Приоритизация и RICE: вопросы для собеседования (часть 3)

RICE, ICE, Impact/Effort matrix — фреймворки приоритизации помогают аналитику аргументировать, какие задачи важнее. На собеседовании дают список фич и просят расставить приоритеты с обоснованием. Аналитик, который умеет оцифровать потенциальный эффект инициативы, становится незаменимым партнёром для продакт-менеджера.

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиВоронки, когорты и retentionРост, активация и онбордингИнструментация и качество данныхМонетизация и юнит-экономикаNorth Star, KPI и иерархия метрикПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD

Вопросы 1115 из 20

11Инициатива X имеет очень высокий `RICE` за счёт большого `reach`, но `confidence` 0.2 (гипотеза без данных). Инициатива Y имеет чуть ниже `RICE`, но `confidence` 0.8 и понятный `effort`. Какое решение лучше отражает зрелую `prioritization`?
AПоставить Y в `build`, а для X запланировать короткий `discovery`/эксперимент, чтобы поднять `confidence` перед большим `bet`
BИгнорировать `confidence` и всегда выбирать максимальный `RICE`
CУмножить `effort` X на 0.2, чтобы компенсировать низкий `confidence`
DСразу исключить X навсегда, потому что `confidence` не равен 1
Ответ: Низкий `confidence` — сигнал сначала сделать небольшой `bet` на проверку, а не сразу коммититься в полный `effort`.

Высокий скор по `RICE` при низком `confidence` часто означает, что потенциальный выигрыш большой, но вы можете ошибаться в `reach` или `impact`. В такой ситуации полезно сделать короткий `discovery`-шаг: прототип, интервью, A/B, чтобы получить данные и обновить `confidence`. Параллельно можно реализовать инициативу Y, где ценность более предсказуема. Это снижает риск и делает `roadmap` устойчивее к сюрпризам.

12Вы запланировали инициативу как средний `bet`. После первой недели выяснилось, что `effort` выше, а ожидаемый `impact` ниже, и `confidence` в успех упала. Как правильнее поступить?
AПродолжать до конца, потому что `roadmap` нельзя менять
BСкрыть новую информацию, чтобы не расстраивать стейкхолдеров
CУвеличить оценку `impact`, чтобы оправдать затраты
DПересчитать `prioritization` с учётом новых данных, обсудить варианты (урезать scope, остановить, разбить `bet`) и обновить `roadmap` прозрачно
Ответ: Хорошая `prioritization` обновляется при learning: пересчитайте `impact/effort` и `confidence` и адаптируйте `roadmap`.

Если новые данные говорят, что ставка хуже ожиданий, продолжать 'по инерции' — это потеря `opportunity cost`. Правильный шаг — пересмотреть прогноз: что поменялось в `impact`, сколько реально `effort`, какие риски выявились и как это влияет на `confidence`. Иногда помогает декомпозиция: сделать меньший `bet` с чётким outcome, а остальное отложить. Прозрачное обновление `roadmap` повышает доверие и снижает риск больших провалов.

13В `prioritization` попала задача 'уменьшить время сборки и деплоя'. У неё нет прямого `reach` на пользователей, но она может ускорить delivery и снизить риск инцидентов. Как лучше учесть такую инициативу рядом с фичами в `roadmap`?
AПоставить `reach` равным 0, тогда она автоматически уйдёт в конец
BОписать `impact` через прокси (например, снижение будущего `effort`, снижение риска), задать `confidence` по данным и/или выделить отдельный трек в `roadmap`, не выдумывая огромный `reach`
CВсегда давать техдолгу максимальный `impact`, чтобы его точно взяли
DНе включать техдолг в `prioritization`, потому что он не измерим
Ответ: Тех-инициативы можно оценивать через прокси-`impact` и честный `confidence`, а иногда держать отдельный трек в `roadmap`.

Задачи про ускорение поставки часто дают ценность не через `reach`, а через снижение затрат и рисков. Их можно оценивать через ожидаемое уменьшение будущего `effort`, снижение частоты инцидентов или ускорение time-to-market. Важно не "рисовать" большой `reach` ради формулы, иначе модель перестанет быть честной. Отдельный трек для `platform/tech` помогает не смешивать несопоставимые ставки, но всё равно требует приоритизации по ценности.

14Вы оцениваете `reach` для инициативы «запустить сообщение в `email` и `push`». В `email` можно достучаться до 200 тыс. пользователей, в `push` — до 150 тыс., но 80 тыс. получают и то, и другое. Как корректнее оценить `reach` для `RICE`?
AСложить 200 тыс и 150 тыс и получить 350 тыс `reach`
BПосчитать `reach` как `unique` охват: 200 тыс + 150 тыс - 80 тыс, чтобы не двойно считать `overlap`
CВзять только больший канал и считать `reach` 200 тыс
DПоставить `confidence` 0 и не считать `reach` вообще
Ответ: Для `reach` важно учитывать `overlap`, иначе вы завышаете охват и искажаете `RICE`.

Если один и тот же пользователь попадает в два канала, сложение охватов без `dedup` даёт завышение. В `RICE` это может поднять инициативу выше других просто из-за ошибки в подсчёте `reach`. Корректнее считать `unique` охват как объединение аудиторий и вычитать `overlap`. Если точный `overlap` неизвестен, можно задать диапазон и снизить `confidence`.

15Для инициативы вы не уверены в `reach`: оценки от 50 тыс. до 300 тыс. в месяц, а `effort` — примерно 2 недели. Какой подход к `prioritization` наиболее корректен?
AПосчитать `RICE` как диапазон (оптимистичный/базовый/пессимистичный), сделать `sensitivity` и проверить, меняется ли порядок при разумных границах (`bounds`)
BВзять максимальный `reach` и поставить `confidence` 1, чтобы не тормозить
CВзять среднее и считать, что неопределённости нет
DНе использовать `RICE` никогда, если есть разброс
Ответ: При неопределённости лучше сравнивать устойчивость решения: диапазон `RICE` и `sensitivity` важнее одной цифры.

Одна точка оценки может создать иллюзию точности, хотя реальность лежит в диапазоне. Если инициатива остаётся в топе даже в пессимистичном сценарии, решение более устойчиво. Если порядок легко меняется, это сигнал: либо улучшать `confidence` через `discovery`, либо выбирать ставки, которые выигрывают при разных границах (`bounds`). Такой подход помогает избегать ложно точных оценок в `roadmap`.

1234

Хотите тренировать интерактивно?

В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.

Тренировать в Telegram

Другие темы: Продуктовая аналитика

A/B-тесты в продуктовой аналитикеОсновы продуктовой аналитикиВоронки, когорты и retentionРост, активация и онбордингИнструментация и качество данныхМонетизация и юнит-экономикаNorth Star, KPI и иерархия метрикПостановка задачи и PRDСегментация и позиционированиеСторителлинг и alignmentИсследование пользователей и JTBD