RICE, ICE, MoSCoW: когда фреймворк приоритизации вас топит

Три фреймворка приоритизации. Один вопрос: когда они вас убивают

Когда я пришёл в 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, в комментариях.