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

Процесс определения порядка реализации функциональности на основе ценности и ресурсов.

Зачем приоритизировать?

Ограниченные ресурсы — нельзя сделать всё сразу
Time-to-market — нужно быстрее выйти на рынок
Фокус на ценности — делать то, что важно пользователям
Управление рисками — сначала критичное, потом nice-to-have

Методы приоритизации

1. MoSCoW

Классификация требований по важности.

Must have (Обязательно)

Без этого продукт не работает или не имеет смысла.

Примеры:

Регистрация и авторизация
Оформление заказа в интернет-магазине
Отправка сообщений в мессенджере

Критерии:

Юридические требования
Критичная функциональность
Без этого продукт бесполезен

Should have (Важно)

Важно, но можно отложить на следующий релиз.

Примеры:

Фильтры в каталоге
История заказов
Уведомления на email

Критерии:

Значительно улучшает UX
Есть workaround
Можно добавить позже

Could have (Желательно)

Хорошо бы иметь, если останется время.

Примеры:

Темная тема
Экспорт в PDF
Интеграция с соцсетями

Критерии:

Небольшое улучшение
Низкое влияние на бизнес
Можно обойтись

Won't have (Не в этом релизе)

Точно не делаем сейчас.

Примеры:

Мобильное приложение (если делаем веб)
AI рекомендации (если MVP)
Интеграция с редкими сервисами

Критерии:

Не вписывается в scope
Слишком дорого
Низкий приоритет

Применение MoSCoW

Релиз 1.0:
Must: 60% ресурсов
Should: 30% ресурсов
Could: 10% ресурсов
Won't: откладываем

Если не успеваем:
1. Убираем Could
2. Переносим часть Should
3. Must делаем обязательно

2. RICE Score

Количественная оценка на основе 4 факторов.

Формула:

RICE = (Reach × Impact × Confidence) / Effort

Reach (Охват)

Сколько пользователей затронет за период (обычно квартал).

Примеры:

10,000 пользователей/квартал
50% активных пользователей
1,000 транзакций/месяц

Impact (Влияние)

Насколько сильно повлияет на ключевую метрику.

Шкала:

3 — Massive impact
2 — High impact
1 — Medium impact
0.5 — Low impact
0.25 — Minimal impact

Примеры:

3: Критичный баг, блокирующий покупки
2: Новая функция, увеличивающая конверсию на 20%
1: Улучшение UX, ускоряющее процесс
0.5: Небольшое удобство
0.25: Косметическое изменение

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

Насколько уверены в оценках.

Шкала:

100% — есть данные, уверены полностью
80% — есть некоторые данные
50% — предположения, мало данных
<50% — чистые догадки (лучше не использовать)

Effort (Усилия)

Трудозатраты в person-months.

Примеры:

0.5 — неделя работы одного человека
1 — месяц работы одного человека
3 — квартал работы одного человека

Пример расчета RICE

Фича: Фильтр товаров по цене

Reach: 5,000 пользователей/квартал
Impact: 1 (medium — улучшает UX)
Confidence: 80% (есть данные от пользователей)
Effort: 0.5 person-months (2 недели)

RICE = (5,000 × 1 × 0.8) / 0.5 = 8,000

Фича: AI рекомендации товаров

Reach: 10,000 пользователей/квартал
Impact: 2 (high — увеличит продажи)
Confidence: 50% (нет данных, предположение)
Effort: 3 person-months (квартал)

RICE = (10,000 × 2 × 0.5) / 3 = 3,333

Вывод: Фильтр по цене приоритетнее (8,000 > 3,333)

3. Value vs Effort Matrix

Матрица 2x2 для быстрой приоритизации.

        High Value
            │
    Quick  │  Major
    Wins   │  Projects
────────────┼────────────
    Fill   │  Money
    Ins    │  Pits
            │
        Low Value

Quick Wins (Быстрые победы)

Ценность: Высокая
Усилия: Низкие
Приоритет: Делаем первыми

Примеры:

Исправление критичного бага
Добавление кнопки "Забыли пароль?"
Улучшение текста ошибок

Major Projects (Крупные проекты)

Ценность: Высокая
Усилия: Высокие
Приоритет: Планируем тщательно

Примеры:

Новый модуль системы
Редизайн интерфейса
Интеграция с платежной системой

Fill Ins (Заполнители)

Ценность: Низкая
Усилия: Низкие
Приоритет: Делаем если есть время

Примеры:

Косметические улучшения
Мелкие удобства
Рефакторинг небольших участков

Money Pits (Денежные ямы)

Ценность: Низкая
Усилия: Высокие
Приоритет: Не делаем

Примеры:

Сложная фича для 1% пользователей
Интеграция с устаревшей системой
Over-engineering

4. Kano Model

Классификация требований по влиянию на удовлетворенность пользователей.

Basic Needs (Базовые потребности)

Ожидаемые функции. Их отсутствие раздражает, наличие не радует.

Примеры:

Сайт загружается быстро
Кнопки работают
Нет багов

Стратегия: Обязательно реализовать, но не переусердствовать.

Performance Needs (Производительные)

Чем больше, тем лучше. Линейная зависимость удовлетворенности.

Примеры:

Скорость доставки
Количество товаров в каталоге
Качество фото

Стратегия: Улучшать постепенно, ориентируясь на конкурентов.

Excitement Needs (Восторг)

Неожиданные функции, вызывающие wow-эффект.

Примеры:

Бесплатная доставка
Персональные рекомендации
Геймификация

Стратегия: Использовать для дифференциации от конкурентов.

Применение Kano

Опрос пользователей с двумя вопросами для каждой функции:
- Как вы себя почувствуете, если эта функция БУДЕТ?
- Как вы себя почувствуете, если этой функции НЕ БУДЕТ?
Варианты ответов:
- Мне это нравится
- Я это ожидаю
- Мне все равно
- Я могу с этим смириться
- Мне это не нравится
Классификация на основе ответов

5. Weighted Scoring

Взвешенная оценка по нескольким критериям.

Критерии (примеры):

Бизнес-ценность (вес 40%)
Удовлетворенность пользователей (вес 30%)
Стратегическое соответствие (вес 20%)
Риски (вес 10%)

Оценка: 1-10 для каждого критерия

Пример:

Фича	Бизнес (40%)	UX (30%)	Стратегия (20%)	Риски (10%)	Итого
Фильтр по цене	7	9	6	2	6.9
AI рекомендации	9	8	9	7	8.5
Темная тема	3	7	4	1	4.3

Расчет для "Фильтр по цене":

7×0.4 + 9×0.3 + 6×0.2 + 2×0.1 = 2.8 + 2.7 + 1.2 + 0.2 = 6.9

6. Cost of Delay

Оценка потерь от откладывания функции.

Формула:

CD3 = Cost of Delay / Duration

Cost of Delay — сколько теряем в месяц, откладывая фичу.

Duration — сколько месяцев займет разработка.

Пример:

Фича	CoD ($/мес)	Duration (мес)	CD3
Платежи	$50,000	2	$25,000
Фильтры	$10,000	0.5	$20,000
Темная тема	$1,000	1	$1,000

Вывод: Сначала Платежи, потом Фильтры, потом Темная тема.

Работа со стейкхолдерами

Техника "Покупка функций"

Даем каждому стейкхолдеру 100 виртуальных долларов
Они "покупают" функции по их стоимости
Видим реальные приоритеты

Пример:

Функция A: $30
Функция B: $20
Функция C: $50
Функция D: $10

Стейкхолдер может купить:
- A + B + D = $60 (остается $40)
- C + D = $60 (остается $40)
- A + C = $80 (остается $20)

Техника "Forced Ranking"

Ранжирование всех требований от 1 до N.

Правила:

Нельзя ставить одинаковый ранг
Нужно выбирать между "хорошим" и "хорошим"

Управление ожиданиями

Когда стейкхолдер говорит "Всё важно":

Покажи ограничения: "У нас 3 разработчика на 2 недели = 6 недель работы"
Покажи trade-offs: "Если делаем A, то B откладывается на месяц"
Спроси о бизнес-целях: "Какая главная цель этого релиза?"
Используй данные: "80% пользователей просят функцию X"
Предложи MVP: "Давайте сделаем базовую версию сейчас, улучшим потом"

Приоритизация багов

Severity (Серьезность)

Critical — система не работает, потеря данных
High — основная функция не работает
Medium — второстепенная функция не работает
Low — косметический дефект

Priority (Приоритет)

P0 — чинить немедленно (hotfix)
P1 — чинить в текущем спринте
P2 — чинить в следующем спринте
P3 — чинить когда будет время

Матрица Severity vs Frequency

	Часто	Редко
Critical	P0	P1
High	P1	P2
Medium	P2	P3
Low	P3	P3

Инструменты

Spreadsheets

Google Sheets / Excel для расчета RICE, Weighted Scoring.

Jira

Поля Priority, Labels, Custom Fields для приоритизации.

ProductBoard

Специализированный инструмент для product management.

Aha!

Roadmap и приоритизация.

Miro / Mural

Для воркшопов по приоритизации.

Best Practices

1. Вовлекай стейкхолдеров

Приоритизация — не единоличное решение аналитика.

2. Используй данные

Аналитика использования
Обращения в поддержку
Опросы пользователей
A/B тесты

3. Пересматривай регулярно

Приоритеты меняются — пересматривай каждый спринт.

4. Будь прозрачным

Объясняй почему что-то приоритетнее.

5. Учитывай зависимости

Иногда нужно сделать B перед A, даже если A приоритетнее.

6. Баланс краткосрочного и долгосрочного

Не только quick wins, но и стратегические проекты.

7. Оставляй буфер

20% времени на непредвиденное (баги, tech debt).

Частые ошибки

1. Всё высокий приоритет

❌ 50 задач с приоритетом "High" ✅ Forced ranking — только одна задача может быть #1

2. Приоритизация по HiPPO

❌ Highest Paid Person's Opinion ✅ Данные + бизнес-цели

3. Игнорирование технического долга

❌ Только новые фичи ✅ 20% времени на tech debt

4. Не учитываем effort

❌ Приоритизируем только по ценности ✅ Учитываем соотношение ценность/усилия

5. Не пересматриваем приоритеты

❌ Приоритеты установлены год назад ✅ Пересмотр каждый спринт

Чек-лист приоритизации

Определены бизнес-цели релиза
Собраны требования от всех стейкхолдеров
Оценены усилия (Story Points / person-days)
Применен метод приоритизации (MoSCoW / RICE)
Учтены зависимости между задачами
Проверена capacity команды
Согласованы приоритеты со стейкхолдерами
Документированы критерии приоритизации
Запланирован пересмотр приоритетов

Полезные ресурсы

Книга "Inspired" — Marty Cagan
Книга "The Lean Product Playbook" — Dan Olsen
RICE Scoring Calculator
Kano Model Guide

Зачем приоритизировать?​

Методы приоритизации​

1. MoSCoW​

Must have (Обязательно)​

Should have (Важно)​

Could have (Желательно)​

Won't have (Не в этом релизе)​

Применение MoSCoW​

2. RICE Score​

Reach (Охват)​

Impact (Влияние)​

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

Effort (Усилия)​

Пример расчета RICE​

3. Value vs Effort Matrix​

Quick Wins (Быстрые победы)​

Major Projects (Крупные проекты)​

Fill Ins (Заполнители)​

Money Pits (Денежные ямы)​

4. Kano Model​

Basic Needs (Базовые потребности)​

Performance Needs (Производительные)​

Excitement Needs (Восторг)​

Применение Kano​

5. Weighted Scoring​

6. Cost of Delay​

Работа со стейкхолдерами​

Техника "Покупка функций"​

Техника "Forced Ranking"​

Управление ожиданиями​

Приоритизация багов​

Severity (Серьезность)​

Priority (Приоритет)​

Матрица Severity vs Frequency​

Инструменты​

Spreadsheets​

Jira​

ProductBoard​

Aha!​

Miro / Mural​

Best Practices​

1. Вовлекай стейкхолдеров​

2. Используй данные​

3. Пересматривай регулярно​

4. Будь прозрачным​

5. Учитывай зависимости​

6. Баланс краткосрочного и долгосрочного​

7. Оставляй буфер​

Частые ошибки​

1. Всё высокий приоритет​

2. Приоритизация по HiPPO​

3. Игнорирование технического долга​

4. Не учитываем effort​

5. Не пересматриваем приоритеты​

Чек-лист приоритизации​

Полезные ресурсы​

Зачем приоритизировать?

Методы приоритизации

1. MoSCoW

Must have (Обязательно)

Should have (Важно)

Could have (Желательно)

Won't have (Не в этом релизе)

Применение MoSCoW

2. RICE Score

Reach (Охват)

Impact (Влияние)

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

Effort (Усилия)

Пример расчета RICE

3. Value vs Effort Matrix

Quick Wins (Быстрые победы)

Major Projects (Крупные проекты)

Fill Ins (Заполнители)

Money Pits (Денежные ямы)

4. Kano Model

Basic Needs (Базовые потребности)

Performance Needs (Производительные)

Excitement Needs (Восторг)

Применение Kano

5. Weighted Scoring

6. Cost of Delay

Работа со стейкхолдерами

Техника "Покупка функций"

Техника "Forced Ranking"

Управление ожиданиями

Приоритизация багов

Severity (Серьезность)

Priority (Приоритет)

Матрица Severity vs Frequency

Инструменты

Spreadsheets

Jira

ProductBoard

Aha!

Miro / Mural

Best Practices

1. Вовлекай стейкхолдеров

2. Используй данные

3. Пересматривай регулярно

4. Будь прозрачным

5. Учитывай зависимости

6. Баланс краткосрочного и долгосрочного

7. Оставляй буфер

Частые ошибки

1. Всё высокий приоритет

2. Приоритизация по HiPPO

3. Игнорирование технического долга

4. Не учитываем effort

5. Не пересматриваем приоритеты

Чек-лист приоритизации

Полезные ресурсы