Приоритизация бэклога продукта: как решить, что действительно делать дальше

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

Обычно происходит обратное: идей, запросов, улучшений и обязательных доработок становится больше, чем команда успевает реализовать.

В backlog одновременно попадают:

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

Через несколько месяцев бэклог может содержать десятки или сотни элементов.

И тогда проблема уже не в том, чтобы придумать следующую задачу.

Проблема — понять:

что из этого действительно должно получить ресурс команды раньше, а что может подождать или вообще никогда не попасть в разработку.

Именно для этого нужна приоритизация бэклога.

Но важно не путать её с календарным планированием.

Приоритизация отвечает:

что важнее?

Планирование отвечает:

когда команда реально сможет это сделать?

Хороший продуктовый процесс должен связывать оба уровня.

Бэклог — не обязательство сделать всё

Одна из самых вредных привычек — воспринимать backlog как длинную очередь, в которой каждая задача рано или поздно должна быть выполнена.

На практике backlog — это скорее набор возможностей и потенциальных решений.

Часть элементов может:

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

Это нормально.

Хороший backlog не обязан постоянно расти.

Если Product Owner только добавляет новые элементы, но почти никогда ничего не удаляет, со временем список превращается в архив пожеланий, а не инструмент управления продуктом.

Что именно нужно приоритизировать

В одном backlog могут оказаться сущности разного масштаба.

Например:

• «изменить текст кнопки»;
• «добавить восстановление пароля»;
• «переработать onboarding»;
• «запустить новый тариф»;
• «мигрировать на новую архитектуру».

Сравнивать их напрямую сложно.

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

Поэтому полезно разделять уровни.

Инициативы

Крупные продуктовые изменения и направления.

Например:

• новая модель оплаты;
• новый onboarding;
• интеграция с партнёром;
• аналитика для корпоративных клиентов.

Фичи и задачи

Конкретные элементы внутри инициатив.

Например:

• новый экран регистрации;
• дополнительный фильтр;
• API-метод;
• уведомление.

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

Не каждый элемент backlog должен иметь точный приоритет

Если в backlog 300 идей, нет большого смысла тщательно рассчитывать порядок от первой до трёхсотой.

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

Поэтому приоритизация может иметь разную точность.

Например:

Ближайшая очередь

Инициативы, которые команда рассматривает для запуска в ближайшее время.

Для них нужен понятный относительный порядок.

Следующий горизонт

Работы, которые выглядят перспективно, но ещё требуют исследования или уточнения.

Дальний backlog

Идеи, к которым команда может вернуться позже.

Так Product Owner не тратит время на создание ложной точности для работы, которая, возможно, никогда не начнётся.

Сначала сформулируйте критерии

Приоритизация без критериев быстро превращается в спор мнений.

Один участник говорит:

Клиенты давно это просят.

Другой:

Эта функция даст больше выручки.

Третий:

Сначала нужно закрыть технический долг.

Все могут быть правы.

Поэтому полезно заранее определить, какие факторы команда принимает во внимание.

Обычно это сочетание нескольких критериев.

Пользовательская ценность

Какую проблему пользователя решает инициатива?

Бизнес-ценность

Как она влияет на выручку, удержание, конверсию, затраты или стратегическую позицию продукта?

Охват

Сколько пользователей или клиентов получат эффект?

Срочность

Есть ли ограничение по времени?

Уверенность

Насколько хорошо подтверждена гипотеза?

Усилия

Сколько ресурсов требуется?

Риск

Что произойдёт, если работу не делать?

Стратегическое соответствие

Поддерживает ли инициатива выбранное направление продукта?

Набор критериев зависит от продукта.

Главное — чтобы он был понятен и использовался последовательно.

RICE для приоритизации бэклога

RICE удобно использовать, когда нужно сравнить несколько продуктовых инициатив.

Модель обычно включает:

• Reach — охват;
• Impact — влияние;
• Confidence — уверенность;
• Effort — усилия.

Смысл подхода — не просто поставить каждой идее оценку, а заставить команду ответить на конкретные вопросы.

Например:

Сколько пользователей реально затронет функция?

Насколько большой эффект мы ожидаем?

Насколько уверены в гипотезе?

Какой объём разработки потребуется?

Это делает обсуждение более предметным.

Но итоговый балл нельзя воспринимать как абсолютную истину.

Он зависит от качества исходных оценок и не учитывает автоматически все ограничения реального продукта.

ICE — быстрый вариант для ранних гипотез

ICE обычно использует:

• Impact;
• Confidence;
• Ease.

Подход проще и быстрее.

Он подходит, когда у команды ещё мало данных и нужно быстро отсортировать набор гипотез.

Но чем субъективнее исходные оценки, тем осторожнее нужно относиться к итоговому числу.

Например, разница между 7 и 8 баллами по Impact может выглядеть математически значимой, хотя на самом деле основана на ощущении команды.

Поэтому ICE полезен как способ структурировать разговор, а не как автоматический механизм принятия решения.

Value/Effort: когда сложная формула не нужна

Очень практичный способ первичной сортировки — сравнить ценность и усилия.

Инициативы можно условно разделить на четыре группы.

Высокая ценность / низкие усилия

Хорошие кандидаты на раннюю реализацию.

Высокая ценность / высокие усилия

Крупные стратегические инвестиции.

Низкая ценность / низкие усилия

Можно делать, если есть свободная мощность, но они не должны автоматически вытеснять важные работы.

Низкая ценность / высокие усилия

Кандидаты на отказ.

Преимущество метода — простота.

Для многих команд этого уже достаточно, чтобы очистить backlog и сократить количество спорных инициатив.

MoSCoW полезен, когда нужно определить границы

Подробный разбор RICE, ICE, MoSCoW и Value/Effort — в статье про приоритизацию задач. MoSCoW делит требования на четыре категории:

• Must have;
• Should have;
• Could have;
• Won't have now.

Метод особенно полезен для определения состава релиза или конкретной инициативы.

Например, если команда понимает, что весь scope не помещается в срок, MoSCoW помогает определить обязательную часть.

Но для всего продуктового backlog у подхода есть ограничение.

Если 20 элементов получили статус Must, их всё равно нужно упорядочить между собой.

Поэтому MoSCoW лучше использовать для границ объёма, а не как единственный способ построения полной очереди.

Не превращайте приоритизацию в соревнование формул

Команда может потратить много времени на выбор между RICE, ICE, WSJF, Value/Effort и собственными моделями.

Но качество решения часто зависит не от формулы.

Гораздо важнее:

• одинаково ли понимаются критерии;
• есть ли данные;
• сравниваются ли сущности одного уровня;
• готовы ли участники действительно выбирать;
• меняет ли результат фактический порядок работы.

Если после двух часов расчётов все инициативы всё равно получают статус «очень важная», процесс не работает.

Хорошая приоритизация требует отказа

Приоритет — это не способ сказать каждой заинтересованной стороне, что её запрос важен.

Это способ решить, что не будет сделано сейчас.

Предположим, команда способна реализовать три крупные инициативы за квартал.

Кандидатов семь.

Тогда результат хорошей приоритизации — не семь задач с разными цветными метками.

Результат:

эти три идут в план; две остаются следующими кандидатами; две мы сознательно не берём.

Именно отказ создаёт фокус.

Без него backlog продолжает давить на команду, даже если физически выполнить всё невозможно.

Не позволяйте небольшим задачам вытеснять важные инициативы

Есть распространённая ловушка.

Небольшую задачу легче начать и завершить.

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

В отчётах всё выглядит хорошо:

• много закрытых задач;
• хороший throughput;
• backlog сокращается.

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

Поэтому приоритизация должна учитывать не только эффективность выполнения отдельных задач, но и важность инициативы, частью которой они являются.

Технический долг тоже должен участвовать в приоритизации

Технический долг часто существует в отдельном списке и конкурирует с продуктовой разработкой неявно.

Это приводит к двум крайностям.

Первая:

бизнес-фичи всегда важнее, технический долг подождёт.

Вторая:

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

Полезнее включать значимые технические работы в общий процесс выбора.

Но критерии могут отличаться.

Для технической инициативы важны:

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

Тогда Product Owner может сравнивать не «фича против непонятной технической задачи», а два вида ценности и риска.

Как работать с запросами крупных клиентов

Запрос крупного клиента легко получает максимальный приоритет просто из-за его размера.

Иногда это оправданно.

Но полезно задать дополнительные вопросы:

• запрос специфичен только для одного клиента?
• сможет ли функция использоваться другими?
• есть ли контрактное обязательство?
• какова потенциальная выручка?
• насколько решение усложнит продукт?
• какой объём разработки потребуется?
• что придётся отложить?

Тогда решение становится осознанным.

Сам факт важности клиента не отменяет стоимость альтернатив.

Как учитывать срочность

Срочность — опасный критерий.

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

Поэтому полезно различать:

Реальную срочность

Есть внешний срок или значимый риск.

Например:

• законодательное требование;
• обязательство перед клиентом;
• закрытие критической уязвимости;
• зависимость от внешнего запуска.

Организационную срочность

Кто-то хочет получить результат быстрее, но объективного ограничения нет.

Оба запроса могут быть важными.

Но они не должны автоматически получать одинаковый вес.

Регулярно очищайте backlog

Приоритизация — это не только сортировка.

Хороший Product Owner регулярно удаляет элементы.

Причины могут быть разными:

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

Удаление старой идеи — не потеря.

Это снижение информационного шума.

Чем чище backlog, тем проще работать с действительно актуальными решениями.

Как часто пересматривать приоритеты

Нет универсальной периодичности.

Можно сочетать два режима.

Регулярный пересмотр

Например, раз в неделю или раз в несколько недель команда обновляет ближайшую очередь.

Событийный пересмотр

Приоритеты меняются при существенном событии:

• появилась новая информация;
• изменился рынок;
• возник срочный риск;
• пришёл значимый клиентский запрос;
• изменилась стратегия;
• текущая инициатива сильно изменила оценку.

Важно другое: не пересматривать всю очередь каждый день без причины.

Если приоритет постоянно скачет, команда теряет фокус.

Приоритет backlog не равен календарной дате

Допустим, очередь выглядит так:

1. Инициатива A.
2. Инициатива B.
3. Инициатива C.

Это ещё не означает:

A начинается сегодня, затем B, потом C.

Почему?

Потому что у инициатив разные этапы и ресурсы.

Для A может быть нужен аналитик, который занят ещё неделю.

У B может быть независимый дизайн, который можно начать сейчас.

C может зависеть от внешнего поставщика.

Поэтому приоритет задаёт правило разрешения конфликтов, а не полностью определяет календарь.

Именно здесь заканчивается приоритизация и начинается планирование.

Как перейти от приоритизированного backlog к плану

Практический переход выглядит так.

Шаг 1. Выберите ближайшие инициативы

Не пытайтесь календарно планировать весь backlog.

Берите только тот горизонт, который действительно претендует на ресурсы.

Шаг 2. Зафиксируйте относительный порядок

Должно быть понятно, какая инициатива получает ресурс первой при конфликте.

Шаг 3. Разложите инициативы на этапы

Например:

• аналитика;
• дизайн;
• backend;
• frontend;
• QA.

Шаг 4. Оцените длительность

Получите рабочие оценки этапов.

Шаг 5. Назначьте ресурсы

Определите, кто должен выполнять работу.

Шаг 6. Укажите зависимости

Что должно закончиться до начала следующего этапа?

Шаг 7. Учтите текущую загрузку

Специалисты уже выполняют другую работу.

Шаг 8. Рассчитайте календарную последовательность

Теперь становится понятно:

• что можно начать сразу;
• что ждёт ресурс;
• когда стартует каждая инициатива;
• когда она завершится.

Это и есть переход от backlog к исполнимому плану.

Что происходит, когда приоритет изменился

Представим, что инициатива C была третьей, но после нового клиентского обязательства становится первой.

В backlog достаточно переместить карточку вверх.

В реальном плане этого мало.

Нужно пересчитать:

• какую работу получит общий ресурс первой;
• что сдвинется;
• какие даты изменятся;
• какие инициативы выйдут за текущий квартал.

Поэтому изменение приоритета имеет стоимость.

И полезно видеть её до принятия решения.

Какие признаки показывают, что backlog управляется плохо

Слишком много элементов

Никто не понимает, актуальны ли задачи в нижней части списка.

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

Значит, реального порядка нет.

Старые задачи никогда не удаляются

Backlog превращается в архив.

Команда выбирает работу по удобству

Выполняется то, что легче взять, а не то, что важнее.

Приоритет не влияет на ресурсы

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

Приоритеты меняются каждый день

Команда не успевает завершать начатую работу.

После приоритизации никто не может назвать сроки

Это означает, что процесс остановился на выборе, но не перешёл к планированию.

Где здесь KORDO

KORDO не предназначен для хранения бесконечного списка продуктовых идей.

Для этого уже существуют backlog и task-management инструменты.

Роль KORDO начинается тогда, когда Product Owner выбрал инициативы, которые действительно должны претендовать на ресурсы команды.

Им можно задать относительный приоритет, разложить на этапы, назначить исполнителей и зависимости и получить календарную последовательность.

Так решение:

«инициатива A важнее инициативы B»

превращается в практическое следствие:

«при конфликте A получает общий ресурс раньше, поэтому её срок становится таким, а B — таким».

Если приоритет меняется, последствия можно увидеть после отдельного расчёта. Опубликованный План меняется только после явной публикации новой версии.

Таким образом, backlog остаётся местом выбора возможностей, а KORDO работает с теми инициативами, которые уже нужно превратить в реальный план.

Главное

Приоритизация бэклога — это не сортировка карточек ради порядка.

Это механизм выбора.

Хороший процесс отвечает на несколько вопросов:

Что действительно создаёт ценность?

Чему мы доверяем достаточно, чтобы инвестировать ресурс?

Что важнее при конфликте?

Что мы сознательно не будем делать сейчас?

После этого появляется следующий уровень:

когда выбранные инициативы реально смогут пройти через существующую команду?

Поэтому полезная цепочка выглядит так:

идеи → критерии → приоритизация → выбор → ресурсы → календарный план.

Backlog помогает решить, что заслуживает внимания команды.

Планирование показывает, когда команда сможет это реализовать.

И только вместе эти два процесса создают управляемое развитие продукта.