Три фреймворка приоритизации. Один вопрос: когда они вас убивают
Когда я пришёл в Instameal, у нас был бэклог на сорок задач и ни одного чёткого критерия почему одно важнее другого.
Мы попробовали RICE. Потом ICE. Потом MoSCoW. Потом снова RICE с другими весами.
Проблема была не в том, что мы выбирали неправильный фреймворк. Проблема была в том, что мы думали: выберем правильный инструмент - и приоритеты выстроятся сами.
Не выстроятся.
Что такое каждый из трёх
RICE: Reach (охват) × Impact (влияние) × Confidence (уверенность) / Effort (усилия). Даёт цифру. Чем выше - тем выше приоритет.
ICE: Impact × Confidence × Ease. Проще, быстрее считается. Используется в growth-командах для быстрой оценки экспериментов.
MoSCoW: Must have / Should have / Could have / Won't have. Не числа, а категории. Используется для определения скоупа: что точно идёт в релиз, что - нет.
На бумаге выглядит логично. На практике каждый из них создаёт свою специфическую проблему.
Когда RICE вас топит
RICE создаёт иллюзию объективности.
Вы получаете число: 84.6. Задача с числом 84.6 важнее задачи с числом 71.2. Кажется, что это данные. На самом деле это ваши субъективные оценки, умноженные друг на друга и поделённые на другую субъективную оценку.
Confidence 80% - откуда? Reach 500 пользователей в месяц - это предположение или из аналитики? Impact «3» - кто решил что именно три?
В Instameal мы однажды потратили два часа на заполнение RICE-таблицы для восьми задач. В конце получили список. Топ-3 задачи в списке совпали ровно с тем, что интуитивно предлагал лид разработки до всего этого упражнения.
RICE убивает когда: данных нет, оценки угадываются, команда начинает спорить не о задачах - а о числах в формуле.
Когда ICE вас топит
ICE быстрее - и именно поэтому опаснее.
Ease («лёгкость») - самый субъективный критерий из всех трёх фреймворков. PM оценивает лёгкость без разработчика. Разработчик видит то же самое и говорит «это три спринта». Встреча становится разбором полётов.
ICE хорошо работает в одной конкретной ситуации: growth-эксперименты, где команда маленькая, критерии известны, и все под одним контекстом. Как только команда больше трёх человек и задачи разноплановые - ICE разваливается потому что «лёгкость» у всех разная.
Когда MoSCoW вас топит
MoSCoW ломается на одном слове: «Must».
Стейкхолдер A говорит: эта фича Must Have. Стейкхолдер Б говорит: нет, эта фича Must Have. Через час у вас двенадцать Must Have задач и вы вернулись к тому с чего начали.
Must для кого? Для пользователя? Для инвестора? Для юридического отдела? Для запуска в эту пятницу или в следующем квартале?
Без чёткого ответа на этот вопрос MoSCoW превращается в политическое голосование, а не в инструмент приоритизации.
Что я использую сейчас
Три правила которые работают лучше любого фреймворка в чистом виде.
Первое: определить горизонт перед тем как расставлять приоритеты. Мы сейчас расставляем приоритеты для ближайших двух недель, квартала или года? Разный горизонт - разный инструмент. MoSCoW хорош для «что идёт в этот релиз», RICE - для «что делать следующим кварталом».
Второе: оценки должны давать те, кто их будет выполнять. Не PM в одностороннем порядке. Если лёгкость или усилие оценивает только один человек - оценка нерабочая.
Третье: фреймворк не принимает решение. Он структурирует разговор. Итоговое решение принимает команда, основываясь на реальных данных и разговорах с пользователями. Число из RICE - один из входов, не ответ.
Главное
Фреймворк приоритизации - это инструмент для разговора, а не замена суждению.
Если ваша команда спорит о весах в RICE-формуле вместо того чтобы говорить о пользователях - формула работает против вас.
Шаблон таблицы приоритизации + объяснение когда какой фреймворк применять - в Telegram-канале PM vision, в комментариях.