Приоритизация: RICE/WSJF/ICE
Приоритизация: RICE, WSJF, ICE
Section titled “Приоритизация: RICE, WSJF, ICE”Быстрый разбор в контексте Delivery: что знать, как применять, какие ошибки не допустить
Зачем приоритизировать задачи в Delivery
Section titled “Зачем приоритизировать задачи в Delivery”Почему нельзя тащить всё сразу
Section titled “Почему нельзя тащить всё сразу”Когда над продуктом работает несколько команд, всегда больше хотелок, чем ресурсов. Если не выбрать, что делать в первую очередь, сроков и качества не будет, команды начнут буксовать.
Как выглядят плохие процессы
Section titled “Как выглядят плохие процессы”Типичная ошибка — взяться за проект, сверяясь с личными мнениями или громкостью запроса. Итог: страдают действительно важные фичи или криты, выгрузки по ночам, откладывание багов и фич ради «нового красивого экрана».
Пример:
В ecommerce запускали блок новых баннеров по пожеланию маркетинга, хотя спустя месяц конкуренты вышли с быстрой доставкой, которую «положили в бэклог». В итоге потеряли долю рынка.
RICE: Оценка эффекта через 4 параметра
Section titled “RICE: Оценка эффекта через 4 параметра”Что такое RICE
Section titled “Что такое RICE”RICE (Reach, Impact, Confidence, Effort) — способ прикинуть пользу задачи и выбрать из набора запросов те, что дадут максимальный эффект на единицу усилий.
Формула:
RICE = (Reach × Impact × Confidence) ÷ Effort
- Reach: сколько пользователей затронет.
- Impact: насколько сильно изменится поведение или метрика.
- Confidence: насколько уверены в оценках.
- Effort: сколько ресурсов потратишь.
Как работает на практике
Section titled “Как работает на практике”Берешь задачи из бэклога, оцениваешь по 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 — осторожнее
Section titled “ICE: Просто, быстро, но в Delivery — осторожнее”Что такое ICE
Section titled “Что такое ICE”ICE (Impact, Confidence, Ease) — похожий, но упрощенный подход.
ICE = Impact × Confidence × Ease
Ease — условный эквивалент «легкости», обычно напоминает Effort, но зеркально (больше — проще).
В каких кейсах ICE может подвезти
Section titled “В каких кейсах ICE может подвезти”ICE подходит, если нечего тратить время на глубокую аналитику. Но часто появляется ilusion of simplicity: ловушка в том, что внутренние ощущения про Impact и Ease могут быть не точными.
Пример:
Команда выбирает из 10 багов по ICE, чтобы починить топ-3 до релиза. Нет данных — полагаются на экспертность и здравый смысл. После релиза выясняется, что часть минорных багов сильно влияла на NPS — оценить заранее было сложно без данных.
Вывод: ICE годится для приоритизации мелких инкрементов и багфиксов в Delivery, где скорость важнее точности.
Источник: GrowthHackers про ICE
WSJF: Сделать дорогое быстро и выгодно
Section titled “WSJF: Сделать дорогое быстро и выгодно”Как работает WSJF
Section titled “Как работает WSJF”WSJF (Weighted Shortest Job First) — базовая техника из Lean и Scaled Agile (SAFe) для больших команд и портфелей.
Формула:
WSJF = Стоимость задержки (Cost of Delay) / Продолжительность (Job Duration)
Таким образом, задачам, у которых задержка принесет много потерь, отдают приоритет.
- Cost of Delay: сколько компания потеряет, если не сделает задачу сейчас.
- Job Duration: сколько времени реально нужно.
Где WSJF применяют в Delivery
Section titled “Где WSJF применяют в Delivery”Когда важно быстро запускать фичи, которые прямо влияют на деньги, выручку или SLA, WSJF помогает не провалиться по критичным блокам.
Пример:
Финтех-команда взвешивала багфиксы и новые интеграции. Перевод пользователей на новую платформу приносил просадку в NPS и деньгах — просчитали Cost of Delay на потерянной выручке, оценили duration, первыми отправили интеграцию на доработку, потом добирались до менее срочных тасков.
Цитата:
WSJF помогает прозрачно расставлять приоритеты между задачами с разным влиянием на бизнес, особенно если ресурсов не хватает
— Melissa Perri, The Build Trap, источник
Источник: ProductPlan о WSJF
Советы и ошибки: что критично помнить
Section titled “Советы и ошибки: что критично помнить”Как не превращать приоритизацию в бессмысленную «игру в баллы»
Section titled “Как не превращать приоритизацию в бессмысленную «игру в баллы»”- Не оценивай задачи в вакууме: соглашайся на оценку несколькими ролями (продукт, аналитик, dev lead).
- Определи, что значит Impact именно для твоего продукта (например, retention vs выручка).
- В бейзлайне держи бизнес-цель и product metrics, чтобы ICE/RICE/WSJF считались не ради баллов, а ради результата.
- Раз в спринт пересматривай важные задачи: при появлении новых вводных приоритеты быстро устаревают.
Типичные ошибки и что делать вместо
Section titled “Типичные ошибки и что делать вместо”- Игнорировать Cost of Delay — мелкие баги могут откусить репутацию, если тянуть слишком долго.
- Считать Effort/Ease без реальной оценки команды (лучше обсудить вместе).
- Недоучитывать уверенность (Confidence): брать задачи с оценкой 0.3 — значит почти играть вслепую. Сначала собери данные.
Пример:
В команде не спрашивают разработчиков насчет Effort — таски кажутся проще, бурндаун срывается.
Советы по приоритизации начинаются с простого вопроса — зачем ты это делаешь? Без четкого ответа любая формула превратится в подкидной инструмент
— Adapted from Teresa Torres, Continuous Discovery Habits, источник
FAQ по приоритизации Delivery задач
Section titled “FAQ по приоритизации Delivery задач”1. Как выбрать между RICE, ICE и WSJF?
Для срочных багов и фич часто используют ICE, для фич с бизнес-метриками — RICE, при оценке многозадачности и срочности — WSJF.
2. Нужно ли детально оценивать все задачи?
Нет, детальную оценку делай только для ключевых задач. Мелкие просчитывай по ICE или сразу сортируй в triage.
3. Что делать, если оценки расходятся в команде?
Обсуди причины расхождений. Проверь базовую логику и данные, лучше переоценить вместе.
4. Когда пересматривать приоритеты?
Перед каждым спринтом или релизом, а также при появлении критичного внешнего фактора (например, выход нового конкурента).
5. Как измерять Impact и Effort объективно?
Impact — через метрики продукта: retention, выручка, NPS. Effort — по экспертной оценке команды, лучше всего в story points или человеко-днях.
6. Где брать хорошие бенчмарки для своих расчетов?
Смотри на аналоги в своем сегменте, читай отчеты (например) и сравнивай с историческими данными своей команды.