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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Scrum существует множество принципов управления и приоритизации задач.

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

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

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

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

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

1. то, что команда уже выполнила и проверила на работоспособность;

2. Что необходимо сделать, но еще не начато;

3. Над чем еще нужно поработать, прежде чем можно будет считать продукт законченным и готовым к выпуску.

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

Принципы составления бэклога продукта

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

Расставьте приоритеты в своих задачах

Существует множество различных способов определения приоритетности задач — вот лишь некоторые из них:

• Вариант 1: Используйте "технику Канбан", когда вы перемещаете задачи слева направо по мере приближения к завершению. Это поможет вам представить, насколько далеко вы продвинулись в процессе.

• Вариант 2: Используйте подход "совещание по планированию спринта", когда вы группируете связанные задачи по степени приоритетности, а затем обсуждаете их с командой, прежде чем переносить что–либо на бумагу или в цифровое хранилище. Это поможет убедиться, что все согласны с тем, что нужно сделать в первую очередь!