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

Тема сегодняшнего спича — бэклог продукта. Мы поговорим о том, что это такое, зачем это нужно и как его правильно составлять. Сегодня вам про это расскажет член нашей команды под условным именем "XXX". Приступим?

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

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

Бэклог продукта — основа для планирования спринтов в Scrum или потоков работ в Kanban. Там команда выбирает элементы из бэклога для реализации в течение предстоящего цикла разработки. Это гарантирует, что работа команды всегда выравнивается с текущими целями и приоритетами проекта.

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

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

Теперь перейдем к различиям между бэклогом продукта и бэклогом спринта:

1. Масштаб. Бэклог продукта охватывает весь продукт: улучшения, функции и исправления, которые могут быть реализованы в будущем. Бэклог спринта фокусируется на конкретном, ограниченном наборе задач, выбранных для выполнения в предстоящем спринте.
2. Динамика изменений. Бэклог продукта постоянно эволюционирует и обновляется в зависимости от изменений требований бизнеса, приоритетов и обратной связи от пользователей. Бэклог спринта может подвергаться незначительным изменениям и в основном остается стабильным в течение спринта, чтобы команда могла сфокусироваться на достижении конкретных целей.
3. Уровень детализации. Задачи в бэклоге спринта обычно более детализированы и разбиты на меньшие задачи по сравнению с элементами бэклога продукта. Это гарантирует команде четкое понимание того, что нужно делать и какие результаты должны быть достигнуты к концу спринта.
4. Участники. Владелец продукта отвечает за управление бэклогом продукта и определение приоритетов задач в нем. Бэклог спринта формируется с командой разработки и владельцем продукта во время планирования спринта, где команда выбирает из бэклога продукта задачи, которые они считают возможным выполнить в течение следующего спринта.

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

Как правильно составлять бэклог продукта? Что в него входит? Про что нельзя забывать?

1. Пользовательские истории (User Stories). Краткие описания функциональности с точки зрения конечного пользователя. Они помогают команде понять, чего пользователь хочет достичь и почему.
2. Функциональные возможности (Features). Более крупные блоки работы, которые могут быть декомпозированы на более мелкие задачи или пользовательские истории.
3. Баги (Bugs). Записи об ошибках или проблемах в существующем продукте, которые нужно исправить.
4. Технический долг (Technical Debt). Указывает на необходимость улучшения структуры кода или архитектуры системы, чтобы облегчить добавление функциональности или улучшение производительности в будущем.
5. Улучшения (Improvements). Идеи по оптимизации, улучшению существующих функций для повышения удобства использования, производительности продукта.

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

Владелец продукта (Product Owner)

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

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

Команда разработки

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

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

Заинтересованные стороны (Stakeholders)

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

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

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

На основе нашего опыта мы приготовили для вас несколько полезных лайфхаков.

1. Используйте пользовательские истории.

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

"Как [роль пользователя], я хочу [цель], чтобы [причина]".

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

2. Приоритизация MSCW.

Метод MSCW помогает расставить приоритеты в элементах бэклога по категориям:

• Must Have (Обязательно);
• Should Have (Желательно);
• Could Have (Можно, но не обязательно);
• Won’t Have (Не будет в этот раз).

Это гарантирует ясность и согласованность в понимании того, над чем команда должна работать в первую очередь.

3. Регулярное обновление и уточнение.

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

4. Визуальное отображение.

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

5. Ограничьте количество элементов в бэклоге.

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

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

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