Приоритизация требований

Приоритизация требований: MoSCoW, Kano, Value vs Effort

📚 20 вопросовПройти тест →
Лекция

Приоритизация требований: MoSCoW, Kano, Value vs Effort

Приоритизация требований

Приоритизация требований: MoSCoW, Kano, Value vs Effort

Введение: чемодан в ограниченный багаж 🧳

В релиз нельзя уместить всё: время, бюджет и команда всегда ограничены. Поэтому важно не просто собрать бэклог, а выбрать, что даёт максимальную ценность сейчас.
💡 Совет: приоритет — это не «что нравится», а «что даёт результат и снижает риски». ✅ Вывод: приоритизация превращает хаос требований в управляемый план.

Проблема → решение

Проблема: когда «всё срочно», команда распыляется, а релиз теряет фокус. Решение: применять понятные методы приоритизации: MoSCoW, Kano, Value vs Effort, RICE, WSJF.
✅ Вывод: приоритеты должны быть прозрачными и объяснимыми для всей команды.

Чем помогает и как работает

Приоритизация помогает выпустить работающий MVP, не срывая сроки. Она показывает, какие требования критичны для релиза, а какие можно перенести.
Как это работает:
  1. Формируем общий список требований.
  2. Оцениваем ценность и усилия.
  3. Выбираем метод и фиксируем решение (что в релизе, что позже).
✅ Вывод: приоритизация — это повторяемый процесс, а не субъективное мнение.

Ключевые термины (простыми словами)

  • Prioritization (приоритизация) — выбор порядка выполнения требований.
  • MoSCoW — Must/Should/Could/Won’t.
  • Kano model — базовые, ожидаемые и «вау»-фичи.
  • Value vs Effort — матрица «польза/затраты».
  • RICE — Reach × Impact × Confidence / Effort.
  • WSJF — Cost of Delay / Job Size.
  • MVP — минимальный рабочий набор функций.
  • Trade-off — осознанный компромисс между важными вариантами.
✅ Вывод: эти термины — база для обсуждения приоритетов с бизнесом и командой.

1. MoSCoW — быстрый фильтр критичности

Назначение: быстро разложить требования по важности для релиза. Простыми словами: отделяем «обязательно» от «желательно».
Пример:
Must: авторизация и запись на курсShould: фильтр по категориямCould: избранноеWon’t: сертификаты в релизе 1.0
🔎 Как это происходит на практике:
  1. Продукт и аналитик собирают список фич.
  2. Команда помечает каждую фичу как Must/Should/Could/Won’t.
  3. В релиз берут Must + часть Should по ресурсу.
Характеристики:
  • ✅ быстрый и понятный метод;
  • ✅ хорошо работает на старте спринта;
  • ❗ требует дисциплины (нельзя делать «всё Must»).
Когда использовать: когда нужно быстро определить состав релиза или спринта.
✅ Вывод: MoSCoW даёт фокус и снимает спор «что важнее».

2. Kano — что влияет на удовлетворённость пользователя

Назначение: понять, какие фичи обязательны, а какие дают «вау»-эффект. Простыми словами: не все полезные функции одинаково важны для эмоции пользователя.
Категории:
  • Basic — обязательный минимум;
  • Performance — чем лучше, тем выше удовлетворённость;
  • Delighter — приятно удивляет, но не обязателен.
🔎 Как это происходит на практике:
  1. Команда описывает ключевые фичи.
  2. Для каждой фичи определяет категорию Kano.
  3. В MVP оставляет Basic + часть Performance, Delighter переносит на следующий этап.
Характеристики:
  • ✅ полезен для продуктовых решений;
  • ✅ помогает не путать «обязательное» и «вау»;
  • ❗ требует обсуждения с продуктом/пользователями.
Когда использовать: когда важно повысить пользовательскую ценность и качество UX.
✅ Вывод: Kano помогает инвестировать в то, что реально чувствует пользователь.

3. Value vs Effort — максимум пользы за минимум усилий

Назначение: выбрать задачи с лучшим соотношением результата и затрат. Простыми словами: сначала делаем быстрые полезные победы.
Матрица:
  • High Value / Low Effort — делаем сразу (quick wins);
  • High Value / High Effort — планируем отдельным этапом;
  • Low Value / Low Effort — берём при свободном ресурсе;
  • Low Value / High Effort — откладываем.
🔎 Как это происходит на практике:
  1. Для каждой фичи команда ставит оценку Value и Effort.
  2. Размещает фичи на матрице.
  3. Формирует порядок разработки по квадрантам.
Характеристики:
  • ✅ просто объяснить бизнесу;
  • ✅ хорошо работает в планировании релиза;
  • ❗ оценки должны быть согласованными.
Когда использовать: когда есть хотя бы грубые оценки трудозатрат.
✅ Вывод: матрица защищает команду от дорогих фич с низкой отдачей.

4. RICE — приоритизация по формуле

Назначение: численно сравнить инициативы, когда есть данные. Простыми словами: считаем ожидаемую ценность и делим на усилия.
Формула: RICE = (Reach × Impact × Confidence) / Effort
Мини‑пример:
Reach: 2000, Impact: 2, Confidence: 80%, Effort: 4RICE = (2000 × 2 × 0.8) / 4 = 800
🔎 Как это происходит на практике:
  1. Продукт собирает метрики охвата и эффекта.
  2. Команда оценивает confidence и effort.
  3. Фичи сортируются по итоговому RICE score.
Характеристики:
  • ✅ снижает субъективность;
  • ✅ полезен для сравнений гипотез;
  • ❗ нужен адекватный исходный data input.
Когда использовать: когда есть цифры по охвату и влиянию.
✅ Вывод: RICE хорош для data-driven приоритизации.

5. WSJF — ценность на единицу времени

Назначение: выбрать задачи, которые быстрее всего принесут бизнес‑результат. Простыми словами: что приносит больше пользы за меньший размер работы.
Формула: WSJF = Cost of Delay / Job Size
🔎 Как это происходит на практике:
  1. Оцениваем стоимость задержки (ценность, срочность, риски).
  2. Оцениваем размер задачи (Job Size).
  3. Берём в работу задачи с более высоким WSJF.
Характеристики:
  • ✅ ускоряет доставку ценности;
  • ✅ помогает на больших бэклогах;
  • ❗ требует единых правил оценки Job Size.
Когда использовать: при ограниченном времени и большом потоке инициатив.
✅ Вывод: WSJF помогает не просто выбрать важное, а выбрать выгодный порядок.

6. Как комбинировать методы (рабочий процесс)

Назначение: получить практичный и защищаемый релиз‑план. Простыми словами: сначала быстро фильтруем, потом уточняем цифрами.
🔎 Как это происходит на практике:
  1. MoSCoW — быстро делим требования на уровни важности.
  2. Kano — проверяем пользовательскую ценность.
  3. Value vs Effort / RICE / WSJF — выбираем финальный порядок реализации.
Характеристики:
  • ✅ сочетает скорость и точность;
  • ✅ снижает конфликт между бизнесом и разработкой;
  • ✅ удобно для защиты решения перед стейкхолдерами.
Когда использовать: при подготовке релиза, roadmap и спринт‑планирования.
✅ Вывод: комбинация методов даёт самый устойчивый результат.

Сравнение методов

МетодОтвечает на вопросКогда удобен
MoSCoWЧто критично для релиза?Быстрый релиз/спринт
KanoЧто влияет на удовлетворённость?Продуктовые решения
Value vs EffortГде быстрые победы?Планирование реализации
RICEЧто даёт максимум эффекта по данным?Когда есть метрики
WSJFЧто выгоднее делать первым по времени?Большой бэклог и дедлайны

Часто спрашивают на собеседованиях

  • В чём разница MoSCoW и Kano?
  • Чем Value vs Effort отличается от RICE?
  • Что делать, если «всё Must»?
  • Когда выбирать WSJF вместо RICE?
  • Можно ли комбинировать методы?
✅ Вывод: важно уметь не только назвать метод, но и объяснить, когда его применять.

Типичные ошибки

Ошибка 1: «Всё Must»

❌ весь бэклог маркируется как критичный ✅ выделяйте узкое Must‑ядро

Ошибка 2: оценка без Effort

❌ выбирают только по «полезности» ✅ всегда добавляйте оценку затрат

Ошибка 3: нет пересмотра приоритетов

❌ приоритеты не меняются месяцами ✅ пересматривайте на каждом планировании

Ошибка 4: нет аргументации решения

❌ «так решили» ✅ фиксируйте причины и критерии в документе

Best Practices

  • Фиксируйте критерии ценности заранее.
  • Проверяйте баланс Value/Effort для каждой крупной фичи.
  • Проводите совместную приоритизацию (продукт + аналитик + разработка + QA).
  • Документируйте причины приоритета для прозрачности.
  • Пересматривайте приоритеты по факту новых данных.

Заключение

🎯 MoSCoW даёт быстрый каркас релиза. 🎯 Kano показывает пользовательскую ценность. 🎯 Value vs Effort, RICE и WSJF помогают выбрать оптимальный порядок реализации.
Теперь вы можете обосновывать приоритеты не «интуицией», а понятной системой.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Приоритизация требований: MoSCoW, Kano, Value vs Effort»

Пройти тест →