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

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

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

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

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

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

A well-managed product backlog can bring numerous benefits to a development team. Some of the key benefits include:

• Improved prioritization: A product backlog helps to ensure that the most critical tasks are being worked on first.

• Increased efficiency: By prioritizing tasks based on customer feedback and business objectives, teams can ensure they work on the most valuable tasks.

• Better communication: A product backlog ensures everyone is aligned and working towards the same goals.

• Reduced waste: By prioritizing tasks based on customer feedback and business objectives, teams can reduce waste and ensure that they are not working on tasks that are not valuable.

• Improved customer satisfaction: By prioritizing tasks based on customer feedback, teams can ensure they deliver customers' desired features and functionality.

Overall, a well-managed product backlog is essential for agile product development. It ensures that teams are working on the most valuable tasks and that everyone is aligned and working towards the same goals.

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

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

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

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

• Важность для клиента

• Необходимость в обратной связи

• Относительная сложность реализации

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

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

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

Составление дорожной карты продукта

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

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

Внесение задач в бэклог продукта

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

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

Так команда разработчиков будет решать задачи, которые принесут наибольшую пользу.

Общение с командой

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

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

Попробуйте бесплатный шаблон бэклога продукта в Jira.

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

Шаг 1. Оцените потребности клиентов

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

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

Шаг 2. Оцените срочность получения обратной связи

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

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

Шаг 3. Учтите сложность реализации

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

• Взвесьте соотношение усилий и ценности, чтобы разумно использовать ресурсы.

Шаг 4. Примите во внимание зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

• Команда добавляет в бэклог только те задачи, которые ориентированы на клиентов.

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

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

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

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

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