Бэклог — это перечень требований к проекту, которые формируются на основе рекомендаций заказчика на старте работы и обратной связи в процессе сотрудничества. Чем подробнее и качественнее составлен бэклог, тем более глубокое погружение сможет сделать команда проекта. В этой статье мы разберем основные правила систематизации требований и порядок работы с договоренностями, а также то, почему нельзя допускать беспорядка в имеющихся данных.
Начало работы
Любой бэклог стоит начинать с составления дорожной карты, включающей базовые функции и требования. Дорожная карта (Product Roadmap) — это полный стратегический план, включающий все этапы взаимодействия команды с проектом. В идеале в нем должны быть отражены конкретные сроки по проекту. Технические подробности работы могут здесь не расписываться, но обязательно должно присутствовать общее видение продукта, а также цели и миссия. Наиболее важные этапы прописываются в самом начале, чтобы и команда, и клиент могли иметь четкое представление о работе. Структура проекта может быть разбита на несколько ключевых составляющих — пользовательских историй. Заказчик со своей стороны может заниматься упорядочиванием этих историй, управляя деятельностью команды.
Какими могут быть приоритеты работы с командой проекта?
- Важность задачи для заказчика.
- Потребность в регулярной обратной связи.
- Сложность осуществления работы.
- Зависимость одной части задач от другой.
Заказчик играет ключевую роль в формировании этапов работы, но мнение команды также должно учитываться. Команда исходит из внутренних ресурсов, задействованных в реализации. А общая успешность бэклога зависит от регулярной обратной связи между командой и заказчиком, а также внутри разных подразделений команды.
Бэклог спринта и релиза
Бэклог спринта — это заранее оговоренные моменты, которые попадают в обновления продукта после завершения спринта. Требования к ним зависят от содержательной части, а их количество — от опыта команды и сложности поставленных задач. К началу выполнения спринта нужно иметь список того, что предстоит сделать. Изменения в бэклог могут вносить только члены команды, а заказчик имеет возможность лишь наблюдать за изменениями.
Бэклог релиза — это объединение нескольких отдельных спринтов. Релиз также может делиться на части и разбираться в отдельные спринты. Каждое обновление бэклога содержит свежую историю, на основе которой заказчик или пользователи могут давать свою обратную связь. Чем дольше идет работа над проектом, тем ценнее сбор такой информации, потому что полноценное развитие проекта без обратной связи невозможно.
Бэклог проекта
Бэклог проекта — это документ, который содержит список задач и требований, которые необходимо выполнить в ходе проекта. Этот список обычно составляется и регулярно обновляется командой проекта. Вот некоторые типичные элементы, которые могут включаться в бэклог:
| Элемент | Описание |
|---|---|
| Задачи | Конкретные действия или работы, которые должны быть выполнены. |
| Требования | Функциональные или нефункциональные характеристики продукта или проекта. |
| Истории пользователей | Краткие описания функциональности с точки зрения пользователя. |
| Баги и исправления | Задачи, связанные с исправлением ошибок, обнаруженных в процессе разработки или тестирования. |
| Оценки и приоритеты | Оценка сложности и приоритет задачи для определения порядка выполнения. |
| Важность и сроки | Определение важности задачи и сроков её выполнения. |
| Ссылки и дополнительные материалы | Ссылки на дополнительные ресурсы и материалы для задачи. |
Таблица представляет собой общий формат бэклога проекта, и команда проекта может добавлять, изменять или уточнять элементы в зависимости от конкретных потребностей проекта.
Составные части бэклога
Функции продукта
Технические возможности, которые могут быть полезны не только для заказчика, но и для конечного пользователя. Они должны соответствовать критериям приемлемости, информативности и быть оцениваемыми командой. Функции состоят из более простых пользовательских историй и расставляются в соответствии с приоритетами.
Ошибки и баги
Возникают в случае некорректной работы или несоответствия поставленной задаче. Отвечают одной из основных целей любого бэклога — контролю качества и внесению правок. Бывают:
- срочными, связанными с текущими задачами. Такие баги требуют оперативного вмешательства со стороны команды. Часто их не заносят в бэклог, потому что они устраняются сразу;
- решаемыми в текущем спринте. Эти баги не являются срочными, могут быть исправлены в рамках текущего спринта и занесены в его бэклог, а не в конечный бэклог продукта;
- не решаемыми в текущем спринте. На успех продукта в текущем спринте такие баги никак повлиять не могут и должны быть занесены в бэклог продукта.
Технический долг
Появляется из-за переноса задач ради ускорения работы или из-за ошибок в планировании. В будущем повлияет на изменения в конечном продукте. Например, это может быть написание дополнительного кода, который позволит ускорить работу продукта, хотя первоначально такой код был проигнорирован в угоду скорости выполнения задачи.
Исследования
Полноценная работа над продуктом невозможна без обработки информации о нем. Напрямую к конечному пользователю она отношения не имеет, но должна быть обязательно проведена для полного понимания функций продукта. Часто результатом исследования могут стать знания, полученные в ходе мозгоштурма или поиска информации.
Процесс ведения бэклога
После того как бэклог создан и согласован с заказчиком, он корректируется по мере выполнения отдельных задач. Корректировки вносятся на основе выводов по последним итерациям с целью уточнения текущих приоритетов. Постоянная работа с бэклогом и его пересмотр также именуются грумингом или ведением бэклога. Если список требований становится широким, в нем рекомендуется выделять отдельно краткосрочные и долгосрочные задачи. Краткосрочные задачи перед присвоением им этого статуса досконально прорабатываются. Для этого создаются полноценные пользовательские истории, обсуждаются детали работы с дизайнерами и разработчиками, оценивается сложность разработки. С долгосрочными задачами работа строится по более упрощенному сценарию. Они могут быть не проработаны до конца, но должны иметь приблизительную оценку, которая поможет расставить приоритеты.
Модернизация бэклога
По мере работы с проектом часть задач может терять актуальность из-за закрытия, выполнения или понимания их бесполезности. Задачи не всегда должны пропадать из поля зрения участников команды — они могут трансформироваться, получать новые приоритеты. Поэтому отслеживание изменений позволяет команде всегда оставаться в контексте всех нововведений. Это, в свою очередь, позволит оперативно встречаться и обсуждать правки.
Как не должен выглядеть бэклог
Некорректным считается бэклог, в котором:
- заказчик устанавливает требования в самом начале работы, но в процессе сотрудничества не опирается на обратную связь от команды проекта и не корректирует изначальные договоренности;
- команда работает исключительно с теми задачами, которые интересуют только заказчика;
- бэклог не распространяется, а хранится в виде локального файла. Это затрудняет получение информации со стороны заинтересованных лиц.
В каком формате нужно вести бэклог
Единого формата, регулирующего создание и ведение бэклога, не существует. Он может быть представлен в виде гугл-таблицы, специализированной программы или даже блокнота и магнитной доски в офисе. У каждого из форматов есть свои преимущества и недостатки. Например, общие облачные документы позволяют отслеживать правки в реальном времени и обсуждать корректировки. А магнитные офисные доски хорошо подходят для проведения мозгоштурмов.
Как структурировать расширяющийся бэклог
Частая проблема менеджеров продукта — нереальность отслеживания новых возможностей конкурентов, а также обновлений и рекомендаций, которые дают пользователи. В результате бэклог расширяется, его становится проблематично контролировать. Как в таком случае управлять приоритетами?
Решение можно найти на специализированных сервисах (например Hygger). С помощью их инструментов можно:
- структурировать бэклог на основе Kanban-досок;
- оценить идеи с помощью критериев Value и Effort;
- визуализировать и приоритизировать идеи.
Бэклог продукта позволяет четко следовать принципам Agile. Он помогает команде выполнять только ту работу, которая будет полезна конечному продукту, избавиться от лишнего труда, сократить ненужную документацию и оперативно решать возникающие проблемы или вносить актуальные изменения.
0 комментариев