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

Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.

Бэклог продукта — это перечень задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты продукта и требований в ней. Наиболее важные элементы расположены в начале бэклога, чтобы команда понимала, чем следует заняться в первую очередь. Скорость, с которой участники выполняют задачи бэклога, не зависит от желаний владельца продукта, и он не должен оказывать давление на команду. Напротив, разработчики самостоятельно выбирают задачи из бэклога продукта с учетом доступных ресурсов. Работа при этом ведется непрерывно (Kanban) либо в рамках итераций (Scrum).

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

Попробовать Scrum-доски Jira

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

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

• Более точные приоритеты. Бэклог продукта помогает решать самые важные задачи в первую очередь.
• Повышение эффективности. Сортируя задачи на основе отзывов клиентов и бизнес-целей, команды могут сосредоточиться на наиболее ценных из них.
• Улучшение коммуникации. Бэклог продукта помогает согласовывать действия всех сотрудников в достижении общих целей.
• Экономия ресурсов. Опираясь на отзывы клиентов и бизнес-цели, команды могут экономить ресурсы и не работать над бесполезными задачами.
• Повышение удовлетворенности клиентов. Когда приоритеты расставлены по отзывам клиентов, команды поставляют клиентам востребованные функции и возможности.

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

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

Веб-сайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.

Владелец продукта составляет из этих пользовательских историй единый список для команды разработчиков. Владелец продукта может упорядочить истории так, чтобы команда сначала выполнила один эпик полностью (слева). Как вариант, может быть важнее сначала протестировать бронирование билетов со скидкой, а для этого нужно реализовать истории из нескольких эпиков (справа). Оба варианта представлены ниже.

Что может повлиять на то, как владелец продукта расставляет приоритеты?

• Важность для клиента
• Необходимость в обратной связи
• Относительная сложность реализации
• Тесная взаимосвязь между рабочими задачами (например, сделать «Б» будет проще, если сначала сделать «А»)

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

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

Создание бэклога — важный шаг в Agile-разработке продукта. Оно включает составление дорожной карты продукта, внесение задач в бэклог и общение с командой.

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

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

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

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

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

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

Все еще нужна помощь? Попробуйте бесплатный шаблон бэклога продукта в Jira.

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

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

• Выявите наиболее полезные для пользователей функции или исправления.
• Опирайтесь на отзывы клиентов, опросы или аналитику при определении приоритетов.

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

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

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

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

Подсказка. Используйте системы расстановки приоритетов, такие как MoSCoW (обязательные, важные, возможные и несущественные задачи) или взвешенная оценка, чтобы принимать объективные и обоснованные решения. Команды могут внедрить собственные уникальные системы расстановки приоритетов, используя гибкую функцию приоритизации в Jira Product Discovery.

После создания бэклога необходимо регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить приоритеты и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога продукта, который в кругах специалистов по Agile часто называют грумингом, помогает согласовать задачи с аналитикой заинтересованных сторон и подготовить команду к будущему спринту (некоторые используют термин уточнение бэклога).

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

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

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

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

Плохие примеры, которые лучше не повторять

• Владелец продукта расставляет приоритеты в бэклоге в начале проекта, но не корректирует их по мере поступления информации от разработчиков и заинтересованных сторон.
• Команда добавляет в бэклог только те задачи, которые ориентированы на клиентов.
• Бэклог хранится как локальный документ и редко передается кому-либо, поэтому заинтересованные стороны не узнают об изменениях.

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

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

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

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