Приоритизация бэклога: RICE, MoSCoW и другие методы

Приоритизировать бэклог — значит решить, что делать первым, исходя из пользы для бизнеса, затрат и риска, а не из того, кто громче просит. Методы вроде RICE, MoSCoW и матрицы «ценность — усилия» не принимают решение за вас, но заставляют назвать критерии и сравнить задачи на одной шкале. Для небольшой команды обычно хватает одного простого метода, применяемого регулярно.

Разберём популярные методы, когда какой подходит и как не превратить приоритизацию в бюрократию.

Зачем нужна приоритизация бэклога?

Приоритизация нужна, потому что идей и запросов всегда больше, чем может сделать команда, а время разработки — самый дорогой ресурс продукта. Без явных правил в работу попадает то, что предложил руководитель, самый настойчивый клиент или сам разработчик, которому интересна задача.

Признаки, что приоритизация не работает:

• команда постоянно переключается между срочными задачами;
• важные улучшения месяцами лежат в конце списка;
• никто не может объяснить, почему задача А делается раньше задачи Б;
• релизы выходят, а метрики продукта не меняются.

Как работает метод RICE?

RICE — это формула, которая оценивает задачу по четырём параметрам: охват (Reach), влияние (Impact), уверенность в оценке (Confidence) и затраты (Effort). Итоговый балл — охват × влияние × уверенность, делённые на затраты. Метод придумали в Intercom, и он хорош тем, что сравнивает очень разные задачи на одной шкале.

Параметр	Что оценивает	Как измерять
Reach	Сколько пользователей затронет изменение за период	Число пользователей или событий в квартал
Impact	Насколько сильно изменение повлияет на каждого	Шкала: 3 — огромное, 2 — большое, 1 — среднее, 0,5 — малое, 0,25 — минимальное
Confidence	Насколько вы уверены в оценках	100% — есть данные, 80% — есть основания, 50% — догадка
Effort	Сколько работы потребуется	Человеко-недели или человеко-месяцы

Задача: упростить оформление заказа до одного экрана
  Reach      = 4 000 покупателей в квартал
  Impact     = 2 (большое влияние на конверсию)
  Confidence = 80% (есть данные аналитики о брошенных корзинах)
  Effort     = 3 человеко-недели
  RICE = 4 000 × 2 × 0,8 / 3 ≈ 2 133

Сам по себе балл не истина. Его ценность в том, что оценки видны всем и их можно оспорить: «почему охват 4 000, если оформляют заказ только 2 000?»

Когда подходит MoSCoW?

MoSCoW подходит, когда нужно быстро договориться о составе конкретного релиза или этапа с фиксированным сроком. Задачи делятся на четыре группы: Must have — без этого релиз не имеет смысла, Should have — важно, но можно выпустить без него, Could have — желательно, если останется время, Won't have — точно не в этот раз.

Как применять:

1. Сначала договоритесь о цели релиза — без неё всё окажется в Must have.
2. Проверяйте каждую Must-задачу вопросом: «выпустим ли мы релиз без неё?» Если да — это Should.
3. Держите Must have в пределах примерно половины мощности команды, остальное — запас.
4. Список Won't have так же важен, как Must have: он снимает ожидания заранее.

Этот метод особенно полезен при определении состава MVP — как на этапе discovery, когда отделяют обязательное для запуска от второй версии.

Фото: Unsplash

Какие ещё методы стоит знать?

Кроме RICE и MoSCoW, полезны матрица «ценность — усилия», модель Кано и подход по стоимости задержки. Они отвечают на разные вопросы, и выбирать стоит тот, который подходит вашей ситуации.

Матрица «ценность — усилия»

Задачи раскладывают на два квадрата по осям «ценность» и «затраты». Сначала делают ценные и дешёвые, затем ценные и дорогие, дешёвые и малоценные — по остаточному принципу, а дорогие и малоценные вычёркивают. Метод быстрый и хорошо работает на коротких планёрках.

Модель Кано

Модель Кано делит функции по тому, как они влияют на удовлетворённость: базовые — их отсутствие раздражает, но наличие не радует; линейные — чем больше, тем лучше; восхищающие — неожиданные и запоминающиеся. Полезна при проектировании продукта, чтобы не забыть базовое и не утонуть в «вау-функциях».

Стоимость задержки

Подход оценивает, сколько бизнес теряет за каждую неделю, пока задача не сделана, и делит это на длительность работ. Он хорош для задач, привязанных ко времени: сезонные продажи, требования закона, окончание договора с поставщиком.

Как встроить приоритизацию в работу команды?

Приоритизацию встраивают как регулярный короткий ритуал, а не как разовое упражнение: раз в одну-две недели владелец продукта пересматривает верх бэклога вместе с техлидом. Важно, чтобы решение принимал один человек, а команда понимала критерии.

Что помогает:

• один владелец бэклога, который принимает окончательное решение;
• оценка затрат от разработчиков, а не от того, кто предлагает задачу;
• приоритизируется только верх списка — задачи на ближайший месяц;
• у каждой задачи есть формулировка проблемы и ожидаемый результат;
• после релиза сравнивайте ожидаемый эффект с фактическим, чтобы оценки становились точнее.

Отдельная категория — технические задачи: обновления, рефакторинг, безопасность. Если их не выделять явно, они всегда проигрывают продуктовым. Мы обычно резервируем под них фиксированную долю времени команды.

Коротко

• Приоритизация сравнивает задачи по пользе, затратам и риску, а не по громкости запроса.
• RICE удобен для сравнения очень разных задач, MoSCoW — для состава релиза с фиксированным сроком.
• Матрица «ценность — усилия», модель Кано и стоимость задержки отвечают на свои вопросы.
• Пересматривайте верх бэклога регулярно, решение принимает один владелец продукта.
• Резервируйте время на технические задачи, иначе они всегда проигрывают продуктовым.