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

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

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

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

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

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

Бэклог продукта состоит из пользовательских историй (User Story).

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

Также в структуре бэклога могут быть другие («Элементы бэклога»), такие как решение багов, проведение исследований, тесты, исправления, формулирование требований к пользовательским историям и т.д.

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

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

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

Бэклог продукта разрабатывает и ведет Project Manager (или Product Owner, если рассматривать фреймворк Scrum). Именно он занимается приоритизацией элементов бэклога (пользовательских историй). Он же определяет их стоимость, значимость, срочность и т.д.

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

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

Такие изменения могут быть проблемой при реализации каскадной модели разработки. Если же команда работает в рамках фреймворка Scrum или другого подхода в рамках Agile–подхода, значительная часть рисков — в виде потери времени, сил и денег — может быть снята.

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

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

1. Оценивать, полагаясь на личную веру и интуицию;

2. Закапываться в детали;

3. Учитывать только качественную (идеи от support–команды / кастдевы / отзывы в сети) или только количественную (аналитика) оценки;

4. Идти на поводу у хайпа и супер–трендов.