Приоритизация и RICE: вопросы для собеседования (часть 2)
RICE, ICE, Impact/Effort matrix — фреймворки приоритизации помогают аналитику аргументировать, какие задачи важнее. На собеседовании дают список фич и просят расставить приоритеты с обоснованием. Аналитик, который умеет оцифровать потенциальный эффект инициативы, становится незаменимым партнёром для продакт-менеджера.
Вопросы 6–10 из 20
6При приоритизации инициатив один менеджер ставит влияние 10, другой — 0.5, и итоговые оценки `RICE` становятся несопоставимыми. Что лучше сделать?
AКаждому оценивающему оставить личную шкалу влияния: важна скорость, а не сопоставимость
BСчитать влияние только в деньгах: иначе сравнение между командами невозможно
CЗафиксировать общую шкалу влияния и примеры-якоря для низкого, среднего и высокого уровней
DУбрать оценку влияния из модели и оставить только трудозатраты для упрощения процесса
Ответ: Чтобы `RICE` работал, нужна единая шкала влияния и калибровка между людьми.
Без общего языка оценка влияния превращается в спор про числа, а не про ценность. Якоря помогают: команда договаривается, что именно считается низким, средним и высоким эффектом, и приводит примеры. Тогда `RICE` лучше отражает относительный порядок инициатив, а не стиль оценивания конкретного человека. Дополнительно полезно периодически сверять оценки с фактом, чтобы улучшать точность.
Подробный разбор → 7Команда считает трудоёмкость в `RICE` только как чистые часы разработчика, не учитывая QA, аналитику, релиз и сопровождение. Как корректнее поступить?
AСчитать только часы разработчика: упрощает оценку и быстрее согласуется с командой инженеров
BПоставить инициативам одинаковую трудоёмкость для упрощения сравнения по влиянию на метрику
CОценивать общие усилия команды (например, человеко-недели) с учётом QA, аналитики и релиза до продакшена
DЗаменить трудоёмкость на оценку влияния, чтобы сравнивать инициативы только по ожидаемому эффекту
Ответ: Трудоёмкость в `RICE` должна отражать реальную стоимость доставки до продакшена, иначе соотношение влияния и затрат будет системно искажено.
Если учитывать только разработку, задачи с большим объёмом тестирования, аналитики или сложным релизом будут казаться дешевле, чем есть. Это приводит к плохой приоритизации: команда берёт «дешёвые» ставки, которые потом неожиданно раздуваются. Лучше договориться об общей единице измерения и оценивать полную трудоёмкость доставки до продакшена. Тогда `RICE` становится более честным инструментом сравнения инициатив.
Подробный разбор → 8У вас таблица для приоритизации, где `RICE = охват · влияние · уверенность / трудозатраты`. За квартал три инициативы: A (охват 100 000, влияние 2, уверенность 0.8, трудозатраты 4), B (охват 50 000, влияние 3, уверенность 0.9, трудозатраты 3), C (охват 200 000, влияние 1, уверенность 0.4, трудозатраты 2). Какую инициативу выше поставить по `RICE`, если сравниваете только эти числа?
AИнициативу B
BИнициативу A
CИнициативу C
DНикакую: метод `RICE` не подходит для сравнения инициатив между собой
Ответ: В `RICE` сравнивайте отношение охват · влияние · уверенность к трудозатратам.
Чтобы сравнить инициативы, достаточно грубо посчитать `RICE` по формуле. У B получится чуть выше, потому что высокое влияние и уверенность компенсируют меньший охват. A и C здесь дают близкие значения, потому что большой охват C сильно дисконтируется низкой уверенностью. В реальной работе дополнительно важно, чтобы охват и трудозатраты были в одних единицах и на одном горизонте.
Подробный разбор → 9У вас идея большой ставки с потенциально высоким влиянием, но уверенность низкая, потому что нет доказательств. Что лучше добавить в ближайший роадмап перед полноценной разработкой?
AЗафиксировать полные трудозатраты и взять задачу в спринт целиком, измерения и проверку гипотезы оставить на этап после запуска фичи
BОтложить инициативу примерно на год, чтобы не тратить время команды и вернуться к идее, когда уверенность вырастет сама собой
CСделать небольшую ставку: спайк, прототип или быстрый эксперимент с ограничением по времени для проверки гипотезы и уточнения влияния
DПоднять уверенность в скоринговой таблице до 0.9 вручную, чтобы ставка автоматически поднялась в приоритизации над скромными задачами
Ответ: Когда уверенность низкая, полезно сделать маленькую ставку с ограничением по времени, чтобы снять ключевые риски.
Большие ставки с низкой уверенностью часто съедают много трудозатрат, прежде чем вы поймёте, работает ли гипотеза. Спайк или прототип позволяют быстро собрать данные и обновить оценки влияния и трудозатрат. Это может либо поднять уверенность и оправдать масштабирование, либо сэкономить месяцы работы, если гипотеза не подтверждается. Ручное завышение уверенности подменяет данные мнением, полный коммит без проверки увеличивает риск, а откладывание на год не двигает понимание гипотезы вперёд.
Подробный разбор → 10Инициатива B по `RICE` выглядит топ-1, но она невозможна без платформенной задачи A (API), у которой низкий `RICE`. Как лучше поступить в роадмапе?
AИгнорировать зависимость и делать B сразу, а A не делать совсем, потому что у A низкий `RICE` и платформенные задачи редко окупаются в текущем квартале
BУчитывать зависимость: включить A как часть ставки для B (пересчитав трудозатраты и план), либо явно запланировать A перед B и объяснить это в приоритизации
CВыкинуть B из плана, потому что любая зависимость снижает влияние и делает результат непредсказуемым, а команда лучше потратит время на независимые инициативы
DПоставить A и B параллельно в один спринт без обсуждения ёмкости команды, чтобы не задерживать запуск B и не растягивать весь план на следующий квартал
Ответ: `RICE` помогает сравнивать, но зависимости требуют явной последовательности и честного учёта трудозатрат пререквизита.
Если B нельзя сделать без A, то реальная стоимость B включает часть трудозатрат A, а ценность A проявляется через разблокировку B. Игнорирование зависимости приводит к невыполнимому плану и срывам сроков. Практичный подход — либо объединить A и B в одну ставку, либо сделать A отдельной задачей-пререквизитом с понятным объяснением. Так приоритизация остаётся связанной с реальными ограничениями исполнения; параллельный запуск без учёта ёмкости команды — типичная ошибка.
Подробный разбор → Другие темы: Продуктовая аналитика