Вы на ранней стадии: данных мало, оценить охват сложно, но нужно быстро ранжировать 15 идей. В команде используют ICE = impact * confidence / effort. Когда ICE часто удобнее, чем RICE?

AКогда нужно посчитать точные квантили по ключевой метрике и сравнивать инициативы с уровнем статистической значимости
BКогда есть надёжные данные по охвату и вы хотите получить максимально детализированный скоринг с учётом всех факторов
CКогда хочется полностью убрать обсуждение рисков и неопределённости из обсуждения, оставив только формальный итоговый балл
DКогда охват оценить трудно и нужен быстрый грубый порядок по влиянию, уверенности и трудозатратам без иллюзии точности
Правильный ответ. ICE удобен, когда нет надёжной оценки охвата, но всё равно нужен быстрый порядок по влиянию и трудозатратам с учётом уверенности.

Разбор

На ранних этапах охват часто приходится угадывать, и точность оценки будет низкой. ICE позволяет не притворяться точными, а сфокусироваться на сути: ожидаемое влияние, разумность гипотезы и трудозатраты. Такой скоринг полезен как инструмент обсуждения и фильтрации идей. Позже, когда появятся стабильные данные по охвату, можно перейти к RICE; варианты про «точные квантили» или «убрать неопределённость» противоречат самому смыслу быстрой приоритизации.

Проверь себя · 1/2разбор после ответа
Команда считает трудоёмкость в RICE только как чистые часы разработчика, не учитывая QA, аналитику, релиз и сопровождение. Как корректнее поступить?
Тренировать продукт в Telegram

Ещё вопросы по теме «Приоритизация и RICE»