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

> RICE framework с AI-автоматизацией: промпты для скоринга Reach, Impact, Confidence, Effort. Учебный пример приоритизации бэклога из 10 фич, шаблоны и автоматизация через LLM.
> Author: Roman Belov · Published: 2026-04-23 · Source: https://futurecraft.pro/ru/blog/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).

```markdown
## Роль
Ты — 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-моделям, в статье про [контекст-инжиниринг](/ru/blog/context-engineering-guide/).

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

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

```markdown
## Роль
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 фич:

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. Расширенный промпт решает эту проблему.

```markdown
## Роль
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. Каждая фича содержит поля, необходимые для скоринга.

```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: Скрипт для батчевого скоринга

```python
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:

```python
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](https://belov.works).*