RICE-приоритизация бэклога

Приоритизируй бэклог через RICE:

{{backlog}}

Формула: RICE = (Reach × Impact × Confidence) / Effort

Шаги

1. Reach — сколько людей это коснётся в выбранный период

• Период: квартал / месяц / год — единый для всех
• Реальные цифры (не "много"). Берём из аналитики
• Пример: 12 000 активных юзеров в квартал

2. Impact — насколько изменится опыт каждого

• 3 — массивный (фундаментально лучше)
• 2 — большой
• 1 — средний
• 0.5 — мелкий
• 0.25 — минимальный

Калибруй: фича которая решает топ-1 жалобу = 2-3. Cosmetic = 0.25-0.5

3. Confidence — насколько уверен в Reach и Impact

• 100% — есть данные / тесты
• 80% — сильная гипотеза, аналоги работают
• 50% — догадка, нужна валидация
• < 50% — не приоритизируй, сначала research

4. Effort — в "person-months" или "person-weeks"

• Включает design, dev, QA, release
• Реалистично, не «один спринт = 2 недели»
• Если > 3 месяцев — разбей на части

5. Посчитай

Сортируй по RICE.

6. Sanity-check

После сортировки — проверь интуицию:

• Если число говорит А, а интуиция говорит Б — что не так? Часто это input.
• "Этого не может быть в топе" → проверь Effort (часто недооценен) или Impact (переоценен)

7. Не-RICE факторы (учитывай отдельно)

• Стратегическая ставка — может быть низкий RICE, но открывает новые рынки
• Технический долг — снижает Effort будущих фич
• Security / compliance — обязательно вне зависимости от RICE
• Risk reduction — например, миграция БД

Сделай отдельный bucket "Strategic" — там 20% capacity, RICE не правит.

Анти-паттерны

• Confidence всегда 100% — никаких гипотез
• Effort недооценен — RICE завышен
• Reach = "все юзеры" — слишком грубо
• Спор о приоритете без обсуждения чисел

В конце

• Таблица с RICE
• Топ-5 рекомендованных к работе
• Что отложить и почему
• Что нужно research'нуть перед оценкой