Control Lab - лаборатория данных

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. Решите задачу оптимизации на итераци...