Одна из самых сложных задач Владельца Продукта (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) или запустить быстрый тест, чтобы получить данные.