Бэклог продукта - один из основных артефактов Product owner, он относится к стадии Development (Разработка) фреймворка для управления инициативами. Работа с бэклогом продукта, управление им и поддержание его в актуальном состоянии - одна из ключевых зон ответственности Product owner.
Бэклог продукта - это приоритизированный список того, что вы планируете делать в продукте.
Откуда берутся составляющие бэклога продукта?
- Например, из «Бэклога гипотез» - в бэклог продукта вы берете валидированные, подтвержденные гипотезы, в которых вы уверены, что они принесут нужный эффект и помогут реализовывать то, что нужно.
- Часто Владельцы продукта в свой бэклог продукта записывают все идеи, какие у них есть, все, что прилетает от кого-либо. Потом они постепенно начинают разбирать эти элементы.
Бэклог продукта является источником задач для бэклога спринта
Т.е. когда вы с командой осуществляете планирование, чтобы определить цель ближайшей итерации и взять задачи на ближайшую неделю или две, эти задачи вы должны брать из бэклога продукта.
При этом бэклог продукта постоянно обновляется, это не "застывший" артефакт.
В предлагаемом нами шаблоне бэклога продукта есть список задач, у каждой из которых есть список атрибутов.
Мы фиксируем месяц релиза, команду, которая выполняет задачу, если команд несколько, заказчика, статус, степень влияния каждой задачи на ключевые метрики продукта (не больше двух-трех) в весах. Вы можете использовать ту шкалу для определения влияния, которую даем вам мы, но сами выбираете, с какой шкалой вам удобнее работать.
Предлагаемая шкала
- 0 – нет никакого влияния на метрику
- 1 – soft-эффект
- 2 - прямой эффект и слабое влияние
- 3 - прямой эффект на метрику и сильное влияние
В бэклоге продукта должна присутствовать оценка трудозатрат по каждой задаче (item).
Ее можно делать в разных единицах - например, story points (это, в основном, практикуют в IT), человеко-днях, человеко-часах, можно составить шкалу, например, 1- менее недели, 2 - от одной до четырех недель, … 7 - все, что больше трех недель.
Оценка ценности (value), которая рассчитывается через влияние на метрики, и оценка трудозатрат дает интегральный показатель, который определяет приоритет задачи.
Наверху списка задач в бэклоге всегда находится то, что обладает наибольшим приоритетом.
Формула расчета приоритета - ценность делим на трудозатраты (оценка команд разработки)
По столбцу приоритета вы можете далее отсортировать бэклог и понять, что вам нужно делать в первую очередь и так далее.
То, что приносит больше value и стоит меньше всего для компании, для команды, то получает наивысший приоритет. Элементы, которые делать долго, сложно и дорого, а эффект приносят незначительный, получат меньший приоритет.
Если вы ведете трекинг задач в каком-то онлайн-инструменте, трекере - Jira, Trello и т.п. - то в бэклог продукта можно вставлять ссылки на эти самые задачи из трекера
Элементы, находящиеся в бэклоге наверху, должны быть максимально проработаны и детально оценены. Чаще всего такие элементы уже разделены на подзадачи, т.е. на множество мелких задач, которые нужно выполнить, чтобы основная задача была реализована.
Один из основных подходов к формированию задач в бэклоге - User stories. User stories - это супермаленькие пользовательские истории, на которые мы, например, делим большую историю с помощью User story map.
- Должны быть детально проработаны задачи вверху бэклога продукта на ближайшие 1-2 спринта. Это самые важные, самые приоритетные задачи.
- Ниже в бэклоге нужно поставить менее проработанные задачи. Это могут быть более крупные user stories, которые еще предстоит разделить на более мелкие задачи.
Рекомендация: таких элементов должно быть на 1-2 ближайших месяца. Т.е. одним-двумя спринтами мы покрываем горизонт первого месяца.
- Ниже в бэклоге продукта находятся так называемые эпики. Это совсем непроработанные истории. Они имеют отношение к долгосрочному планированию - что мы глобально в будущем планируем делать, большие «куски» работ. Здесь горизонт - от трех месяцев и далее, и список этих эпиков может быть бесконечным.
Все это нужно для правильного, корректного управления ожиданиями стейкхолдеров. Очень важно знать производительность команды и понимать, какие трудозатраты за одну итерацию она может нести.
Вы можете задать статусы элемента бэклога – как предлагаемые нами, так и свои.
Можно использовать, например, такой список статусов.
- Backlog - планируем в будущем что-то с этим сделать, еще не прорабатывали не изучали
- Discovery - это статус research, исследований, когда мы проводим эксперименты и проверяем гипотезы
- Estimation - это когда мы проектируем наше решение и оцениваем его вместе с командой
- To do - это статус, когда мы все исследовали, спроектировали, задизайнили, задача лежит в бэклоге и уже готова браться в работу
- In progress - задача в работе, в реализации
- Done - это когда мы ее сделали, зарелизили
- Block - когда по какой-либо причине мы не можем продолжать работать над задачей, есть некоторый блокатор
Это инструмент для планирования ресурсов.
Когда у вас есть месяц, задача и команда, вам с помощью этого всего очень легко составить будет roadmap пробного продукта.
Сортировку задач в бэклоге можно настроить по статусу.
Задачи со статусом «Done» можно переместить вниз. Истории со статусом «To do» и «In progress» лучше видеть вверху списка. Все остальное ниже можно отсортировать по приоритету.
Но при этом, если вдруг какой-то приоритет окажется выше, то это говорит о том, что нужно как можно скорее оценить эту задачу и уточнить эту оценку, задизайнить решение, как оно будет выглядеть, может быть, разделить на какие-то меньше истории.
И, возможно, какие-то из них сместят ту историю, которая уже есть в «To do» и имеет свой приоритет, но мы понимаем, что есть более важная, более потенциальная история.
Хотите научиться работать с бэклогом продукта и другими продуктовыми артефактами, освоить профессию "продакта"? Мы всегда на связи – Telegram, сайт, info@neuromap.tech.