RICE Scoring с AI: как приоритизировать бэклог, когда всё кажется срочным

Без формализованной системы приоритизация превращается в политику. Побеждает тот, кто громче кричит на стендапе. Или тот, чей запрос пришёл от самого крупного клиента. Или тот, кто последним написал в Slack.

RICE scoring решает эту проблему числами. Четыре параметра, одна формула, объективный ранг каждой фичи. AI ускоряет процесс с нескольких часов ручной оценки до 15 минут автоматического скоринга.

Что такое RICE и почему он работает лучше интуиции

RICE придумал Шон Макбрайд из Intercom в 2016 году. Фреймворк состоит из четырёх компонентов:

Reach — сколько пользователей затронет фича за определённый период. Не “все” и не “много”. Конкретное число: 5000 пользователей в месяц, 300 новых регистраций в квартал, 100% активной базы.

Impact — насколько сильно фича повлияет на каждого затронутого пользователя. Шкала от 0.25 до 3:

• 3 = massive (полностью меняет опыт)
• 2 = high (заметное улучшение)
• 1 = medium (умеренное улучшение)
• 0.5 = low (минимальное улучшение)
• 0.25 = minimal (почти незаметно)

Confidence — уверенность в оценках Reach и Impact. Процент: 100% = есть данные, 80% = сильная гипотеза, 50% = интуиция, 20% = чистое предположение. Confidence работает как штраф за неопределённость. Фича с Impact 3 и Confidence 20% получит меньше баллов, чем фича с Impact 1 и Confidence 100%.

Effort — сколько человеко-месяцев займёт реализация. Единственный параметр в знаменателе. Чем больше Effort, тем ниже приоритет.

Формула:

RICE Score = (Reach × Impact × Confidence) / Effort

Пример: фича затрагивает 10 000 пользователей, Impact = 2, Confidence = 80%, Effort = 3 человеко-месяца.

RICE = (10000 × 2 × 0.8) / 3 = 5333

Сила RICE в том, что он заставляет декомпозировать “это важно” на четыре измеримых компонента. “Важная” фича с Reach 200 и Effort 6 проигрывает “мелкой” фиче с Reach 8000 и Effort 0.5. Числа не врут.

Почему ручной RICE-скоринг не приживается

RICE на бумаге прост. На практике команды сталкиваются с тремя проблемами.

Оценка Reach требует данных. Нужны аналитические отчёты, сегментация пользователей, прогнозы по росту. Продакт-менеджер тратит 20-40 минут на одну фичу, чтобы вытащить релевантные числа из Amplitude, Mixpanel или внутренних дашбордов.

Impact субъективен. Два продакта оценят одну и ту же фичу по-разному. Один поставит Impact 2, другой 1. Разница в два раза. Без структурированных критериев Impact превращается в ту же интуицию, от которой RICE должен был избавить.

Масштаб убивает мотивацию. Бэклог из 50 фич при 30 минутах на каждую — 25 часов работы. Три полных рабочих дня только на скоринг. Большинство команд скорят 10-15 фич и забрасывают процесс.

AI решает все три проблемы. LLM анализирует контекст продукта и предлагает обоснованные оценки. Не заменяет продакта, но берёт на себя первичный скоринг.

Промпт для AI-скоринга одной фичи

Начнём с базового промпта. Он работает с любой LLM (Claude, GPT-5.5, Gemini).

## Роль
Ты — senior product manager с 10-летним опытом приоритизации бэклогов
по RICE framework. Оценки всегда обоснованы данными, не интуицией.

## Контекст продукта
- Продукт: [название и краткое описание]
- MAU: [число активных пользователей в месяц]
- Основная метрика: [retention / revenue / activation / другая]
- Стадия: [pre-PMF / growth / scale]
- Средний размер команды на фичу: [число разработчиков]

## Задача
Оцени следующую фичу по RICE framework.

## Фича
Название: [название]
Описание: [2-3 предложения о том, что именно делает фича]
Целевой сегмент: [кто будет использовать]
Имеющиеся данные: [запросы от пользователей, метрики, результаты
исследований — всё, что есть]

## Формат ответа
Для каждого параметра RICE:
1. Оценка (число)
2. Обоснование (2-3 предложения)
3. Confidence в этой конкретной оценке (low/medium/high)

Итого:
- Reach: [число пользователей за квартал]
- Impact: [0.25 / 0.5 / 1 / 2 / 3]
- Confidence: [20% / 50% / 80% / 100%]
- Effort: [человеко-месяцы]
- RICE Score: [вычисленное значение]
- Рекомендация: одно предложение

Ключевой момент — блок “Контекст продукта”. Без него LLM оценивает фичу в вакууме. MAU в 1000 и MAU в 1 000 000 дают радикально разные Reach. Стадия pre-PMF vs scale меняет Impact. Контекст определяет качество скоринга.

Подробнее о том, как правильно передавать контекст AI-моделям, в статье про контекст-инжиниринг.

Промпт для батчевого скоринга бэклога

Скорить по одной фиче неэффективно. Реальная ценность RICE — в сравнении. Вот промпт для обработки всего бэклога за один вызов.

## Роль
Senior product manager. Задача — приоритизировать бэклог по RICE,
обеспечивая консистентность оценок между фичами.

## Контекст продукта
- Продукт: TaskFlow — B2B project management tool
- MAU: 45 000
- Основная метрика: Weekly Active Teams (retention)
- Стадия: growth (post-PMF, Series A)
- Команда: 8 разработчиков, 2 дизайнера
- Средний velocity: 1 фича за 2-4 недели

## Правила оценки
1. Reach считай в пользователях за квартал. Используй процент от MAU,
   если точных данных нет.
2. Impact оценивай по влиянию на основную метрику (Weekly Active Teams).
3. Confidence: 100% только при наличии данных из аналитики или
   исследований. 80% при наличии качественных сигналов (интервью,
   запросы в поддержку). 50% при наличии косвенных данных.
   20% — чистая гипотеза.
4. Effort в человеко-месяцах. Учитывай дизайн, разработку, QA.
5. Оценивай все фичи по одной шкале. Если фича A получила Impact 2,
   фича B не может получить Impact 2, если её влияние объективно меньше.

## Бэклог
[список фич — по одной строке каждая]

## Формат ответа
Markdown-таблица:
| # | Фича | Reach | Impact | Confidence | Effort | RICE Score |
Отсортируй по RICE Score (убывание).
После таблицы — 3 предложения: топ-3 рекомендации по порядку реализации.

Правило 5 — самое важное. Без явной инструкции о консистентности LLM склонна завышать Impact для каждой фичи отдельно. Когда модель видит весь бэклог разом, она калибрует оценки относительно друг друга.

Пример: бэклог из 10 фич с расчётами

Применим батчевый промпт к реальному бэклогу TaskFlow. Вот 10 фич, отправленных в Claude:

1. Канбан-доска с drag-and-drop — визуальное управление задачами
2. Интеграция с Slack — уведомления и создание задач из Slack
3. Гостевой доступ — приглашение внешних участников в проект
4. Тёмная тема — переключение light/dark mode
5. AI-саммари проекта — еженедельный автоотчёт по прогрессу
6. Шаблоны проектов — готовые структуры для типовых проектов
7. Gantt-диаграмма — визуализация таймлайнов и зависимостей
8. Мобильное приложение — нативные iOS и Android клиенты
9. Кастомные поля — пользовательские атрибуты для задач
10. Двухфакторная аутентификация — 2FA через TOTP

Результат скоринга:

#	Фича	Reach	Impact	Confidence	Effort	RICE Score
1	Интеграция с Slack	31 500	2	80%	2	25 200
2	Шаблоны проектов	27 000	2	80%	1	43 200
3	Канбан-доска	40 500	2	100%	3	27 000
4	Кастомные поля	22 500	2	80%	1.5	24 000
5	2FA	45 000	1	100%	0.5	90 000
6	Гостевой доступ	13 500	2	50%	2	6 750
7	Тёмная тема	36 000	0.5	100%	0.5	36 000
8	AI-саммари проекта	18 000	1	50%	2.5	3 600
9	Gantt-диаграмма	9 000	2	50%	4	2 250
10	Мобильное приложение	27 000	2	50%	8	3 375

Отсортировано по RICE Score:

Ранг	Фича	RICE Score
1	2FA	90 000
2	Шаблоны проектов	43 200
3	Тёмная тема	36 000
4	Канбан-доска	27 000
5	Интеграция с Slack	25 200
6	Кастомные поля	24 000
7	Гостевой доступ	6 750
8	AI-саммари проекта	3 600
9	Мобильное приложение	3 375
10	Gantt-диаграмма	2 250

Несколько наблюдений.

2FA выиграла не потому, что это “самая важная” фича. Reach = 100% базы (все пользователи затронуты), Confidence = 100% (требование безопасности, нет неопределённости), Effort = 0.5 (TOTP — стандартная интеграция). Низкий effort при максимальном reach дал рекордный скор.

Мобильное приложение заняло предпоследнее место. Impact = 2, Reach высокий, но Effort = 8 человеко-месяцев уничтожил скор. RICE наказывает ресурсоёмкие проекты. Это не значит “не делать”. Это значит “не сейчас”.

AI-саммари получило Confidence 50%. Фича выглядит привлекательно, но нет данных, подтверждающих спрос. RICE отфильтровал хайп от доказанной потребности.

Калибровка: когда AI ошибается

AI-скоринг не заменяет экспертизу. Он создаёт первое приближение, которое продакт корректирует. Типичные ошибки LLM при RICE-оценке:

Завышенный Reach. LLM по умолчанию оптимистична. Если промпт не содержит ограничений, модель посчитает, что фичу будут использовать “большинство пользователей”. Решение: в контексте указать реальные данные adoption rate для существующих фич. “Текущий adoption новых фич: 30-50% от MAU в первый квартал.”

Недооценённый Effort. LLM не знает о техдолге, легаси-архитектуре и организационных трениях. Решение: добавить в контекст данные о прошлых оценках vs реальных сроках. “Исторически наши оценки effort занижены на 40%. Умножай свою оценку на 1.4.”

Слепые зоны в Impact. LLM оценивает Impact на основе общих знаний о продуктах. Она не знает, что для конкретного продукта интеграция со Slack — ключевое конкурентное преимущество. Решение: описать стратегический контекст. “Мы проигрываем сделки из-за отсутствия Slack-интеграции. 23% потерянных лидов упоминали это как причину отказа.”

Правило: AI делает первый проход. Продакт ревьюит и корректирует. Финальное решение остаётся за человеком.

Продвинутый промпт: RICE с учётом стратегии

Базовый RICE не учитывает стратегический контекст. Фича с высоким RICE Score может противоречить квартальным OKR. Расширенный промпт решает эту проблему.

## Роль
VP of Product. Приоритизируешь бэклог с учётом квартальной стратегии.

## Стратегический контекст
- Квартальные OKR:
  1. Увеличить retention Week 8 с 34% до 42%
  2. Выйти на enterprise-сегмент (компании 500+ сотрудников)
  3. Снизить support load на 20%
- Стратегические ставки: enterprise readiness, self-serve onboarding
- Антицели: НЕ расширять мобильный опыт в этом квартале

## Задача
Рассчитай RICE Score для каждой фичи. Затем добавь столбец
"Strategic Alignment" (0-5), где:
- 5 = напрямую двигает OKR
- 3 = косвенно связана с OKR
- 1 = не связана с OKR
- 0 = противоречит антицелям

Финальный ранг = RICE Score × (1 + Strategic Alignment / 10)

## Формат
Таблица с колонками: Фича | RICE Score | Strategic Alignment |
Adjusted Score | Ранг

Множитель (1 + Strategic Alignment / 10) даёт бонус от 0% до 50% за стратегическое соответствие. Фича с RICE 20 000 и Strategic Alignment 5 получает Adjusted Score 30 000. Фича с RICE 25 000 и Strategic Alignment 0 остаётся на 25 000. Стратегия корректирует, но не переворачивает математику.

Автоматизация RICE-скоринга через API

Ручной запуск промптов масштабируется плохо. Полная автоматизация через API работает так:

Шаг 1: Структурированный бэклог

Бэклог хранится в JSON. Каждая фича содержит поля, необходимые для скоринга.

{
  "product_context": {
    "name": "TaskFlow",
    "mau": 45000,
    "primary_metric": "weekly_active_teams",
    "stage": "growth",
    "team_size": 10,
    "avg_feature_adoption": 0.35,
    "effort_multiplier": 1.4
  },
  "features": [
    {
      "id": "F-101",
      "name": "Slack Integration",
      "description": "Bidirectional sync: notifications to Slack, task creation from Slack",
      "segment": "all_teams",
      "signals": [
        "23% of churned leads mentioned lack of Slack integration",
        "Top-3 requested feature in NPS surveys (n=340)"
      ]
    }
  ]
}

Шаг 2: Скрипт для батчевого скоринга

import json
from anthropic import Anthropic

client = Anthropic()

def score_backlog(backlog_path: str) -> dict:
    with open(backlog_path) as f:
        backlog = json.load(f)

    system_prompt = """You are a senior product manager scoring features
using RICE framework. Return valid JSON only."""

    user_prompt = f"""
Score each feature using RICE framework.

Product context:
{json.dumps(backlog['product_context'], indent=2)}

Features to score:
{json.dumps(backlog['features'], indent=2)}

Rules:
- Reach: users per quarter, based on MAU and segment size
- Impact: 0.25 / 0.5 / 1 / 2 / 3
- Confidence: 0.2 / 0.5 / 0.8 / 1.0
- Effort: person-months, multiply by {backlog['product_context']['effort_multiplier']}
- Score = (Reach * Impact * Confidence) / Effort

Return JSON array:
[{{
  "id": "F-101",
  "name": "...",
  "reach": 0,
  "impact": 0,
  "confidence": 0,
  "effort": 0,
  "score": 0,
  "reasoning": "..."
}}]
"""

    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=4096,
        system=system_prompt,
        messages=[{"role": "user", "content": user_prompt}]
    )

    return json.loads(response.content[0].text)


def rank_features(scored: list) -> list:
    return sorted(scored, key=lambda f: f["score"], reverse=True)


if __name__ == "__main__":
    scored = score_backlog("backlog.json")
    ranked = rank_features(scored)

    print(f"{'Rank':<5} {'Feature':<30} {'Score':>10}")
    print("-" * 47)
    for i, f in enumerate(ranked, 1):
        print(f"{i:<5} {f['name']:<30} {f['score']:>10,.0f}")

Шаг 3: Интеграция с трекером задач

Скор записывается обратно в Jira, Linear или Notion через API. Пример для Linear:

def sync_scores_to_linear(scored_features: list):
    for feature in scored_features:
        # Обновить кастомное поле "RICE Score" в Linear
        update_issue(
            issue_id=feature["id"],
            custom_fields={
                "rice_score": feature["score"],
                "rice_reach": feature["reach"],
                "rice_impact": feature["impact"],
                "rice_confidence": feature["confidence"],
                "rice_effort": feature["effort"]
            }
        )

Пайплайн: бэклог обновился в трекере → скрипт забирает новые фичи → LLM скорит → результат записывается обратно → дашборд показывает актуальный ранг.

Распространённые ошибки при RICE-скоринге

Смешивание единиц Reach. Одна фича оценена в “пользователях”, другая в “компаниях”, третья в “запросах”. Reach должен измеряться в одних единицах по всему бэклогу. Пользователи за квартал — оптимальный вариант для B2C. Команды или аккаунты — для B2B.

Impact без привязки к метрике. “Фича улучшит UX” — не оценка Impact. “Фича увеличит activation rate на 5-8% для нового пользователя” — оценка Impact. Промпт должен содержать конкретную метрику, к которой привязан Impact.

Confidence 80% по умолчанию. Команды ставят Confidence 80% всем фичам, потому что 100% кажется самонадеянным, а 50% — недостаточным. Результат: Confidence перестаёт влиять на скор. Решение: жёсткие критерии. 100% = A/B тест или аналитика. 80% = качественные интервью (n > 10). 50% = запросы в поддержку. 20% = “мне кажется”.

Игнорирование Effort на дизайн и QA. Effort = только разработка. Забыли дизайн, QA, документацию, миграцию данных. Effort в RICE — это полный цикл от начала работы до релиза.

RICE как единственный инструмент. RICE не учитывает зависимости между фичами, регуляторные требования (GDPR, SOC2) и технические предусловия. Фича с RICE Score 100 бесполезна, если для неё нужна инфраструктурная задача с RICE Score 10. Используйте RICE для ранжирования, но финальный роадмап строится с учётом зависимостей.

Однократный скоринг. RICE Score устаревает. MAU растёт, приоритеты меняются, появляются новые данные. Рескоринг раз в квартал — минимум. С AI-автоматизацией можно делать рескоринг при каждом обновлении бэклога.

Шаблон для быстрого старта

Минимальный набор для запуска RICE-скоринга с AI за 15 минут:

1. Описать контекст продукта (5 полей: название, MAU, метрика, стадия, размер команды)
2. Выгрузить бэклог в текстовый формат (название + описание + имеющиеся данные для каждой фичи)
3. Использовать батчевый промпт из этой статьи
4. Отправить в LLM, получить таблицу с ранжированием
5. Ревьюить топ-5 и bottom-5, скорректировать очевидные ошибки

Через 2-3 итерации промпт калибруется под конкретный продукт. Оценки становятся точнее, потому что контекст обогащается историческими данными: реальный adoption rate, фактический effort vs оценка, обратная связь после релиза.

Итог

RICE scoring превращает “всё важно” в ранжированный список с обоснованиями. AI убирает из этого процесса главный bottleneck — время на ручную оценку каждой фичи.

Формула остаётся простой: (Reach × Impact × Confidence) / Effort. Промпты из этой статьи обеспечивают консистентные оценки по всему бэклогу. Автоматизация через API делает рескоринг дешёвым и регулярным.

Пять фич, один промпт, 15 минут. Этого достаточно, чтобы проверить, совпадают ли AI-оценки с экспертным мнением. После калибровки процесс масштабируется на весь бэклог и перезапускается каждый квартал без дополнительных усилий.

---

Нужна помощь с приоритизацией бэклога? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.

FAQ

Как оценивать фичи без исторических данных — новые рынки или непроверенные идеи?

Ставьте Confidence 20% и явно документируйте это. Спекулятивная фича с Impact 3 и Confidence 20% наберёт столько же баллов, сколько валидированная фича с Impact 1 и Confidence 60% — в районе 1800–2700 для типичного бэклога. Это не скрывает неопределённость, а количественно её выражает. Если фича с Confidence 20% всё равно входит в топ-5, это сигнал провести небольшой discovery-спринт для повышения уверенности перед полноценной разработкой.

Работает ли RICE для B2B-продуктов, где Reach — это компании, а не пользователи?

Да, но нужно выбрать одну единицу и придерживаться её по всему бэклогу. Для B2B используйте аккаунты или команды как единицу Reach — «1200 активных аккаунтов» — а не отдельных пользователей. Impact должен отражать бизнес-результаты на уровне аккаунта (активация, расширение, снижение оттока), а не пользовательский опыт. Смешение единиц (одни фичи оценены в пользователях, другие в аккаунтах) разрушает сопоставимость и делает ранжирование бессмысленным.

Что делать, если RICE-ранжирование противоречит стратегическому роадмапу?

Используйте мультипликатор Strategic Alignment из статьи, а не ручное переопределение скора. Если высокорейтинговая фича противоречит квартальным OKR, низкий Strategic Alignment (0–1) естественно опустит её в итоговом ранжировании. Ручная корректировка подрывает доверие к системе — как только люди поймут, что PM может продвинуть любую фичу, цифры перестанут иметь значение и RICE превратится в декорацию.