Приоритеты
Как расставлять приоритеты в разработке, когда всё важное уже помечено как срочное. MoSCoW, RICE и WSJF: принципы, расчёты и применение в проектах.
У нас всё приоритетное
В большом проекте задач всегда больше, чем команда способна выполнить. Клиенту нужен новый функционал, бизнес хочет увеличить конверсию, разработка напоминает о техническом долге, а релиз уже маячит на горизонте. У каждой задачи находится человек, уверенный в её исключительной важности. Можно назначить всему высокий приоритет, но от этого свободных ресурсов не станет больше.
Для подобной жести существуют методики приоритизации. Они помогают согласовать обязательный объём работ, сравнить ожидаемую пользу инициатив и определить последовательность выполнения. Разберу три подхода на примере интернет-магазина, которому одновременно требуется исправить оплату, улучшить поиск, добавить избранное и обновить интеграцию доставки.
MoSCoW = определить обязательное
| Категория | Значение |
|---|---|
| Must Have | Обязательно для достижения цели релиза |
| Should Have | Важно, но допустима отсрочка |
| Could Have | Желательно при наличии ресурсов |
| Won't Have | Исключено из текущего релиза |
Допустим, магазин готовится к запуску. Исправление критической ошибки оплаты = Must Have, улучшение работающего поиска = Should Have, избранное = Could Have. С интеграцией доставки сложнее: если партнёр отключает старый API до релиза, обновление становится обязательным. Если нет, то его можно перенести.
MoSCoW особенно полезна при согласовании требований с клиентом и планировании фиксированного объёма поставки. Не записывайте всё подряд в Must Have, смысл метода потеряется. При этом категории определяют обязательность, но не точный порядок разработки: технические зависимости и сроки всё равно придётся учитывать.
RICE = сравниваем пользу
RICE оценивает продуктовые инициативы по четырём показателям: Reach (охват), Impact (влияние), Confidence (уверенность в оценке) и Effort (трудозатраты).
RICE = (Reach × Impact × Confidence) / Effort
Команда выбирает между улучшением поиска и добавлением избранного. Используем условные данные аналитики, месячный охват, относительную шкалу влияния и трудозатраты в человеко-месяцах.
| Показатель | Поиск | Избранное |
|---|---|---|
| Reach | 4 000 | 2 000 |
| Impact | 2 | 1 |
| Confidence | 80% | 50% |
| Effort | 2 | 1 |
| RICE | 3 200 | 1 000 |
Поиск получает более высокий балл: несмотря на дополнительные трудозатраты, ожидаемая польза значительно больше. Низкий Confidence у избранного указывает, что востребованность функции пока подтверждена недостаточно.
RICE удобна для сравнения продуктовых гипотез, но требовательна к исходным данным. Если Impact определён исключительно по принципу «кажется, пользователям понравится», итоговая цифра будет выглядеть убедительнее, чем заслуживает. Высокий RICE не отменяет обязательные технические работы и критические исправления.
WSJF = стоимость задержки
WSJF (Weighted Shortest Job First) определяет последовательность работ с учётом последствий ожидания. Подход используется, в частности, в SAFe.
WSJF = Cost of Delay / Job Size
Cost of Delay = относительная стоимость задержки, Job Size = размер работы. В модели SAFe стоимость задержки складывается из бизнес-ценности, критичности по времени и снижения рисков или открытия новых возможностей.
| Показатель | Доставка | Поиск | Избранное |
|---|---|---|---|
| Бизнес-ценность | 5 | 8 | 3 |
| Критичность по времени | 8 | 3 | 1 |
| Снижение рисков / новые возможности | 5 | 2 | 1 |
| Cost of Delay | 18 | 13 | 5 |
| Job Size | 3 | 5 | 2 |
| WSJF | 6,0 | 2,6 | 2,5 |
Первой оказывается интеграция доставки. Хотя улучшение поиска потенциально принесёт больше пользы пользователям, задержка обновления API может создать проблемы с оформлением заказов. При небольшом объёме работ откладывать интеграцию невыгодно.
WSJF полезна при конкуренции крупных инициатив за ресурсы, особенно когда важны внешние сроки и последствия задержек. Но оценки должны быть согласованы между участниками, а технические зависимости учтены до утверждения плана.
Три разных результата
| Методика | Для чего использовать |
|---|---|
| MoSCoW | Определить обязательный состав релиза |
| RICE | Сравнить ожидаемую пользу продуктовых инициатив |
| WSJF | Выбрать экономически предпочтительную очерёдность работ |
Их вполне можно сочетать. Например, сначала определить обязательный функционал через MoSCoW, дополнительные продуктовые инициативы сравнить по RICE, а при планировании работ учесть стоимость задержки через WSJF.
Сложность инструмента должна соответствовать масштабу задачи. Если команда и клиент уже согласовали десять понятных требований, отдельная система коэффициентов не принесёт пользу. Но для продукта с десятками конкурирующих инициатив прозрачные критерии упростят принятие решений.
Красиво посчитали
Любая приоритизация требует проверки на реализуемость. Высокий балл не гарантирует свободную команду, согласованные требования или техническую возможность начать разработку. После расчётов PM проверяет зависимости, загрузку специалистов, бюджет и внешние ограничения. Приоритеты необходимо пересматривать при существенных изменениях проекта. Новые требования, критические ошибки, изменение сроков или пользовательских метрик могут полностью поменять первоначальные оценки.
Методики помогают аргументировать решения, но не принимают их вместо бизнеса и команды. Если коэффициенты назначаются по личным ощущениям менеджера, получается привычная приоритизация на глаз. Просто с формулами и тупо красивой табличкой.
Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.