Как преоритизируешь требования?

Приоритизация требований

Приоритизация — это основа эффективного управления проектом. За 10+ лет я разработал комплексный подход, который учитывает бизнес-ценность, технические ограничения и человеческий фактор.

Основной принцип: Value vs Effort

Каждое требование оцениваю по двум осям:

• Ценность для бизнеса (High/Medium/Low)
• Трудозатраты (Low/Medium/High)

Приоритеты расставляю так:

1. High Value + Low Effort → Делаем немедленно (Quick Wins)
2. High Value + Medium Effort → В план на следующие спринты (Major Projects)
3. Medium Value + Low Effort → Когда будет время (Fill-Ins)
4. Low Value + High Effort → Откладываем или отклоняем (Time Wasters)

Методология RICE (Reach, Impact, Confidence, Effort)

Использую расширенный подход, когда нужно выбрать между несколькими проектами одного уровня ценности:

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

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

Проект 1 — "Оптимизация скорости загрузки приложения"

• Reach: 10,000 пользователей в месяц = 10
• Impact: каждый пользователь использует приложение 5+ раз, быстрая загрузка увеличит retention на 15% = 3 (high)
• Confidence: у нас есть данные о загрузке, риск низкий = 100%
• Effort: 40 часов разработки = 5
• RICE Score = (10 × 3 × 1) / 5 = 6.0

Проект 2 — "Новая экспортная функция в Excel"

• Reach: 500 power-users = 0.5
• Impact: решает боль 10% нашей аудитории = 2
• Confidence: требование не полностью ясно = 60%
• Effort: 60 часов = 6
• RICE Score = (0.5 × 2 × 0.6) / 6 = 0.1

Проект 1 имеет RICE 6.0, Проект 2 — 0.1. Вывод: сначала оптимизируем загрузку.

Матрица Кано (Kano Model)

Категоризирую требования по типам:

Базовые требования (Must-Have)

• Пользователи ожидают это, хотя не говорят явно
• Отсутствие вызывает недовольство
• Пример: авторизация, базовая функциональность, безопасность данных
• Приоритет: ВЫСШИЙ

Линейные требования (Performance)

• Чем больше функции, тем больше удовлетворение
• Пример: скорость загрузки, количество фильтров, качество поиска
• Приоритет: ВЫСОКИЙ (после Must-Have)

Радующие требования (Delighters)

• Пользователи не ожидают, но очень доволены, если есть
• Дают конкурентное преимущество
• Пример: тёмный режим, персональные рекомендации, геймификация
• Приоритет: СРЕДНИЙ (делаем после покрытия базовых)

Практический процесс приоритизации

Шаг 1: Сбор требований На встречах со стейкхолдерами (продукт, бизнес, клиенты) собираю все идеи. Не отклоняю ничего на этом этапе.

Шаг 2: Классификация Распределяю требования по категориям Кано:

• Это базовое требование? → Must-Have
• Это улучшение существующей фичи? → Performance
• Это что-то неожиданное? → Delighter

Шаг 3: Оценка Для каждого требования:

• Estimate effort (story points) с разработчиком
• Оцениваю business value (в % от total opportunity)
• Определяю dependencies (от каких других требований зависит)
• Выявляю риски

Шаг 4: Расчёт приоритетов

• Применяю RICE для каждой фичи
• Сортирую по убыванию RICE score
• Учитываю dependencies (если Task A зависит от Task B, то B выше)

Шаг 5: Валидация с бизнесом Покаываю результаты на встрече:

• Вот 20 требований, которые вы просили
• Вот их приоритеты, основанные на данных
• Вот что мы можем сделать в Q1, Q2, Q3
• Давайте обсудим, согласны ли вы с этим порядком?

Инструменты и визуализация

Priority Matrix (2x2)

• High Impact + Low Effort = Quick Wins
• High Impact + High Effort = Major Projects
• Low Impact + Low Effort = Fill-Ins
• Low Impact + High Effort = Time Wasters

Все требования размещаю на этой матрице в Excel/Jira. Видно сразу, на что сосредоточиться.

MoSCoW классификация (для дополнения RICE)

• Must: критично для успеха (базовая функциональность, критические баги)
• Should: важно, но можно отложить (улучшения, nice-to-have)
• Could: можно сделать, но не критично (доп. фичи)
• Won't: не делаем в этот цикл

Управление изменениями в приоритетах

Данные меняются, рынок меняется. Я переоцениваю приоритеты:

• Еженедельно: на standup-ах смотрю, не упали ли стратегические требования
• Раз в спринт: на refinement встречах переоцениваю новые требования
• Раз в квартал: полный пересчёт RICE с учётом новых метрик

Если требование движется вверх в приоритетах, договариваюсь с командой, что уйдёт из спринта в обмен. Не просто добавляю работу.

Обработка давления

Стейкхолдеры часто давят: "Это срочно, надо в начало очереди". Я отвечаю:

1. Спрашиваю почему: "Почему это срочно? Какой бизнес-результат?"
2. Показываю текущий план: "Вот наши текущие приоритеты и их RICE scores"
3. Предлагаю трейд-офф: "Если мы поднимем это требование, то отодвинем то (показываю, что)"
4. Даю данные: "Вот сколько это стоит в часах разработки"

Чаще всего после такого разговора давление ослабевает, потому что стейкхолдер видит полную картину.

Результаты моего подхода

• 90%+ требований выполняются в запланированные сроки
• Стейкхолдеры видят логику приоритизации и верят процессу
• Команда фокусирует на high-impact работе, не на срочном
• Финансовый результат: ROI инвестиций в разработку на 40-50% выше благодаря правильной приоритизации