Бэклог продукта: зачем он нужен и как правильно расставить приоритеты

Вольный перевод статьи 5 Key Factors for Effective Product Backlog Prioritization, опубликованной на сайте mountaingoatsoftware.com

Бэклог продукта (Product backlog) — это список всех функций и задач, которые со временем должны появиться в продукте. Неважно, оформлены ли элементы бэклога как пользовательские истории, job stories или просто как краткие заметки — главное, чтобы команда всегда работала над самыми важными задачами. Важно не только внедрять нужные функции, но и делать это в правильной последовательности. Вот пять ключевых факторов, которые помогут грамотно выбрать приоритеты для бэклога продукта.

Фактор 1: Ценность задачи в бэклоге продукта для пользователей и команды

Начнем с самого важного — с ценности. Приоритизация функций всегда опирается на их значимость, но само понятие «ценность» часто трактуют по-разному.

Ценность — это то, насколько функция полезна или влияет на определённую аудиторию. Большинство задач в Agile-командах приносят пользу клиентам Но есть и такие, которые важны только для самой команды. Иногда задача оказывается полезной сразу для всех: пользователей, заинтересованных сторон и разработчиков.

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

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

Фактор 2: Реальные затраты на задачу 

Второй важный вопрос — затраты. Сколько усилий команда тратит на внедрение функции? Чаще всего команды используют story points (стори поинты — условные баллы для оценки сложности) для планирования задач из бэклога продукта. Иногда для оценки берут человеко-дни, идеальное время или похожие единицы.

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

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

Фактор 3: Чему команду учит задача

Еще один важный момент при расстановке приоритетов — чему команда научится, выполняя конкретную задачу? Если реализация задачи даст новый опыт или знания, стоит взяться за нее раньше: так появится время применить полученные навыки на практике.

Если же команда получит знания слишком поздно, использовать их будет уже сложно.

Обучение бывает двух типов: связанное с продуктом и с проектом:

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

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

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

Когда участники берутся за первую задачу из бэклога и используют эту технологию, они узнают:

• Действительно ли технология работает в соответствии с заявленными возможностями?
• Нужно ли пересчитать сроки и усилия, чтобы внедрить эту технологию?
• Можно ли применить ее в других частях продукта или проекта?

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

 Фактор 4: Риски реализации

Четвёртый фактор, который важно учитывать при расстановке приоритетов, — это риск, связанный с задачей из продуктового бэклога. Если элемент несет высокий риск и его обязательно нужно реализовать, займитесь им как можно раньше. Так вы быстрее поймёте, станет ли этот риск реальностью.

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

Фактор 5: Зависимости между задачами

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

 Как расставить приоритеты в бэклоге: рабочие методы

Существует множество инструментов для приоритизации задач. Они помогают сравнивать разные факторы — например, модель Kano, система скоринга RICE или взвешенная оценка. Даже если вы пользуетесь такими формальными подходами, при создании продуктовой дорожной карты важно помнить о тех факторах, которые я перечислил здесь, — даже если они не прописаны в самих моделях.

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