
Бэклог продукта 📜 — примеры управления и приоритизации бэклога задач

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

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

Как управлять бэклогом продукта
Приоритизируйте задачи в соответствии с их Cost of Delay или по другим критериям (важность, срочность, стоимость).

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

Из чего состоит бэклог продукта
Бэклог продукта состоит из пользовательских историй (User Story).
Пользовательская история — это короткое, понятное всем описание того, какая функция или свойство требуется продукту. В списке бэклога пользовательский истории могут быть рассортированы в порядке их срочности, значимости, актуальности, стоимости.
Также в структуре бэклога могут быть другие («Элементы бэклога»), такие как решение багов, проведение исследований, тесты, исправления, формулирование требований к пользовательским историям и т.д.
В результате бэклог продукта значительно отличается от классического списка задач с подробной документацией о том, что и как должно быть сделано.
Он не задает сильных рамок (формирование этих рамок — отдельная задача других процессов, вроде планирования спринта). Он скорее является ориентиром для команды, и служит для понимания того, что именно нужно сделать.
Значимым результатом наличия у продукта хорошего бэклога является то, что команда понимает куда двигается и зачем. А то как именно она будет это делать — отдельная история.

Кто и как ведет бэклог продукта
Бэклог продукта разрабатывает и ведет Project Manager (или Product Owner, если рассматривать фреймворк Scrum). Именно он занимается приоритизацией элементов бэклога (пользовательских историй). Он же определяет их стоимость, значимость, срочность и т.д.
При работе с бэклогом Project Manager может советоваться с другими лицами — например, со стейкхолдерами, с командой разработки. При этом окончательное решение о том, как будет выглядеть бэклог продукта — и, в перспективе, сам продукт — остается за ним.
Нередкая ситуация — когда бэклог продукта требуется изменить, в соответствии с новой информацией и новой реальностью. Например — появление новых конкурентов, новых запросов рынка, новых технологий и т.д. В такой ситуации бэклог продукта необходимо обновлять.
Такие изменения могут быть проблемой при реализации каскадной модели разработки. Если же команда работает в рамках фреймворка Scrum или другого подхода в рамках Agile–подхода, значительная часть рисков — в виде потери времени, сил и денег — может быть снята.

Продуктовый беклог - как с ним жить?
Бэклог продукта позволяет команде ориентироваться в разработке продукта, принимать эффективные решения о порядке и способах разработки.
Занимается разработкой, ведением и обновлением бэклога продукта Project Manager. Он отвечает за то, чтобы бэклог продукта был актуальным и отражал значимые для продукта элементы, которые ведут к достижению бизнес–ценности, в том числе прибыли.

Как не стоит работать с приоритетами?
Оценивать, полагаясь на личную веру и интуицию;
Закапываться в детали;
Учитывать только качественную (идеи от support–команды / кастдевы / отзывы в сети) или только количественную (аналитика) оценки;
Идти на поводу у хайпа и супер–трендов.