Бэклог продукта: что это и как вести

Бэклог продукта (product backlog) — это единый упорядоченный список всего, что команда потенциально может сделать с продуктом: новые функции, улучшения, исправления багов, технические задачи и идеи. Ключевых свойств у бэклога два: он приоритизирован — наверху лежит самое ценное, что берут в работу первым, а внизу то, что можно отложить или не делать вовсе; и он живой — постоянно пополняется, пересматривается и чистится. Бэклог отвечает на вопрос «что команда будет делать дальше» в любой момент времени и служит главным рабочим инструментом product owner.

Что такое бэклог продукта

Бэклог — это не список задач в привычном смысле и не свалка идей. Это отсортированная по ценности очередь работы. Представьте воронку: сверху — то, что вот-вот пойдёт в разработку, оно проработано детально; ниже — то, что случится позже, описано крупно; на самом дне — сырые идеи «на подумать».

Важно понимать, что бэклог живёт на уровне конкретных задач, а не стратегии. Если роадмап отвечает на вопрос «зачем и в каком порядке мы развиваем продукт», то бэклог — на вопрос «что именно команда сделает в ближайших спринтах». Один пункт роадмапа вроде «улучшить онбординг» может разворачиваться в десяток задач в бэклоге.

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

Из чего состоит бэклог

Обычно в бэклог попадают элементы нескольких типов:

• •Пользовательские истории — новые функции с точки зрения пользователя, сформулированные как user story.
• •Улучшения — доработки того, что уже есть.
• •Баги — то, что работает не так, как задумано.
• •Технический долг — рефакторинг, обновления, работа «под капотом», которую не видит пользователь, но без которой продукт деградирует.
• •Исследовательские задачи — гипотезы и эксперименты, которые нужно проверить, прежде чем что-то строить.

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

Как приоритизировать бэклог

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

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

Что такое груминг бэклога

Груминг (backlog refinement, или уточнение бэклога) — это регулярная работа по поддержанию бэклога в порядке. Без груминга даже хорошо начатый бэклог за пару месяцев превращается в свалку. Что делают на груминге:

• •Уточняют задачи. Верхние пункты доводят до состояния, когда команда понимает, что делать и что считать успехом.
• •Дробят крупное. Большие расплывчатые задачи режут на мелкие и понятные, которые реально взять в спринт.
• •Переоценивают приоритеты. Появились новые данные — что-то поднимается наверх, что-то опускается.
• •Удаляют мусор. Задачи, которые висят полгода и которые команда точно не возьмёт, безжалостно удаляют.

Груминг обычно проводят раз в спринт, командой, на 30–60 минут. Это не бюрократия, а гигиена: чистый бэклог экономит часы споров на планировании.

Полезное правило груминга — детально проработанным должен быть только верх бэклога, примерно на два спринта вперёд. Всё, что ниже, держат крупными формулировками: тратить время на вылизывание задач, до которых команда доберётся через полгода, бессмысленно — к тому моменту они десять раз изменятся. Такой подход экономит силы и не создаёт ложного ощущения, что дальний план уже готов.

Бэклог, который только растёт и никогда не сокращается, — это не бэклог, а кладбище идей. Удалять задачи так же важно, как добавлять.

Чем бэклог отличается от роадмапа

Их часто смешивают, хотя они работают на разных уровнях:

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

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

Типичные ошибки

• •Бэклог-свалка. Тысячи задач без приоритета. Никто не понимает, что важно, и команда берёт в работу то, что попалось на глаза.
• •Слишком детальный дальний горизонт. Команда вылизывает описания задач, до которых доберётся через полгода и которые сто раз изменятся.
• •Приоритет по громкости. Наверх пробивается не ценное, а то, что продавил самый настойчивый. Явная модель приоритизации это лечит.
• •Игнорирование техдолга. В бэклоге только новые фичи, техдолг копится, скорость команды падает, и никто не понимает почему.
• •Бэклог без груминга. Список ведут, но не чистят. Через квартал он превращается в архив, которым никто не пользуется.
• •Бэклог как склад чужих хотелок. Каждую просьбу механически заносят в список, не проверяя, работает ли она на цель продукта.

Итог

Бэклог продукта — это живая приоритизированная очередь работы, а не архив всех идей, что когда-либо приходили в голову. Держите наверху самое ценное, уточняйте ближний горизонт, регулярно грумите и не бойтесь удалять то, что никогда не возьмёте в работу. Отличайте его от роадмапа: один про «зачем», другой про «что». Как продуктовые команды выстраивают приоритизацию и борются со свалкой в бэклоге, разбирают на профильных деловых мероприятиях, где практики делятся живыми приёмами, а не теорией из учебника.