Приоритизация и RICE: вопросы для собеседования (часть 2)
RICE, ICE, Impact/Effort matrix — фреймворки приоритизации помогают аналитику аргументировать, какие задачи важнее. На собеседовании дают список фич и просят расставить приоритеты с обоснованием. Аналитик, который умеет оцифровать потенциальный эффект инициативы, становится незаменимым партнёром для продакт-менеджера.
Вопросы 6–10 из 20
6В таблице `prioritization` один PM ставит `impact` 10, другой — 0.5, и результаты `RICE` становятся несопоставимыми. Что лучше сделать?
AРазрешить каждому использовать свою шкалу `impact`, главное — скорость
BСчитать `impact` только в деньгах, иначе нельзя
CЗафиксировать общую шкалу `impact` и примеры-анкоры (что значит низкий/средний/высокий), чтобы оценки были калиброваны
DПолностью убрать `impact` из модели и оставлять только `effort`
Ответ: Чтобы `RICE` работал, нужна единая шкала `impact` и калибровка между людьми.
Без общего языка оценка `impact` превращается в спор про числа, а не про ценность. Анкоры помогают: команда договаривается, что именно считается низким, средним и высоким эффектом, и приводит примеры. Тогда `RICE` лучше отражает относительный порядок инициатив, а не стиль оценивания конкретного человека. Дополнительно полезно периодически сверять оценки с фактом, чтобы улучшать точность.
7Команда считает `effort` в `RICE` только как чистые часы разработчика, не учитывая QA, аналитику, релиз и сопровождение. Как корректнее поступить?
AОставить как есть: `effort` должен быть только про разработчика
BОценивать `effort` как общие усилия команды (например, человеко-недели) и включать типичные работы вокруг фичи, чтобы сравнение было честным
CЗаменить `effort` на `impact`, чтобы не считать трудозатраты
DПоставить всем инициативам одинаковый `effort`, чтобы избежать споров
Ответ: `Effort` в `RICE` должен отражать реальную стоимость доставки, иначе `impact/effort` будет системно искажён.
Если учитывать только разработку, задачи с большим объёмом тестирования, аналитики или сложным релизом будут казаться дешевле, чем есть. Это приводит к плохой `prioritization`: команда берёт 'дешёвые' ставки, которые потом неожиданно раздуваются. Лучше договориться об общей единице (`units`) и оценивать полный `effort` доставки до продакшена. Тогда `RICE` становится более честным инструментом сравнения.
8У вас таблица для `prioritization`, где `RICE = reach * impact * confidence / effort`. За квартал три инициативы: A (reach 100 000, `impact` 2, `confidence` 0.8, `effort` 4), B (reach 50 000, `impact` 3, `confidence` 0.9, `effort` 3), C (reach 200 000, `impact` 1, `confidence` 0.4, `effort` 2). Какую инициативу выше поставить по `RICE`, если сравниваете только эти числа?
AИнициативу B
BИнициативу A
CИнициативу C
DНикакую: `RICE` не подходит для сравнения инициатив
Ответ: В `RICE` сравнивайте отношение `reach * impact * confidence` к `effort`.
Чтобы сравнить инициативы, достаточно грубо посчитать `RICE` по формуле. У B получится чуть выше, потому что высокий `impact` и `confidence` компенсируют меньший `reach`. A и C здесь дают близкие значения, потому что большой `reach` C сильно дисконтируется низким `confidence`. В реальной работе дополнительно важно, чтобы `reach` и `effort` были в одинаковых `units` и горизонте.
9У вас идея большого `bet` с потенциально высоким `impact`, но `confidence` низкий, потому что нет доказательств. Что лучше добавить в ближайший `roadmap` перед полноценной разработкой?
AСразу коммитнуть на полный `effort` и измерять потом
BОтложить на год, чтобы не тратить время
CПовысить `confidence` в таблице до 0.9, чтобы ставка поднялась
DСделать небольшой `bet` типа `spike`/прототип/эксперимент с `timebox`, чтобы проверить гипотезу и уточнить `impact` и `effort`
Ответ: Когда `confidence` низкий, полезно сделать маленький `bet` с `timebox`, чтобы снять ключевые риски.
Большие ставки с низким `confidence` часто 'съедают' много `effort`, прежде чем вы поймёте, работает ли гипотеза. `Spike` или прототип позволяют быстро собрать данные и обновить оценки `impact` и `effort`. Это может либо поднять `confidence` и оправдать масштабирование, либо сэкономить месяцы работы, если гипотеза не подтверждается. Такой подход делает `prioritization` динамичной и основанной на learning.
10Инициатива B по `RICE` выглядит топ-1, но она невозможна без платформенной задачи A (API), у которой низкий `RICE`. Как лучше поступить в `roadmap`?
AИгнорировать зависимость: делать B сразу, а A не делать
BВыкинуть B, потому что зависимость снижает `impact`
CУчитывать зависимость: включить A как часть `bet` для B (пересчитав `effort`/план), или явно запланировать A перед B и объяснить это в `prioritization`
DПоставить A и B параллельно в тот же спринт без обсуждения capacity
Ответ: `RICE` помогает сравнивать, но зависимости требуют явного `sequencing` и честного учёта `effort`.
Если B нельзя сделать без A, то реальная стоимость B включает часть `effort` A, а ценность A проявляется через enablement. Игнорирование зависимости приводит к невыполнимому `roadmap` и срывам сроков. Практика — либо объединить A и B в один `bet`, либо сделать A отдельной ставкой-пререквизитом с понятным объяснением. Так вы сохраняете связь `prioritization` с реальными ограничениями исполнения.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика