RICE, ACE, WSJF
Какой фреймворк принятия решений используешь ты?
Принятие решения - одно из главных задач которыми занимается продукт, управленец
При этом в лесу разных фреймворков часто можно увидеть, что какой-либо знакомый набор аббревиатура набор букв фактически работают не так как задумано по той причине, что используются не для той среды для которой придуманы.
Примеры
RICE Score = (Reach × Impact × Confidence) / Effort
- Reach — Сколько пользователей затронет за период
- Impact — Насколько сильно повлияет на целевую метрику
- Confidence — Уверенность в оценке (отражает способ проверки информации и достоверность которую дает метод)
- Effort — Относительная сложность реализации выраженная в положительном исчислении
Применяется для Гипотез, и только!
Он не подходит для выбора инициатив, которые готовы к тому, чтобы быть запущенными в реализацию.
Если уж говорить про инициативы, то тут из известного лучше всего подходит
WSJF (Weighted Shortest Job First) используется для приоритизации готовых инициатив (фич) в очереди Delivery.
WSJF = Cost of Delay / Job Size
- Cost of Delay — Сколько стоит задержка (бизнес-ценность, время на рынок, риск)
- Job Size — Оценка объёма работы
WSJF — Приоритет (чем выше, тем важнее)
Когда исопльзуеться?
- Для готовых инициатив (фич) в Delivery
- Когда инициативы (фичи) прошли валидацию и готовы к реализации
- Когда нужно выбрать, какую фичу делать следующей
WSJF в классическом виде предполагает единую очередь для одного стрима. Когда у нас несколько стримов (Desktop, Mobile, Backend), работающих над одной инициативой:
Но имеет свои проблемы:
1. Неделимость инициативы. Инициатива уровня E2E требует участия всех трёх стримов. Вы не можете запустить фичу на Mobile, если Backend не готов.
2. Разная скорость стримов Delivery. У каждого стрима свой Throughput, свой Cycle Time. Задача, которая для Backend — 3 дня, для Mobile может быть 2 недели.
3. Конкуренция за ресурсы между инициативами. Если у вас 5 инициатив в бэклоге, и каждая требует участия всех трёх стримов, то вы не можете просто отсортировать их по WSJF и брать сверху.
В случае мульти-стримной системе поставки (в Delivery) при этом есть решения
Рекомендация: Перед тем как взять инициативу в Delivery, проверить доступность всех необходимых стримов. Если хотя бы один стрим перегружен — инициатива не стартует, а ждёт освобождения. Бэклог Delivery сортируется по WSJF, но старт инициативы происходит только при готовности всех стримов.
- Ввести WIP-лимиты на уровне «количество одновременных E2E-инициатив», а не на уровне отдельных стримов. Например: не более 3 инициатив одновременно в Delivery.
- Использовать узкое горлышко как драйвер расписания. Если Backend — узкое горлышко, то приоритизировать бэклог Delivery по тому, что максимально загружает Backend ценной работой.
- Для квартального планирования — метод критической цепи, если у вас фиксированный набор инициатив на квартал.
Если же разложить на какую-то простую понятную форму, когда что использовать, то можно представить так:
- Value vs Effort (ICE) — Базовая приоритизация
- RICE — Гипотезы в Discovery
- WSJF — Готовые фичи в Delivery
- WSJF + WIP-лимиты — Мультистримная среда (Delivery)
Конечно, если вы переходите к использованию более автоматизированных систем, где за приоритизацию может отвечать машина, то стоит рассмотреть подробнее о том, что такое Симплекс Метод, который является более универсальным походом, и наиболее качественно решает проблему упаковки и получения максимального Value.
---
Из интересного, это то, что WSJF наиболее близок к теории игр
В теории игр используется метод Неймана–Моргенштерна (Neumann–Morgenstern), который позволяет оценить ожидаемую полезность для каждого игрока в сложной игре.
Как можно связать с теорией игр?
Шаг 1. Определите «полезность» для вашего продукта
Полезность — это не просто деньги. Это может быть:
- Бизнес-ценность (рост конверсии, удержание, выручка),
- Стратегическая важность (выход на новый рынок),
- Снижение рисков (техдолг, безопасность),
- Удовлетворённость ключевых клиентов.
Шаг 2. Оцените неопределённость по каждой задаче
Для каждой user story или фичи оцените несколько сценариев по времени и результату:
- Оптимистичный (всё гладко) — вероятность, время, полученная ценность,
- Наиболее вероятный,
- Пессимистичный (всплыли подводные камни).
Шаг 3. Примените функцию полезности с учётом отношения к риску
Команды часто избегают задач с большим разбросом (рискованных), даже если их ожидаемая ценность высока. Фон Нейман–Моргенштерн позволяют ввести выпуклую/вогнутую функцию (например, логарифмическую), чтобы отразить вашу толерантность к риску.
Пример:
- Если вы стартап, готовы рисковать — функция линейная.
- Если продукт в стабильной фазе, штрафуете пессимистичные сценарии (вогнутая функция).
Вместо сложных формул на практике часто используют «взвешенный по риску» приоритет: вычитаете из ценности, скажем, 10% за каждый день отклонения сверх ожидаемого.
Шаг 4. Решите задачу оптимизации на итерацию
У вас есть ограничение — сумма человеко-дней команды (например, 100 ч/дней). Теперь:
- Для каждой задачи рассчитайте отношение ожидаемой полезности к ожидаемым затратам (ROI).
- Отсортируйте задачи по убыванию этого отношения.
- Последовательно добавляйте их, пока не упрётесь в бюджет итерации.
Это классический «жадный» алгоритм, близкий к Weighted Shortest Job First (WSJF), который используется в SAFe — он как раз основан на той же логике ожидаемой полезности.
Шаг 5. Проведите анализ чувствительности
Посмотрите, как изменится выбор, если вы немного измените оценки вероятностей или времени. Если приоритет топ-задач остаётся стабильным — вы уверены в решении. Если нет — обсудите оценки повторно с командой.
#интересное
