Приоритезация требований
Что такое приоритизация требований, зачем она нужна, кто участвует, основные критерии (ценность, сложность, риски) и методы: MoSCoW, модель Кано, Value vs Complexity, RICE, простая шкала. Также типичные ошибки и факторы, влияющие на приоритеты.
Все важно, но делать надо по порядку
Представьте, что вы собираетесь в отпуск. У вас есть чемодан, но он не резиновый. Взять с собой все, что хочется, невозможно. Нужно выбирать: теплые вещи или купальник, фотоаппарат или второй ноутбук, пять пар обуви или одну, но удобную. Вы расставляете приоритеты исходя из погоды, планов и места в чемодане.
В разработке ровно та же история. Заказчик хочет все и сразу. Пользователи просят 100500 фич. У команды есть ограниченное время, бюджет и количество разработчиков. Приходится выбирать.
Приоритезация требований – это процесс определения порядка реализации требований на основе их важности, ценности, рисков и других факторов.
Зачем нужна приоритезация
Ресурсы всегда ограничены
У команды есть только 10 человек и 3 месяца до релиза(цифры абстрактные, может быть где то больше, где то меньше). А хотелок – на год работы. Нужно выбрать самое важное.
Бизнесу нужно быстро получить ценность
Вместо того чтобы год делать “все и сразу”, лучше через месяц выпустить версию с самым главным, получить обратную связь и начать зарабатывать.
Помогает управлять ожиданиями
Заказчик видит, что его “хотелки” не выкинули, а просто отложили на потом. Он понимает, что самое важное делается сейчас.
Снижает риски
Самые рискованные и сложные требования лучше сделать рано, чтобы понять, все ли получится, а не обнаружить проблемы в конце проекта.
Помогает фокусироваться
Команда не распыляется на 100 задач, а четко знает, что сейчас важно.
Кто участвует в приоритезации
Приоритезация – это командная работа:
Владелец продукта (Product Owner)
Главный по приоритетам. Он знает бизнес-цели, видит картину целиком и принимает финальное решение.
Заказчик (если это не PO)
Тот, кто дает деньги. Может сказать: “Это самое важное, потому что без этого мы не выйдем на рынок”.
Аналитик
Помогает оценить сложность, показывает зависимости между требованиями, подсвечивает риски.
Архитектор / Техлид
Оценивает техническую сложность, говорит, что технически проще сделать сначала, а что лучше отложить.
Разработчики и тестировщики
Дают реалистичные оценки: “Это быстро, а это – долго и больно”.
Критерии для приоритезации
По каким параметрам сравнивать требования?
Ценность для бизнеса
Сколько денег принесет? Сколько сэкономит? Как повлияет на позиции на рынке?
Ценность для пользователя
Насколько это важно пользователям? Без чего они не могут работать? Что сделает их счастливее?
Сложность реализации
Сколько времени займет? Сколько человек нужно? Есть ли технические риски?
Риски
Что будет, если это не сделать? А если сделать, но что-то пойдет не так?
Зависимости
Что должно быть сделано до этого? Что можно сделать только после? Какие зависимости есть на смежные системы?
Срочность
Есть дедлайн? Закон требует сдать отчетность к определенной дате?
Методы приоритезации
Основные способы приоритезации:
MoSCoW
Самый популярный и простой метод. Все требования делятся на четыре категории:
| Категория | Значение | Описание |
|---|---|---|
| M – Must have | Обязательно сделать | Без этих требований система не имеет смысла. Критически важно для первого релиза. Если не сделаем – проект провален. |
| S – Should have | Желательно сделать | Важные требования, но без них можно выпустить первую версию. Добавим во вторую очередь. |
| C – Could have | Можно сделать | То, что хорошо бы сделать, если останется время. Часто это “украшательства” или нишевые фичи. |
| W - Won’t have | Не будем делать | Сознательно откладываем или вообще отказываемся. Четкое “нет”, чтобы не висело мертвым грузом. |
Пример для интернет-магазина:
- Must have: Каталог товаров, корзина, оформление заказа, оплата картой.
- Should have: Личный кабинет с историей заказов, отзывы на товары.
- Could have: Рекомендации похожих товаров, сравнение товаров.
- Won’t have: Интеграция с соцсетями, мобильное приложение (только сайт).
Важное правило MoSCoW: Must have не должно быть больше 60% от всего объема. Иначе это не приоритезация, а просто список всего подряд.
Модель Кано (Kano Model)
Японский метод, который смотрит на удовлетворенность пользователя. Делит требования на категории по влиянию на эмоции.
| Категория | Описание | Пример |
|---|---|---|
| Базовые (Threshold) | Очевидные вещи. Если их нет – пользователь в ярости. Если есть – не замечает. | В машине должны быть тормоза. В телефоне должна работать связь. |
| Линейные (Performance) | Чем больше, тем лучше. Прямая зависимость. | Чем быстрее грузится сайт – тем лучше. Чем больше памяти в телефоне - тем лучше. |
| Восторг (Excitement) | Неожиданные приятные бонусы. Если их нет – все равно. Если есть – вау-эффект. | Бесплатная доставка, подарок в заказе, приятный дизайн. |
| Безразличные | Пользователю все равно, есть они или нет. | Какая-то техническая фича, которую пользователь не видит. |
| Обратные | Чем больше, тем хуже. | Навязчивая реклама, обязательная регистрация. |
Как применять:
- Сначала закрываем базовые требования (иначе пользователи уйдут).
- Потом добавляем линейные (чем больше, тем конкурентоспособнее).
- Восторг – приятный бонус, когда есть ресурсы.
Бизнес-ценность / Сложность (Value vs Complexity)
Рисуем квадрат с осями “Ценность” и “Сложность”. Каждое требование размещаем в одном из четырех квадрантов:
| Сложность \ Ценность | Низкая ценность | Высокая ценность |
|---|---|---|
| Низкая сложность | Сделаем, если будет время (low hanging fruit) | ДЕЛАЕМ В ПЕРВУЮ ОЧЕРЕДЬ! (quick wins) |
| Высокая сложность | Не делаем (money pit) | Делаем, но тщательно планируем (major projects) |
Логика простая:
- Quick wins (легко и ценно): делаем немедленно.
- Major projects (сложно, но ценно): планируем, выделяем ресурсы, делаем аккуратно.
- Low hanging fruit (легко, но малополезно): делаем в последнюю очередь, если останется время.
- Money pit (сложно и бесполезно): не делаем вообще.
Для оценки сложности можно использовать story points (очки).
Story Point – это условная единица измерения размера задачи (User Story). Не время в часах, а именно “размер”, сложность. Простыми словами: это абстрактная цифра, которой команда оценивает, насколько задача большая по сравнению с другой.
Ключевые идеи:
- Оценивается относительно других задач. Задача А в два раза сложнее задачи Б? Значит у неё в 2 раза больше Story Points.
- Учитывается все: объем работы, сложность, риски, неопределенность.
- Команда договаривается о “шкале” (обычно числа Фибоначчи: 1, 2, 3, 5, 8, 13…).
Зачем нужно: Чтобы планировать спринты. Если команда делает в среднем 40 Story Points за спринт, значит в следующий спринт она может взять задач примерно на 40 Points.
RICE
Более продвинутый метод, который считает числовой приоритет по формуле.
RICE = (Reach * Impact * Confidence) / Effort
- Reach (Охват): сколько пользователей/событий затронет за период (например, в месяц).
- Impact (Влияние): насколько сильно повлияет на цель (например, конверсию). Обычно шкала: 0,25 (минимально), 0,5, 1 (средне), 2 (сильно), 3 (максимально).
- Confidence (Уверенность): насколько вы уверены в оценках (проценты: 20%, 50%, 80%, 100%).
- Effort (Усилия): сколько времени займет (в человеко-месяцах или story points).
Пример:
Фича А: охват 1000 пользователей, влияние 2, уверенность 80%, усилия 20.
RICE = (1000 * 2 * 0.8) / 20 = 80
Фича Б: охват 500 пользователей, влияние 1, уверенность 90%, усилия 5.
RICE = (500 * 1 * 0.9) / 5 = 90
Фича Б имеет больший приоритет (90 > 80), хотя охват меньше, но она дешевле и уверенность выше.
Простая трехбалльная шкала
Для маленьких проектов или когда нужна быстрая оценка можно использовать просто:
- P1 (Critical): Критично, блокирует работу, без этого релиз невозможен.
- P2 (High): Важно, но жить можно, сделаем в этом релизе, если успеем.
- P3 (Medium): Хорошо бы, но не горит.
- P4 (Low): Когда-нибудь потом, в бэклоге.
Что влияет на приоритеты
Зависимости
Иногда технически невозможно сделать фичу Б, пока не сделана фича А. Даже если Б важнее, А придется делать раньше.
Риски
Сложные и рискованные фичи лучше делать рано. Если поймете, что не получается, останется время на перепланирование. Если оставить рискованное на конец - можно провалить релиз.
Технический долг
Иногда нужно сначала сделать “невидимую” работу (рефакторинг, обновление библиотек), чтобы потом можно было быстро делать новые фичи. Это не ценно для бизнеса напрямую, но критически важно для скорости разработки.
Внешние ограничения
Закон требует сдать отчетность до 1 апреля. Значит, эта фича автоматически становится Must have независимо от всего остального.
Сезонность
Если у вас интернет-магазин подарков, то фичи для новогоднего сезона нужно делать летом, а не в декабре.
Типичные ошибки при приоритезации
Всё - Must have
Самая частая ошибка. Заказчик говорит, что все критично. Но так не бывает. Задача аналитика – помочь выделить действительно важное, задавая вопросы: “А без этого можно выпустить первую версию?”, “А что будет, если это не сделать?”.
Приоритезирует только один человек
Техлид говорит: “Это сложно, давайте не будем”. А заказчик: “Это критично для бизнеса”. Без диалога приоритеты будут кривыми.
Забывать про зависимости
Поставили высокий приоритет фиче, которая требует уже устаревшей технологии, и теперь нужно сначала обновлять всю инфраструктуру.
Приоритезация без оценок
Нельзя выбрать между фичами, если не понимать, сколько они стоят. Простая фича с низкой ценностью может оказаться выгоднее сложной со средней ценностью, если делать быстро.
Один раз приоритезировали и забыли
Приоритеты живут и меняются. Рынок изменился, конкурент выкатил фичу, закон вышел новый – приоритеты нужно пересматривать.