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

Приоритизация фич: система и методология

Приоритизация — это одна из главных задач Product Manager. Расскажу о методике, которая позволяет принимать обоснованные решения в условиях ограниченных ресурсов.

Правило 1: Не всё вдруг

Основной принцип:

• Нельзя делать всё одновременно
• Ресурсы (люди, время, деньги) ограничены
• Выбор приоритетов = выбор, от чего отказаться

Я всегда говорю команде: "Приоритизация — это искусство сказать "нет"".

Фреймворк приоритизации

Я использую комбинированный подход из нескольких методик:

1. RICE (Reach, Impact, Confidence, Effort)

Каждую фичу оцениваю по четырём параметрам:

Reach (охват)

• Сколько пользователей это коснётся?
• Умножаю на период (неделя/месяц)
• Пример: 100 тыс. пользователей = 100
• 10 тыс. пользователей = 10

Impact (влияние)

• Как сильно это повлияет на каждого пользователя?
• Оцениваю по шкале:
  • Massive (3x результаты) = 3
  • High (2x результаты) = 2
  • Medium (1.5x) = 1
  • Low (минимальное влияние) = 0.5
  • Minimal = 0.25

Confidence (уверенность)

• Насколько я уверен в этих прогнозах?
• High confidence = 100% (есть данные)
• Medium = 80% (основано на анализе)
• Low = 50% (гипотеза)

Effort (затраты)

• Сколько недель разработки нужно?
• Обычно 1-6 недель

Формула:

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

Пример расчёта:

Фича A (быстрый повторный заказ):
- Reach = 50 (50% активных пользователей)
- Impact = 2 (удваивает частоту заказов)
- Confidence = 100 (есть данные)
- Effort = 4 недели
- Score = (50 × 2 × 100) / 4 = 2500

Фича B (интеграция с новой платёжной системой):
- Reach = 100 (все пользователи)
- Impact = 1 (небольшое удобство)
- Confidence = 70 (неясная конверсия)
- Effort = 8 недель
- Score = (100 × 1 × 70) / 8 = 875

Фича A выше приоритет.

2. ICE (Impact, Confidence, Ease)

Упрощённый вариант для быстрой оценки:

ICE Score = Impact × Confidence / Effort

Оцениваю каждый параметр от 1 до 10:

• Impact: как это повлияет на бизнес? (1-10)
• Confidence: уверен ли я? (1-10)
• Ease: насколько легко реализовать? (1-10)

Использую это для: быстрой оценки на планёрке

3. Qualitative факторы

Не всё можно измерить числами. Также учитываю:

Стратегические приоритеты:

• Входит ли в квартальные OKR?
• Поддерживает ли это наше видение?
• Это инвестиция в будущее?

Технические долги:

• Блокирует ли это другие фичи?
• Нужно ли это для масштабирования?
• Есть ли технические риски?

Рыночные окна:

• Конкурент запустил похожее?
• Есть сезонность?
• Есть ли срочные customer requests?

Здоровье продукта:

• Нужны ли баги-фиксы?
• Есть ли проблемы с производительностью?
• Нужна ли рефакторинг?

Процесс приоритизации

Этап 1: Сбор идей (неделя 1)

• От пользователей (feedback, support requests)
• От команды (идеи разработчиков, дизайнеров)
• От бизнеса (цели, гипотезы)
• От рынка (анализ конкурентов)

Этап 2: Валидация (неделя 1-2)

• Есть ли спрос на эту фичу?
• Сколько пользователей это попросили?
• Какой потенциал ROI?
• Технически ли это возможно?

Этап 3: Оценка (неделя 2)

• Применяю RICE/ICE
• Обсуждаю с tech lead на estimate effort
• Уточняю Reach и Impact с аналитикой

Этап 4: Обсуждение с командой (неделя 2-3)

• Презентирую scores
• Слушаю контр-аргументы
• Выясняю неизвестные факторы
• Приходим к консенсусу

Этап 5: Финальный приоритет (неделя 3)

• Публикую roadmap на квартал
• Объясняю reasoning
• Оставляю место для срочных items

Структура backlog

Я разделяю фичи на три группы:

1. NOW (Next Sprint/Week) — 40% ёмкости
   - Наиболее критичные
   - RICE score > 1000
   - Готовы к разработке

2. NEXT (Next Quarter) — 40% ёмкости
   - Important но не срочные
   - RICE score 500-1000
   - Нужна валидация

3. FUTURE (Next 6+ months) — 20% ёмкости
   - Nice-to-have
   - RICE score < 500
   - Требуют research

Обработка срочных requests

Даже в приоритизированном плане бывают срочные:

• Production bugs: исправляю немедленно
• Critical customer issues: макс 48 часов
• Compliance требования: макс 1 неделя
• Стратегические задачи CEO: обсуждаю impact

Правило P.25: Если фича попадает в срочные, я вытаскиваю из backlog фичу с меньшим score.

Коммуникация приоритетов

Я регулярно объясняю:

1. Для разработчиков:

   • Почему это фича в roadmap
   • Какой impact ожидается
   • Зачем нам это нужно

2. Для бизнеса:

   • Как это поддерживает OKR
   • Какой timeline
   • Какой expected revenue

3. Для пользователей:

   • Что мы строим
   • Зачем это нужно
   • Когда они это получат

Мониторинг и корректировка

Еженедельно проверяю:

• Все ли идёт по плану?
• Появились ли новые данные, которые меняют приоритеты?
• Есть ли неожиданные блокеры?

Раз в месяц пересматриваю:

• Текущие метрики
• Feedback от пользователей
• Компетиторский ландшафт
• Корректирую RICE scores при необходимости

Типичные ошибки приоритизации

❌ Что я избегаю:

1. Приоритизация по громкости: заказчик кричит громче — не значит, что это важнее
2. Приоритизация по новизне: новая идея — не значит, что она лучше
3. Приоритизация по личным предпочтениям: мне нравится — не значит, что это нужно пользователям
4. Переделанная приоритизация: меняю приоритеты каждый день — хаос
5. Добавление всех идей: backlog должен быть управляемым, не 100+ items

Вывод

Приоритизация — это балансирование между данными и интуицией, стратегией и тактикой, клиентом и бизнесом. Нет идеального способа, но структурированный подход (RICE + qualitative) позволяет:

• Принимать обоснованные решения
• Объяснять выбор команде
• Адаптироваться к изменениям
• Максимизировать impact на ограниченных ресурсах

И главное: умение сказать "нет" — это суперсила Product Manager.