Какие знаешь методы приоритизации требований?

Методы приоритизации требований: Полный арсенал

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

Зачем нужна приоритизация?

Проблема: У вас 100 требований, бюджет на 20. Решение: Приоритизировать — выбрать 20 самых ценных.

Без приоритизации вы либо:

• Делаете случайные вещи (упускаете ценное)
• Пересипаете сроки (берётесь за всё)
• Разочаровываете клиентов (делаете не то, что нужно)

Метод 1: MoSCoW (Most Stringent Method)

Как работает: Разделить требования на 4 категории.

Категории:

M - Must Have (Критично)

• Без этого система не работает
• Примеры: авторизация, базовая функциональность, security
• Если не сделаем: проект fail
• Процент: 30-40% требований

S - Should Have (Важно)

• Значительно улучшает value
• Примеры: улучшения UX, доп. фичи
• Если не сделаем: недовольны пользователи
• Процент: 40-50% требований

C - Could Have (Nice-to-have)

• Было бы хорошо, но не критично
• Примеры: тёмный режим, дополнительные фильтры
• Если не сделаем: некритично
• Процент: 10-15% требований

W - Won't Have (Не будем делать) / (Would like to have in future)

• Откладываем на следующий релиз
• Примеры: интеграция с rare API
• Процент: 5-10% требований

Пример применения:

Проект: "Система управления проектами"

MUST HAVE (обязательны в MVP):
- Создание проекта
- Создание задач
- Назначение пользователей
- Базовое управление правами

SHOULD HAVE (желательны в v1.0):
- Комментарии на задачи
- Файл attachments
- Email уведомления
- Календарь

COULD HAVE (v1.1 или позже):
- Интеграция с Slack
- Экспорт в Excel
- Тёмный режим
- Custom fields

WON'T HAVE (future consideration):
- Интеграция с 100+ сервисов
- AI-powered task assignment
- Mobile app native

Плюсы:

• Простой и быстрый
• Легко объяснить стейкхолдерам
• Хороший для MVP планирования

Минусы:

• Не учитывает effort и value детально
• Все Must Have имеют одинаковый приоритет (может быть неправильно)

Метод 2: RICE (Reach, Impact, Confidence, Effort)

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

Этот метод я очень часто использую, потому что он data-driven.

Параметры:

Reach (Охват):

• Сколько пользователей затронет эта фича?
• Измеряется в числах: 1000, 10000, 100000
• Или в процентах: 5% пользователей, 50% пользователей

Impact (Влияние):

• Насколько сильно это повлияет на каждого пользователя?
• Шкала:
  • 3 = Massive (很大 улучшение)
  • 2 = High (значительное улучшение)
  • 1 = Medium (заметное улучшение)
  • 0.5 = Low (небольшое улучшение)
  • 0.25 = Tiny (едва заметно)

Confidence (Уверенность):

• Насколько уверены в этих цифрах?
• Шкала: 100% (уверены), 80%, 50%, 25% (гадаем)
• Если не уверены, используем меньший % (штраф за неопределённость)

Effort (Усилие):

• Сколько часов разработки нужно?
• Или в баллах: 1, 3, 5, 8, 13 story points

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

Фича 1: "Recommended products" (ML-based recommendations)
- Reach: 50,000 users = 50
- Impact: High (30% increase in AOV) = 2
- Confidence: Medium (don't know if ML will work well) = 75%
- Effort: 100 hours = 100
- RICE = (50 × 2 × 0.75) / 100 = 0.75

Фича 2: "Dark mode"
- Reach: 20,000 users = 20
- Impact: High (15% increase in session length) = 2
- Confidence: High = 95%
- Effort: 40 hours = 40
- RICE = (20 × 2 × 0.95) / 40 = 0.95

Фича 3: "Email signature templates"
- Reach: 5,000 users = 5
- Impact: Tiny (1% improvement) = 0.25
- Confidence: High = 95%
- Effort: 16 hours = 16
- RICE = (5 × 0.25 × 0.95) / 16 = 0.074

Приоритет: Фича 2 (0.95) > Фича 1 (0.75) > Фича 3 (0.074)

Когда использовать:

• Много требований (>20)
• Нужна objective приоритизация
• Есть данные о reach/impact

Плюсы:

• Учитывает value и effort
• Data-driven
• Легко объяснить цифрами

Минусы:

• Требует много информации
• Reach/Impact трудно оценить точно
• Может быть дорогой для маленьких projects

Метод 3: Value vs Effort Matrix (2x2)

Как работает: Матрица с 2 осями.

           LOW EFFORT        HIGH EFFORT
HIGH VALUE  Quick Wins      Major Projects
LOW VALUE   Fill-Ins        Time Wasters

Квадранты:

Quick Wins (High Value + Low Effort)

• Делаем немедленно (ROI highest)
• Примеры: исправить typo, добавить один toggle
• Время: дни

Major Projects (High Value + High Effort)

• Планируем в roadmap
• Требуют investment
• Примеры: redesign UI, миграция database
• Время: недели/месяцы

Fill-Ins (Low Value + Low Effort)

• Делаем когда нечего делать
• Улучшают polish
• Примеры: оптимизация small animation

Time Wasters (Low Value + High Effort)

• Откладываем или отклоняем
• ROI отрицательный
• Примеры: support для очень старого браузера

Пример:

┌──────────────────────────────────────┐
│  QUICK WINS    │  MAJOR PROJECTS    │
│  Fix typos     │  Mobile app        │
│  Add filter    │  Redesign          │
│  Sort option   │  API refactoring   │
├────────────────┼────────────────────┤
│  FILL-INS      │  TIME WASTERS      │
│  Dark mode*    │  IE8 support       │
│  Animation     │  Obscure feature   │
│  CSS tweaks    │  Support old API   │
└──────────────────────────────────────┘

*Dark mode может быть Quick Win если development easy

Плюсы:

• Очень простой и быстрый
• Визуальный (легко объяснить)
• Хороший для первичной сортировки

Минусы:

• Не очень точный (много требований в одном квадранте)
• Субъективно (что такое "high value"?)

Метод 4: Kano Model (3 уровня)

Как работает: Классифицировать требования по 3 типам.

Типы:

Basics (Базовые)

• Пользователи ожидают, но не говорят
• Отсутствие = недовольство
• Присутствие = not satisfying (нормально, как надо)
• Примеры: работает быстро, не падает, безопасно
• Приоритет: CRITICAL (делать в первую очередь)

Performance (Линейные)

• Чем больше, тем лучше
• Пример: скорость загрузки 2sec vs 0.5sec
• Пример: может обработать 1K vs 10K запросов
• Приоритет: HIGH (после basics)

Delighters (Радующие)

• Пользователи не ожидают
• Если есть = очень довольны
• Если нет = не заметят
• Примеры: AI recommendations, VR preview
• Приоритет: MEDIUM (polish, future)

Пример для E-commerce:

BASICS (Must Have):
- Товары отображаются
- Можно добавить в корзину
- Можно оплатить
- Товар доставляется
- Нет bugs

PERFORMANCE (The more, the better):
- Скорость загрузки страницы
- Количество фильтров
- Скорость поиска
- Скорость checkout

DELIGHTERS (Surprises):
- AR preview товара (примерить очки через камеру)
- AI recommendations ("Люди, которые купили X, также купили Y")
- Geo-targeted shipping estimates
- Voice search

Плюсы:

• Помогает выбрать правильный фокус (basics first)
• Хороший для product strategy

Минусы:

• Требует юзер-исследований (что люди expect?)
• Может менять со временем

Метод 5: Cost-Benefit Analysis

Как работает: Посчитать ROI для каждого требования.

Формула: ROI = (Benefits - Costs) / Costs × 100%

Пример:

Фича: "One-click checkout"
- Development cost: $20,000
- Marketing cost: $5,000
- Expected additional sales: $100,000/year
- Total benefit: $100,000
- ROI = ($100,000 - $25,000) / $25,000 = 300%

Это means: за каждый $1 потраченный, получаем $4 обратно.
Отличный ROI!

Фича: "Support 5 new languages"
- Development cost: $50,000
- Expected additional sales: $10,000/year
- ROI = ($10,000 - $50,000) / $50,000 = -80%

Отрицательный ROI — не делаем!

Когда использовать:

• Нужно convince CEO/finance
• Много дорогих features
• Money is primary driver

Плюсы:

• Финансово обоснованный
• CEO понимает язык денег

Минусы:

• Трудно оценить benefit (особенно для soft features)
• Не учитывает strategic value (brand building)

Метод 6: Weighted Scoring

Как работает: Каждому критерию даём weight, считаем score.

Пример с весами:

Критерий          | Weight | Фича A | Score A | Фича B | Score B
──────────────────┼────────┼────────┼─────────┼────────┼─────────
Business value    | 35%    | 9/10   | 3.15    | 7/10   | 2.45
User impact       | 25%    | 8/10   | 2.0     | 9/10   | 2.25
Effort required   | 20%    | 6/10   | 1.2     | 8/10   | 1.6
Risk             | 15%    | 7/10   | 1.05    | 5/10   | 0.75
                  | 100%   |        | 7.4     |        | 7.05

Фича A имеет более высокий score (7.4 vs 7.05), поэтому приоритет выше.

Плюсы:

• Гибкий (можно менять weights)
• Объективнее чем интуиция

Минусы:

• Сложный процесс
• Результат зависит от weights (garbage in, garbage out)

Метод 7: Stack Ranking (Относительная приоритизация)

Как работает: Пользователь/team ранжирует требования относительно друг друга.

Процесс:

1. Берём 2 требования
2. Спрашиваем: "Какое важнее?"
3. Более важное идёт выше
4. Повторяем для всех пар

Пример результата:

1. Авторизация (никак не обойтись)
2. Создание задач (core feature)
3. Комментарии (collaboration)
4. Email notifications (удобство)
5. Dark mode (nice-to-have)
6. Export PDF (future)

Плюсы:

• Простой для малых lists (<20)
• Относительное ранжирование (что важнее всего)

Минусы:

• N(N-1)/2 сравнений (для 20 требований = 190 сравнений!)
• Медленный процесс

Метод 8: User Story Mapping

Как работает: Визуализировать user journey и приоритизировать по stages.

Пример:

User journey для e-commerce:
DISCOVER → BROWSE → SELECT → CHECKOUT → PAY → RECEIVE
   ↓        ↓        ↓        ↓         ↓       ↓
 Search   Filter   Reviews  Promo   Payment Address
 Suggest   Sort    Compare  Coupon  Methods Tracking
 Browse   Save    Images   Gift    Refund  Returns
           Categories       Card

MVP (Must have):
DISCOVER → BROWSE → SELECT → CHECKOUT → PAY
             Search   Review   Promo   Credit Card
             Filter   Compare  Cart    Address

v1.0 (Should have):
Add: Gift cards, Email receipt, Order history

v1.1 (Could have):
Add: Recommendations, Personalized filters, Mobile app

Плюсы:

• Фокусирует на user experience
• Помогает выявить missing steps

Минусы:

• Требует UX expertise
• Может быть комплексным для complicated flows

Как я выбираю метод приоритизации?

Я использую эту матрицу:

Количество требований: < 20    →  MoSCoW или Matrix
Количество требований: 20-100  →  RICE или Weighted Scoring
Количество требований: > 100   →  RICE + Filtering

Есть финансовый driver:  → Cost-Benefit
У нас нет данных:        → MoSCoW или Kano
Нужна быстрая answer:    → Matrix
Нужна аккуратная answer: → RICE
Need user perspective:    → User Story Mapping

Типичный процесс (как я делаю)

Шаг 1: Быстрая сортировка (5 минут) МоSCoW: Must/Should/Could/Won't → Сразу видно: Must Have сделать, Won't отклонить

Шаг 2: Детальная приоритизация (30 минут) Для Should Have + Could Have применяю RICE:

• Reach: data from analytics
• Impact: feedback from users
• Confidence: базируюсь на past projects
• Effort: estimate с dev team

Шаг 3: Валидация (встреча с стейкхолдерами, 1 час)

• Показываю результаты
• Спрашиваю: согласны ли вы?
• Объясняю reasoning (RICE scores)
• Договариваюсь о roadmap

Результат правильной приоритизации

• Фокус (team знает, на что работать)
• Реалистичный roadmap (стейкхолдеры довольны)
• Максимальный ROI (делаем most valuable features first)
• Счастливые users (получают то, что реально нужно)

Приоритизация требований — это искусство и наука. Выбирайте правильный метод для вашей ситуации.