Одна из самых сложных задач Владельца Продукта (Product Owner) — сказать нет. В бэклоге всегда больше идей, чем команда физически может реализовать. Если пытаться сделать всё сразу, мы не сделаем ничего. Если выбирать задачи на основе «чуйки» или того, кто громче кричит, продукт превратится в лоскутное одеяло.
Чтобы принимать взвешенные решения, нужны системы приоритизации. Разберем две самые популярные: MoSCoW для быстрых решений и RICE для глубокого анализа.
MoSCoW: Метод для дедлайнов и релизов
Эта техника пришла из Agile-методологии DSDM. Она идеально подходит, когда у вас есть жесткое ограничение по времени (например, Спринт или дата релиза) и нужно понять, что в него войдет.
Название это акроним, который делит все задачи на четыре корзины:
- M — Must have (Обязательно должно быть).
Это фундамент. Без этих задач продукт не имеет смысла или не будет работать. Если мы не сделаем хотя бы один «Must», релиз считается проваленным.- Пример: Для интернет-магазина это кнопка «Купить» и корзина.
- S — Should have (Следует сделать).
Важные функции. Если их не сделать, будет больно или неудобно, но продукт будет работать. Обычно их делают сразу после Must.- Пример: Возможность восстановить пароль через email (можно временно делать это через техподдержку, но лучше автоматизировать).
- C — Could have (Могло бы быть / Хорошо бы сделать).
Приятные дополнения. Их делают, только если осталось время. Это первые кандидаты на вылет, если что-то пойдет не так.- Пример: Темная тема интерфейса.
- W — Won’t have (Не будет в этот раз).
Важно: это не значит никогда. Это значит «не в этом релизе». Мы осознанно откладываем эти задачи, чтобы сфокусироваться на главном.
Золотое правило: Категория Must have не должна занимать более 60% ресурсов команды. Если у вас всё «Must», у вас нет пространства для маневра при возникновении проблем.
RICE: Математика вместо интуиции
Этот метод разработала компания Intercom. Он подходит для стратегического планирования, когда нужно сравнить совершенно разные идеи (например, «интеграция с Telegram» против «нового дизайна профиля») и понять, что принесет больше денег или пользы.
RICE это формула. Вы считаете четыре параметра для каждой задачи:
- Reach (Охват).
Скольких людей это затронет за определенный период (обычно квартал)?- Пример: 500 клиентов в месяц.
- Impact (Влияние).
Насколько сильно это повлияет на конкретного человека (или на ключевую метрику)?
Обычно используют шкалу:- 3 = Массивное влияние.
- 2 = Высокое.
- 1 = Среднее.
- 0.5 = Низкое.
- Confidence (Уверенность).
Это ваш фильтр от галлюцинаций. Насколько вы уверены в своих цифрах по Охвату и Влиянию?- 100% = Есть твердые данные, метрики, исследования.
- 80% = Есть косвенные данные.
- 50% = «Мне так кажется» (интуиция).
- Effort (Усилия/Трудозатраты).
Сколько времени это займет? Обычно считают в «человеко-месяцах» или «человеко-неделях».
Формула RICE:
(Reach×Impact×Confidence)/Effort=ScoreЧем выше итоговый балл, тем приоритетнее задача. Эта формула помогает отсеять идеи, которые требуют огромных усилий, но приносят мало пользы, или идеи, в которых мы совсем не уверены.
Сравнение методов
| Характеристика | MoSCoW | RICE |
| Тип оценки | Качественная (Слова/Смыслы) | Количественная (Цифры/Формула) |
| Для чего лучше | Планирование Спринта, Релиза, MVP. Общение со стейкхолдерами. | Формирование Roadmap, сравнение гипотез, долгосрочное планирование. |
| Сложность | Низкая. Можно сделать на стикерах за 15 минут. | Высокая. Требует сбора данных и расчетов. |
| Главный риск | Всё становится Must have под давлением заказчика. | Ошибка в данных («Мусор на входе — мусор на выходе»). |
Глубокое погружение: Как это работает в жизни
Частая ошибка новичков: верить, что фреймворк примет решение за вас. Это не так.
RICE не истина в последней инстанции.
Вы можете посчитать баллы и увидеть, что скучная техническая задача набрала больше очков, чем стратегически важная фича. Это повод задуматься, а не слепо следовать цифрам. RICE подсвечивает задачи с высоким потенциалом и низкими затратами (Quick Wins), которые вы могли пропустить.
MoSCoW — это инструмент переговоров.
Когда стейкхолдер приходит и говорит: «Мне нужно всё это к пятнице», вы используете MoSCoW, чтобы договориться. Вы говорите: «Окей, мы берем это в Must. Но если мы не успеем, мы пожертвуем задачами из Could. Согласны?». Это делает ожидания прозрачными.
Резюме: Какой метод выбрать?
Используйте MoSCoW, когда вы сидите на Планировании Спринта или обсуждаете с клиентом состав ближайшего релиза. Это язык, понятный людям.
Используйте RICE, когда вы сидите в тишине, смотрите на бэклог из 100 идей и пытаетесь понять, куда развивать продукт в следующем квартале. Это язык внутренней эффективности.
Ключевой вывод: Приоритизация — это не просто сортировка списка. Это процесс отказа от хороших идей ради реализации великих.
Часто задаваемые вопросы (FAQ)
Да, и это отличная практика. Сначала вы используете RICE, чтобы отфильтровать бэклог и выбрать топ-10 самых перспективных идей для квартала. А затем, когда планируете конкретный Спринт или релиз, применяете MoSCoW к этим выбранным задачам, чтобы управлять рисками сроков.
Финальное решение всегда за Владельцем Продукта (Product Owner). Это его прямая ответственность согласно Scrum Guide. Однако он должен делать это, советуясь с Разработчиками (для оценки Effort) и стейкхолдерами (для оценки Impact/Value).
В Scrum это происходит постоянно. Бэклог Продукта, это живой артефакт. Официально пересмотр происходит на Product Backlog Refinement (уточнении бэклога). Если вы используете RICE, пересчитывать баллы стоит раз в квартал или при появлении новых данных.
Это сигнал о незрелости процессов или недоверии. Владелец Продукта должен объяснить, что если всё “Must”, то ничто не является приоритетом. При форс-мажоре (заболел разработчик, упал сервер) такой план рухнет целиком. Предложите жесткое правило: не более 60% на Must, остальное буфер безопасности.
Если данных нет совсем, ваша уверенность минимальна (50% или ниже). Это нормально. RICE как раз и покажет, что у задачи низкий приоритет из-за риска. Чтобы повысить приоритет, нужно провести исследование (Spike) или запустить быстрый тест, чтобы получить данные.