MoSCoW приоритизация: что важно для продакта

Зачем нужен MoSCoW

Бывает спринт на две недели и список из 25 задач. Команда хочет сделать всё, реальность хочет сделать пять. MoSCoW — про честный разговор: что точно надо, что надо если хватит времени, и что мы решили не делать в этом спринте.

Метод появился в методологии DSDM в 1990-х, ещё в эпоху до Scrum. Сегодня его чаще всего используют не для продуктового бэклога целиком, а для скоупа конкретного релиза или MVP. Это самый понятный и тупой способ сказать «нет» части задач.

Главная польза не в самих категориях, а в том, что Won't отдельно выделена. В большинстве методов «нет» — это «отсутствие задачи в списке». В MoSCoW «нет» — это явный пункт, на который потратили время и решили: эту фичу мы не делаем.

Расшифровка четырёх категорий

• Must have — без этого релиз не имеет смысла. Если хоть одна Must не сделана — релиз не выкатывается. Обычно 50–60% скоупа.
• Should have — важно, но релиз без них переживёт. Стараемся сделать, при сжатых сроках можем перенести. 20–30% скоупа.
• Could have — приятно бы иметь. Делаем, если хватит времени и не пострадают Must/Should. Около 20%.
• Won't have (this time) — фичи, которые мы осознанно отказались делать в этом релизе. Не «забыли», а «решили не делать сейчас».

Ключевые слова — «в этом релизе». Won't не значит «никогда», значит «не сейчас». Это снимает напряжение с команды — никого ничего не отменили, просто перенесли.

Пример распределения на спринт

Допустим, выкатываем апдейт Telegram-приложения для подготовки к собесам. Скоуп — 12 фич:

Must have (обязательно):

• Починить баг с дублированием платежа
• Обновить тариф «Премиум» на новую цену
• Кнопка «выйти из подписки» в настройках

Should have (важно):

• Email-уведомление о продлении подписки
• Новые 50 вопросов по A/B-тестам
• Перевод страницы оплаты на русский для всех СНГ

Could have (приятно):

• Изменить иконку премиума
• Анимация при разблокировке достижения
• Поделиться результатом теста в Stories

Won't have (не в этом релизе):

• Полный редизайн ленты вопросов
• Семейный тариф
• Интеграция с LinkedIn

Решение по Won't важно зафиксировать письменно — иначе через две недели кто-то спросит «а где интеграция с LinkedIn», и команда зависнет.

Когда MoSCoW работает лучше всего

• Релизы с дедлайном. Когда дата фиксирована, MoSCoW идеально показывает, что «отрезаем» при сжатых сроках.
• MVP. Help понять минимальный набор фич, без которых продукт не запустится.
• Согласование с заказчиком. В консалтинге и продуктах с внешними клиентами MoSCoW — это инструмент управления ожиданиями. Заказчик видит Won't и может перепродвинуть в Must (но за это платит сроком или бюджетом).
• Регуляторные релизы. Compliance-фичи попадают в Must без обсуждения.

Где плохо работает: при работе по непрерывному потоку (Kanban без релизов), при долгосрочной продуктовой стратегии (там нужны RICE/Kano), при росте бэклога фич без конца.

MoSCoW vs RICE и ICE

Все три фреймворка приоритизируют, но решают разные задачи.

• MoSCoW — что включить в один релиз/спринт. Качественный, без чисел.
• RICE — какие фичи приоритетнее на квартал. Количественный, требует данных.
• ICE — какие гипотезы тестировать на этой неделе. Быстрый, скриминговый.

В реальности их часто комбинируют: считаем RICE для всего бэклога, отбираем топ-15 кандидатов на ближайший релиз, на этом срезе раскладываем по MoSCoW.

Частые ошибки

• Слишком много Must. Если все 12 задач — Must, MoSCoW не помог. Должно быть честное «всё это сделать невозможно, что важнее».
• Won't превращается в забытое. Если про Won't никто не вспомнит после релиза — фреймворк не работает. Должна быть процедура возврата к Won't на следующем планировании.
• Could делают раньше Must. Классический спринт-баг: команда «зачерпнула» приятную задачу, потому что она интересная, а Must зависла на середине. Could делается ТОЛЬКО когда Must и Should закрыты.
• MoSCoW без оценки эффорта. Если Must в сумме на 200% мощности команды — это не план. Нужна оценка трудозатрат, иначе Must перестают быть Must.
• Один человек распределяет. MoSCoW — командное решение. Если только продакт делит — он получит свой собственный список, который команда не разделяет.

Связанные темы

• RICE приоритизация
• ICE приоритизация
• Kano-модель
• KPI tree продукта

FAQ

Какое идеальное распределение по категориям?

Ориентир: Must — 50–60%, Should — 20%, Could — 20%, Won't — отдельный список. Если Must больше 70% — спринт перегружен.

MoSCoW подходит для Kanban?

Не очень. Kanban работает с потоком, а MoSCoW — со скоупом релиза. Для Kanban лучше использовать классы обслуживания и WIP-лимиты.

Что делать с фичей, которую заказчик считает Must, а команда — Could?

Открытое обсуждение с цифрами: что произойдёт, если фичи не будет. Если ответ «ничего критичного» — это не Must.

Как Won't отличается от «отменено»?

Won't — это «не в этом релизе, обсудим в следующий раз». Отменено — это «никогда». Разница в том, остаётся ли фича в общем бэклоге.

Можно ли менять категории по ходу спринта?

Технически да, но фреймворк теряет смысл, если переставлять каждый день. Должна быть веская причина (новые данные, изменение приоритета бизнеса).

MoSCoW работает в маленькой команде?

Особенно хорошо. Когда вас трое, чёткое «делаем эти 5, не делаем эти 7» — половина успеха. В крупных командах MoSCoW дополняют RICE и OKR.

---

Готовитесь к собесу на продакта или аналитика? Откройте Карьерник — 1500+ вопросов по продуктовой аналитике, фреймворкам и приоритизации.