Приоритизация: RICE/WSJF/ICE

RICE, ICE и WSJF не выдают объективный ответ — они делают допущения видимыми и помогают сравнивать инициативы по одной логике. Сначала определите тип решений и единицы оценки, затем обсуждайте расхождения в Reach, Impact, Confidence и Cost of Delay, а не спорьте о финальном балле.

Зачем приоритизировать задачи в Delivery

Почему нельзя тащить всё сразу

Когда над продуктом работает несколько команд, всегда больше хотелок, чем ресурсов. Если не выбрать, что делать в первую очередь, сроков и качества не будет, команды начнут буксовать.

Как выглядят плохие процессы

Типичная ошибка — взяться за проект, сверяясь с личными мнениями или громкостью запроса. Итог: страдают действительно важные фичи или криты, выгрузки по ночам, откладывание багов и фич ради «нового красивого экрана».

Пример:
В ecommerce запускали блок новых баннеров по пожеланию маркетинга, хотя спустя месяц конкуренты вышли с быстрой доставкой, которую «положили в бэклог». В итоге потеряли долю рынка.

RICE: Оценка эффекта через 4 параметра

Что такое RICE

RICE (Reach, Impact, Confidence, Effort) — способ прикинуть пользу задачи и выбрать из набора запросов те, что дадут максимальный эффект на единицу усилий.
Формула:
RICE = (Reach × Impact × Confidence) ÷ Effort

• Reach: сколько пользователей затронет.
• Impact: насколько сильно изменится поведение или метрика.
• Confidence: насколько уверены в оценках.
• Effort: сколько ресурсов потратишь.

Как работает на практике

Берешь задачи из бэклога, оцениваешь по 4 параметрам — например, новую интеграцию или переработку UX. Сравниваешь баллы: если задача может дать заметный прирост метрики при минимальных рисках и усилиях, она скорее попадет в Delivery следующей итерации.

Пример:
В SaaS заметили просадку онбординга, сформулировали гипотезы, оценили:
Reach 2000 юзеров/месяц
Impact 0.3 (умеренный)
Confidence 80%
Effort 5 дней
RICE: (2000×0.3×0.8)/5 = 96
Для сравнения, другая задача набрала 40 — в первую очередь берут ту, что выше.

Антипаттерн:
Завышать Impact из-за внутреннего энтузиазма или занижать Effort от оптимизма — баллы становятся непоказательными, Delivery буксует.

Источник: Intercom об RICE

ICE: Просто, быстро, но в Delivery — осторожнее

Что такое ICE

ICE (Impact, Confidence, Ease) — похожий, но упрощенный подход.
ICE = Impact × Confidence × Ease
Ease — условный эквивалент «легкости», обычно напоминает Effort, но зеркально (больше — проще).

В каких кейсах ICE может подвезти

ICE подходит, если нечего тратить время на глубокую аналитику. Но часто появляется illusion of simplicity: ловушка в том, что внутренние ощущения про Impact и Ease могут быть не точными.

Пример:
Команда выбирает из 10 багов по ICE, чтобы починить топ-3 до релиза. Нет данных — полагаются на экспертность и здравый смысл. После релиза выясняется, что часть минорных багов сильно влияла на NPS — оценить заранее было сложно без данных.

Вывод: ICE годится для приоритизации мелких инкрементов и багфиксов в Delivery, где скорость важнее точности.

Источник: GrowthHackers про ICE

WSJF: Сделать дорогое быстро и выгодно

Как работает WSJF

WSJF (Weighted Shortest Job First) — базовая техника из Lean и Scaled Agile (SAFe) для больших команд и портфелей.
Формула:
WSJF = Стоимость задержки (Cost of Delay) / Продолжительность (Job Duration)
Таким образом, задачам, у которых задержка принесет много потерь, отдают приоритет.

• Cost of Delay: сколько компания потеряет, если не сделает задачу сейчас.
• Job Duration: сколько времени реально нужно.

Где WSJF применяют в Delivery

Когда важно быстро запускать фичи, которые прямо влияют на деньги, выручку или SLA, WSJF помогает не провалиться по критичным блокам.

Пример:
Финтех-команда взвешивала багфиксы и новые интеграции. Перевод пользователей на новую платформу приносил просадку в NPS и деньгах — просчитали Cost of Delay на потерянной выручке, оценили duration, первыми отправили интеграцию на доработку, потом добирались до менее срочных тасков.

Источник: ProductPlan о WSJF

Советы и ошибки: что критично помнить

Как не превращать приоритизацию в бессмысленную «игру в баллы»

• Не оценивай задачи в вакууме: соглашайся на оценку несколькими ролями (продукт, аналитик, dev lead).
• Определи, что значит Impact именно для твоего продукта (например, retention vs выручка).
• В бейзлайне держи бизнес-цель и product metrics, чтобы ICE/RICE/WSJF считались не ради баллов, а ради результата.
• Раз в спринт пересматривай важные задачи: при появлении новых вводных приоритеты быстро устаревают.

Типичные ошибки и что делать вместо

• Игнорировать Cost of Delay — мелкие баги могут откусить репутацию, если тянуть слишком долго.
• Считать Effort/Ease без реальной оценки команды (лучше обсудить вместе).
• Недоучитывать уверенность (Confidence): брать задачи с оценкой 0.3 — значит почти играть вслепую. Сначала собери данные.

Пример:
В команде не спрашивают разработчиков насчет Effort — таски кажутся проще, бурндаун срывается.

FAQ по приоритизации Delivery задач

1. Как выбрать между RICE, ICE и WSJF?
Для срочных багов и фич часто используют ICE, для фич с бизнес-метриками — RICE, при оценке многозадачности и срочности — WSJF.

2. Нужно ли детально оценивать все задачи?
Нет, детальную оценку делай только для ключевых задач. Мелкие просчитывай по ICE или сразу сортируй в triage.

3. Что делать, если оценки расходятся в команде?
Обсуди причины расхождений. Проверь базовую логику и данные, лучше переоценить вместе.

4. Когда пересматривать приоритеты?
Перед каждым спринтом или релизом, а также при появлении критичного внешнего фактора (например, выход нового конкурента).

5. Как измерять Impact и Effort объективно?
Impact — через метрики продукта: retention, выручка, NPS. Effort — по экспертной оценке команды, лучше всего в story points или человеко-днях.

6. Где брать хорошие бенчмарки для своих расчетов?
Смотри на аналоги в своем сегменте, читай отчеты (например) и сравнивай с историческими данными своей команды.