Приоритизация — не расстановка пунктов по порядку, а компромисс между ценностью для бизнеса, затратами, рисками и зависимостями. Без осознанного ранжирования команда распыляется, сроки срываются, а MVP превращается в «всё и сразу». Статья описывает три базовых метода — MoSCoW, модель Кано и WSJF — и показывает, как аналитику выбрать технику, зафиксировать результат и не смешать разные оси «важности».

1. Суть темы

Приоритизация требований (requirements prioritization) — упорядочивание кандидатов в требования по относительной важности с учётом ограничений релиза: срок, бюджет, риски, взаимозависимости. Это не единоразовый акт, а непрерывная работа (grooming backlog) — см. 05.02 Scrum и Kanban (аналитик в Agile); пересмотр приоритетов при изменении контекста — 02.05.02 Управление приоритетами в условиях изменчивости. В BABOK® и ISO/IEC/IEEE 29148 приоритизация — отдельная техника управления требованиями; обзор стандартов — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

Зачем это аналитику:

Уровень артефакта. На ранней стадии ранжируют бизнес-цели и capabilities — ещё до детальной декомпозиции в FR и User Story. MoSCoW на этом уровне задаёт границы MVP; WSJF и Кано по отдельным story имеют смысл после декомпозиции. Смешивать в одном бэклоге бизнес-требования (БТ) и функциональные (ФТ) без явного правила уровня — типичная ошибка: сначала приоритет capability, затем — её частей на одном уровне детализации — 02.03.01 Классификация требований (БТ, ФТ, НФТ), 04.02 Пользовательские истории (User Stories) и Job Stories.

MoSCoW чаще применяют к capabilities, эпикам или крупным FR на уровне релиза/MVP. WSJF — к эпикам, фичам и User Story в бэклоге. Кано — к атрибутам продукта или функциям, которые можно показать пользователю или представителю роли. Комбинация «MoSCoW на MVP → WSJF внутри Must» работает только если оба метода применены к совместимым уровням декомпозиции.

Зависимости — отдельный слой. Сортировка по WSJF или MoSCoW не заменяет граф зависимостей: элемент с высоким приоритетом может быть заблокирован предшественником. Рабочий порядок: (1) ранжирование по выбранному методу, (2) коррекция по зависимостям и блокерам релиза — 02.05.01 Управление зависимостями между требованиями.

Владелец решения. Технику ведёт аналитик, но утверждает приоритеты владелец продукта, спонсор или CCB — в зависимости от governance проекта. Изменение содержания требования и изменение порядка в бэклоге — разные процессы: 02.05.02 Управление изменениями (Change Control Board) vs 02.05.02 Управление приоритетами в условиях изменчивости.

Не путайте два «Must». В MoSCoW Must Have — категория скоупа релиза («без этого релиз не состоится»). В модели Кано Must-Be — тип восприятия пользователя («базовое качество, отсутствие вызывает недовольство»). Kano Must-Be не автоматически становится MoSCoW Must: базовое качество может быть реализовано в более позднем релизе, если есть обходной путь. И наоборот: MoSCoW Must по договорённости с бизнесом не всегда совпадает с Must-Be в глазах пользователя.

2. Ключевые понятия

MoSCoW

MoSCoW (Must, Should, Could, Won't) — качественный метод категоризации, широко используемый в Agile и проектах с фиксированными сроками. Метод закреплён в DSDM (Dynamic Systems Development Method); практические правила — у Agile Business Consortium.

КатегорияСмыслПример
M — Must HaveКритично для релиза; без этого продукт не выполняет минимальную бизнес-функциюОплата заказа в интернет-магазине; согласование заявки в корпоративном workflow
S — Should HaveВажно, но релиз возможен без этого; есть приемлемый обходФильтр по цвету при наличии поиска; экспорт отчёта в Excel при наличии PDF
C — Could HaveЖелательно; повышает удовлетворённость, но не блокирует релизРекомендации похожих товаров; массовое редактирование записей в справочнике
W — Won't Have (this time)Осознанно отложено; фиксируется для управления ожиданиямиИнтеграция с маркетплейсом в следующем квартале; SSO через внешний IdP до миграции AD

Правила применения:

  • Доля Must Have обычно не превышает 60 % объёма timebox — эмпирическое правило DSDM для сохранения буфера на Should/Could и непредвиденное. Если всё «must», метод не работает.
  • «Won't» — не «плохая идея», а решение о границе релиза — 02.01.04 Определение границ решения (Scope Modelling).
  • Regulatory Must: требования по закону, отраслевым и корпоративным стандартам compliance — Must не по результатам переговоров, а по обязательству. Их выделяют отдельно и не «торгуют» в MoSCoW-сессии — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
  • При фиксированном сроке/бюджете (DSDM timebox) MoSCoW определяет, что войдёт в коробку; при фиксированном scope приоритеты влияют на последовательность, а не на отсечение — типичный контекст Waterfall и контрактных проектов: 05.01 Waterfall и V-model.

Плюсы: прост, понятен бизнесу, быстр. Минусы: субъективен, не учитывает стоимость; взаимозависимости корректируются отдельно — 02.05.01 Управление зависимостями между требованиями.

Модель Кано

Модель Кано (Noriaki Kano, 1984) классифицирует атрибуты продукта по влиянию на удовлетворённость пользователя — ось восприятия, а не скоупа релиза.

ТипСмыслСледствие для приоритизации
Must-Be (базовые)Ожидаемы «по умолчанию»; отсутствие — резкое недовольствоЗакрывать раньше конкурентных «фишек», но «первая очередь» по Кано ≠ MoSCoW Must — см. callout в начале статьи
Performance (одномерные)Удовлетворённость растёт с уровнем реализацииОценивать «достаточный» уровень и ROI улучшений
Attractive (привлекательные)Неожиданные «фишки»; отсутствие не разочаровываетВысокий эффект при малых затратах — кандидаты в Could/Should
Indifferent (безразличные)Пользователю всё равноНизкий приоритет; часто кандидаты на Won't или отказ
Reverse (обратные)Наличие снижает удовлетворённостьНе делать — явный сигнал убрать из бэклога

Динамика: Attractive со временем становятся Performance, затем Must-Be.

Процесс: анкета с парой вопросов («если функция будет» / «если не будет»); по матрице ответов определяют категорию. Приоритет: Must-Be → Performance с наибольшим влиянием → Attractive; Indifferent и Reverse обрабатывают отдельно.

Ограничение контекста: на B2B и internal-системах «пользователь» — роль или эксперт-представитель; опрос заменяют интервью, наблюдением, анализом инцидентов — 02.02.01 Интервьюирование и анкетирование, 02.02.03 Наблюдение и анализ документов.

Ограничения методологии: при выборке менее ~30–50 респондентов категории нестабильны; один и тот же атрибут может попасть в разные квадранты при повторном опросе. Формулировки анкеты и культурный контекст («не хочу обидеть разработчиков») искажают ответы. Для корпоративных систем опирайтесь на triangulation — интервью + инциденты + экспертная оценка, а не на единственный опрос.

Плюсы: опирается на восприятие, выявляет скрытые ожидания. Минусы: требует сбора данных и достаточной выборки; не учитывает стоимость и технические ограничения.

WSJF (Weighted Shortest Job First)

WSJF — количественный метод на основе стоимости задержки (Cost of Delay, CoD). Стандарт в SAFe — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках; применим и вне SAFe.

[ WSJF = \frac{\text{CoD}}{\text{Job Size}} ]

Cost of Delay — относительная ценность, теряемая при откладывании работы. В практике SAFe и потоковой разработки CoD чаще безразмерный: команда ставит баллы 1, 2, 3, 5, 8, 13… и ранжирует элементы, а не переводит задержку в рубли или «день простоя». Абсолютный CoD в деньгах возможен при зрелой финансовой модели, но для большинства внутренних и корпоративных проектов достаточно относительного сравнения.

CoD оценивается как сумма относительных баллов по компонентам:

  • Value — влияние на KPI, выручку, NPS;
  • Time Criticality — сужение окна возможностей (сезонность, регуляторный дедлайн);
  • Risk Reduction / Opportunity Enablement — снижение неопределённости, открытие будущих возможностей — 08.05 Управление рисками на этапе анализа.

Job Size — оценка трудозатрат (Story Points, человеко-часы) — 02.05.04 Совместная оценка трудоёмкости требований. В SAFe в знаменателе иногда называют Job Duration — по сути та же оценка размера/длительности работы, не путать с календарным сроком проекта.

Процесс: (1) оценить CoD-компоненты для каждого элемента бэклога, (2) оценить Job Size, (3) вычислить WSJF, (4) отсортировать по убыванию, (5) скорректировать порядок по зависимостям.

Если Job Size неизвестен: до grooming с оценкой команды ранжируют только по CoD или используют MoSCoW/Kano для грубой нарезки; WSJF применяют после появления хотя бы относительных оценок размера.

Дон Райнертсен отмечает, что около 85 % продакт-менеджеров не знают стоимость задержки своих инициатив — иллюстративная оценка из его книги, не статистика исследования; смысл в том, что интуитивные приоритеты часто расходятся на порядки.

Плюсы: объективнее субъективных списков, связывает приоритет с экономикой потока. Минусы: требует дисциплины оценки; зависимости — отдельный шаг.

Другие методы (кратко)

Вспомогательные техники — для обзора, без углубления:

  • Buy-a-Feature (Innovation Games®, Luke Hohmann) — стейкхолдеры распределяют виртуальный бюджет; наглядно при конфликте интересов — 02.02.02 Воркшопы, фасилитация и совместные сессии, 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).
  • RICE — (Reach × Impact × Confidence) / Effort; популярен в продуктовых командах.
  • ICE — Impact × Confidence × Ease; быстрая оценка большого числа идей.
  • Матрица Эйзенхауэра — срочно/важно; слабо ложится на backlog features, годится для личных задач и верхнеуровневых решений.
  • Pareto (20/80) — эвристика «найти 20 % элементов с 80 % ценности»; требует предварительной оценки ценности, иначе превращается в догадку.

RICE и WSJF решают схожую задачу «ценность / усилия», но WSJF явно включает срочность через Time Criticality; детальное сравнение и калькуляторы — в материалах SAFe и продуктовых практиках — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

3. Как применяется в работе аналитика

Выбор метода

СитуацияМетод (основной / вспомогательный)
Ранняя стадия, быстрый скоуп MVPMoSCoW
Есть данные о пользователях, важна дифференциацияКано
Нужна экономическая обоснованность, есть оценки трудозатратWSJF
Много стейкхолдеров с разными предпочтениямиBuy-a-Feature (вспомогательный); при тупике — переговорная рамка 09.03 Управление конфликтами и переговоры
Продуктовая команда, data-driven подходRICE / ICE (вспомогательные)

Типовая комбинация: MoSCoW для грубой нарезки релиза → WSJF или Кано внутри Must Have на одном уровне декомпозиции.

Сквозной пример

Фрагмент бэклога internal-системы учёта заявок после MoSCoW-сессии и WSJF внутри Must:

ЭлементMoSCoWCoDJob SizeWSJFЗависимость / комментарий
Создание заявки с обязательными полямиMust1352,6Блокирует все downstream-процессы
Маршрутизация на согласующегоMust832,7Зависит от «Создание заявки»
Email-уведомление о статусеShould522,5Не блокирует MVP; обход — статус в UI
SLA-дашборд для руководителяCould380,4Высокий Job Size при низкой срочности

После сортировки по WSJF порядок реализации корректируют по графу зависимостей: «Маршрутизация» идёт после «Создание заявки», несмотря на чуть более высокий WSJF.

НФТ в приоритизации

Нефункциональные требования (безопасность, SLA, производительность) — отдельные элементы пула, не «фоновая оптимизация» — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты:

  • MoSCoW: шифрование персональных данных — Must (часто regulatory Must); улучшение времени отклика с 500 до 200 мс — Should или Could в зависимости от SLA.
  • Кано: соответствие базовым ожиданиям безопасности — Must-Be; ускорение отклика — Performance.
  • WSJF: compliance-дедлайн даёт высокий Time Criticality; архитектурный spike на риск — Risk Reduction.

Роль аналитика

После приоритизации — спецификация и критерии приёмки: 02.03.03 Спецификация требований (SRS, Use Case, User Story), 02.04.02 Критерии приёмки (Acceptance Criteria). Регламент пересмотра при изменении контекста — 02.05.02 Управление приоритетами в условиях изменчивости.

Согласование конфликтующих сигналов

Один элемент может получить разные оценки: MoSCoW Should, высокий WSJF, Kano Attractive. Алгоритм:

  1. Зафиксировать расхождение явно — не «усреднять молча».
  2. Вернуться к целям и KPI релиза — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
  3. Эскалировать владельцу решения (PO, спонсор) с аргументами по каждой оси; при конфликте интересов стейкхолдеров — 09.03 Управление конфликтами и переговоры.
  4. Зафиксировать итог и обоснование в артефакте — 02.05.06 Инструменты управления требований (Jama, DOORS, Confluence).

Пакет vs атом — критерий выбора:

  • Эпик или vertical slice целиком — когда декомпозиция ещё грубая, команда оценивает «кусок ценности» end-to-end, или зависимости не позволяют делить (общая инфраструктура, единый релизный контур).
  • Отдельное FR или User Story — когда элемент независимо поставляем, имеет собственные критерии приёмки и оценку Job Size.
  • Смешивать уровни в одной таблице нельзя: эпик «Онбординг клиента» и story «Кнопка „Сохранить черновик“» не соревнуются в одном WSJF-рейтинге.

ИИ как источник данных

LLM и NLP могут ускорить кластеризацию отзывов и черновую классификацию по Кано, но не заменяют фасилитацию и утверждение приоритетов бизнесом. Детали — 11.07 Практические кейсы применения LLM в анализе.

4. Типовые ошибки и ограничения

  • Всё — Must Have: обесценивает MoSCoW. Лечится квотой (~60 % по DSDM) и отдельным выделением regulatory Must. Усиливается якорением и социальным доказательством — если первый участник назвал пункт Must, остальные повторяют; см. 01.07 Когнитивные искажения и критическое мышление.
  • Смешение Must (MoSCoW) и Must-Be (Kano): см. предупреждение в разделе «Суть темы».
  • Смешение БТ и ФТ в одном бэклоге: capability и её story ранжируют на разных уровнях; без правила уровня приоритеты несопоставимы.
  • Игнорирование НФТ: «потом оптимизируем» — блокеры на поздних стадиях; включать НФТ в тот же пул с явной категорией.
  • Зависимости «в голове»: высокий WSJF у заблокированного элемента создаёт ложное ощущение прогресса — нужен граф — 02.05.01 Управление зависимостями между требованиями.
  • Фиксация навсегда: приоритеты устаревают; пересмотр — 02.05.02 Управление приоритетами в условиях изменчивости.
  • Приоритизация без бизнеса: команда разработки решает в одиночку — нарушение governance; аналитик обеспечивает участие владельца продукта.
  • Оценка «на глазок» без KPI: нельзя обосновать CoD и категории MoSCoW.
  • Кано на малой выборке: категории нестабильны; один опрос без triangulation — низкая достоверность.
  • Misapply Эйзенхауэра/Pareto: применять к backlog features без измеримой ценности — формальность.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • IIBA (2015). BABOK® Guide v3 — техники prioritization, MoSCoW, backlog management (разделы по управлению требованиями и приоритизации). https://www.iiba.org/standards-and-resources/babok/
  • Reinertsen, D. (2009). The Principles of Product Development Flow. Cost of Delay, экономика потока.
  • Kano, N. (1984). «Attractive Quality and Must-Be Quality». Journal of the Japanese Society for Quality Control — оригинальная модель Кано.
  • Hohmann, L. (2006). Innovation Games — Buy-a-Feature и игровые техники elicitation.

Руководства и практика

Дополнительно