Фреймворки приоритизации не отменяют суждение — они структурируют его так, чтобы оно было видимым, сопоставимым и защитимым, когда кто-то спросит, почему пункт A вышел раньше пункта B.
Сравнение трёх фреймворков
| Фреймворк | Как считает баллы | Лучше всего подходит для | Слабость |
|---|---|---|---|
| RICE (Reach, Impact, Confidence, Effort) | Числовой балл на основе четырёх оценённых факторов | Команды с данными об использовании и множеством конкурирующих инициатив | Точность может вводить в заблуждение — входные данные всё равно остаются оценками |
| MoSCoW (Must, Should, Could, Won't) | Распределение по четырём уровням приоритета | Скоупинг одного релиза или спринта с жёстким дедлайном | Не ранжирует внутри уровня — всё, что «must have», получает равный вес |
| Матрица «ценность против усилий» | График по двум осям: ожидаемая ценность против стоимости разработки | Небольшие команды без надёжной инфраструктуры данных | Ось ценности часто основана на интуиции, а не на измеренных данных |
Как выбрать между ними
У вас есть надёжные данные об использовании или выручке?
Если да, и при этом есть много конкурирующих инициатив, которые нужно сравнивать друг с другом, — выбирайте RICE. Если нет — более простую матрицу «ценность против усилий».
Скоупите ли вы один релиз с фиксированным дедлайном?
MoSCoW создан именно для этого: он проводит чёткую границу между тем, что выйдет, а что нет, в конкретном окне.
Сколько людей должны согласиться с результатом?
Чем больше стейкхолдеров, тем полезнее числовой фреймворк вроде RICE, поскольку вокруг наглядного балла легче договориться, чем вокруг спора.
Что делает любой фреймворк честнее
- Reach (охват): сколько пользователей реально сталкиваются с этой проблемой, а не насколько громко о ней говорят самые заметные из них
- Impact (влияние): что изменится после выхода в терминах, которые бизнес уже отслеживает (удержание, конверсия, нагрузка на поддержку), а не расплывчатое «улучшает опыт»
- Effort (усилия): реальная инженерная оценка, а не догадка, сделанная без команды, которая будет это строить
- Confidence (уверенность): насколько вышеперечисленное измерено, а не предположено; пункты с низкой уверенностью и высоким влиянием заслуживают дешёвого шага валидации перед полноценной разработкой
Pros
- +Структурированный фреймворк делает компромиссы наглядными и защитимыми перед стейкхолдерами
- +Числовая оценка снижает влияние того, кто спорит громче или недавнее всех
- +Регулярный пересмотр баллов держит бэклог в соответствии с текущей реальностью
Cons
- −Любой фреймворк, построенный на оценках, наследует их точность
- −Переусложнение процесса подсчёта баллов может отнимать больше времени, чем сами решения, которые он поддерживает
- −Фреймворк не может разрешить реальное разногласие по стратегии — только структурировать спор
Фреймворк приоритизации не говорит вам, что правильно. Он последовательно показывает, что вы сами считаете правильным.
После того как функции ранжированы, этот рейтинг должен где-то храниться так, чтобы стейкхолдеры видели его, но он не превращался в обязательство; о том, как отражать приоритет, не давая лишних обещаний по датам, — в статье про продуктовые дорожные карты.
FAQ
FAQ
Какой фреймворк приоритизации функций лучший?+
Универсально лучшего фреймворка не существует. RICE хорошо подходит командам с надёжными данными об использовании, MoSCoW хорошо работает для скоупинга одного релиза, а простая матрица «ценность против усилий» подходит небольшим командам без инфраструктуры данных, необходимой для RICE.
Как часто нужно пересматривать приоритеты бэклога?+
Большинству продуктовых команд полезно пересчитывать приоритеты раз в две–четыре недели, а не постоянно. Постоянная перепроритизация создаёт хаос, а слишком редкая — позволяет устаревшим допущениям управлять решениями.
Должны ли запросы клиентов автоматически попадать в начало бэклога?+
Нет. Запрос одного клиента отражает лишь одну точку зрения. Приоритизация должна учитывать, сколько пользователей разделяют эту потребность, а не то, кто попросил громче или недавнее всех.
Похожие материалы
Расползание скоупа: почему оно происходит и как продуктовые команды его предотвращают
Расползание скоупа редко приходит как одно большое решение. Оно приходит как дюжина мелких, на первый взгляд разумных добавлений. Почему это происходит и какие конкретные механизмы контроля удерживают чётко определённый проект чётко определённым.
БизнесПродуктовые дорожные карты: что в них должно быть (и чего не должно)
Дорожная карта, забитая фиксированными датами, превращается в нарушенное обещание в тот момент, когда меняется реальность. Что дорожная карта должна на самом деле сообщать, что из неё стоит убрать и как сохранить её полезной и для стейкхолдеров, и для команды, которая всё строит.
БизнесВнутренние инструменты: зачем компании их строят и как определить масштаб первого
Внутренние инструменты заменяют таблицы и ручную координацию специально созданным ПО для вашей же команды. Как найти первого хорошего кандидата и определить его масштаб без переусложнения.
Newsletter
Продуктовые заметки без шума.
Редкие материалы о порталах, SaaS MVP и автоматизации.