Бэклог задач в разработке продукта: как его составить и приоритизировать

Михаил

Шумовский

Автор статьи

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

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

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

Бэклог — хранилище идей и задач

Как правильно сформировать бэклог

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

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

Из чего состоит бэклог

Функций продукта. Здесь описывают все функциональные требования, которые нужны пользователям. Например, возможность добавлять товары в корзину, оформлять заказ, отслеживать статус доставки. При определении нужных функций важно расставлять приоритеты: сначала реализовать самые важные функции, без которых продукт не может работать, а потом добавлять остальные.

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

Ошибки в бэклоге нужно разбивать на:

• Срочные, которые связаны с текущими задачами. Их нужно решать сразу.
• Средней срочности, которые нужно решить в течение спринта. 
• Низкой срочности, которые нельзя решить в течение спринта. Несрочными считаются ошибки, которые не влияют на успех продукта в текущем спринте.

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

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

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

Как сделать бэклог

Работа с бэклогом начинается со «скелета» — базовых функций и ключевых задач, которые должны присутствовать в продукте. Чтобы определить базовые задачи, обычно используют Product Roadmap (дорожную карту проекта), User Stories (пользовательские истории) и Customer Journey Map (карта пути клиента).

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

Простой пример Roadmap: без конкретных дат, но с конкретными задачи

Задачи и пояснения к ним обычно отражают в User Stories. User Stories — это описание функций продукта с точки зрения пользователя. Например, «Как пользователь, я хочу сохранять свои данные, чтобы не вводить их каждый раз заново». Такие истории помогают понять, что именно нужно пользователю и как это реализовать.

User Stories обычно визуализируют с помощью Customer Journey Map. Это визуальное представление пути пользователя от первого контакта с продуктом до достижения цели. Customer Journey Map помогает понять, какие задачи в бэклоге действительно важны для пользователя, а какие — нет. Например, если на карте видно, что пользователь тратит много времени на поиск нужной функции, то задача по улучшению навигации должна быть приоритетной.

Так может выглядеть карта пути клиента

На основе этих документов можно сделать бэклог. Для этого нужно:

1. Составить список функций, которые нужно реализовать. Желательно сразу расставить их по приоритету на дорожной карте.
2. Написать техническое задание в формате User Story для каждой функции. Это поможет понять, как каждая функция поможет пользователям. 
3. Оценить важность каждой функции и разместить их в бэклоге по приоритету.
4. Обсудить задачи с командой. Определить, кто за что отвечает, и установить сроки.

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

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

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

Сначала компания сформулировала общие задачи: добавить новые фильтры для поиска жилья, улучшить интерфейс выбора дат и внедрить систему оценки жилья. Затем эти задачи оценили по важности и сложности, а также расставили по приоритету.

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

Бэклог проекта, спринта и релиза: в чем отличие и как их организовать

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

Бэклог спринта — это список конкретных задач, которые команда берет для выполнения в текущем спринте. Обычно спринт длится 2−4 недели, и в его бэклоге оказываются только те задачи, которые команда успеет выполнить за этот период.

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

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

• Discovery backlog — список задач, которые нужно исследовать и проверить. Например, провести интервью с пользователями, протестировать прототип или проанализировать данные. Цель такого бэклога — снизить неопределенность и риски в проекте.
• Delivery backlog — список задач, которые нужно выполнить, чтобы доставить ценность пользователям. Например, разработать новую функцию, исправить баги или улучшить производительность. Цель такого бэклога — как можно быстрее предоставить пользователям работающий продукт.

виды бэклога

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

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

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

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

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

Как не запутаться в бэклоге

Чтобы не запутаться в растущем количестве задач, нужно разделять их на эпики, фичи и пользовательские истории.

• Эпик — это крупная цель или функция, которая обычно не может быть реализована за один спринт. Эпик помогает ориентироваться на долгосрочные цели, которые затем разбиваются на более мелкие задачи. Пример эпика — «создание системы рекомендаций для пользователей». 
• Фичи — это более конкретные функции, которые помогают достичь цели эпика. Например, для эпика «система рекомендаций» фичами будут задачи вроде «разработка алгоритма рекомендаций» или «интеграция с базой данных пользователей». 
• Пользовательские истории — это конкретные требования или задачи, которые описывают нужды пользователя. Например, «Как пользователь, я хочу, чтобы система показывала мне персонализированные рекомендации, а я легко находил новые товары». Каждая история должна быть небольшой, чтобы ее можно было выполнить в рамках одного спринта. 

Зависимости в бэклоге

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

Как приоритизировать задачи в бэклоге

Любые задачи можно разделить на несколько категорий по важности и срочности:

• Высокий приоритет.
• Средний приоритет.
• Низкий приоритет. 

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

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

Приоритизировать задачи можно разными способами.

Один из них — MoSCoW. Расшифровывается так:

• Must have — обязательно к выполнению. Без этих задач проект или продукт не имеет смысла.
• Should have — задачи, которые желательно выполнить. Но если не будет хватать времени и ресурсов, задачами можно пожертвовать.
• Could have — задачи, которые можно сделать. Но в случае, если останется время после Must и Should.
• Won’t have — задачи, которые можно не делать. Они никак не влияют на текущий продукт или спринт.

Вот пример, как можно приоритизировать задачи при разработке интернет-магазина:

Другой метод — RICE. Он учитывает четыре фактора:

• reach (охват); 
• impact (влияние); 
• confidence (уверенность); 
• effort (усилия). 

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

Есть и другие способы приоритизации:

• оценка задач по их ценности и трудозатратам;
• матрица Эйзенхауэра;
• WSJF и др.

И у всех способов суть одинаковая — распределить задачи по важности.

Совет. Когда расставите приоритеты, определитесь, какие задачи войдут в ближайший спринт, а какие будут отложены на потом. Здесь важно учитывать не только приоритеты, но и зависимости между задачами, риски, ресурсы команды. Например, если есть две задачи с высоким приоритетом, но одна из них блокирует другую, то сначала нужно сделать блокирующую задачу.

Как проверять актуальность бэклога

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

Ревизия — это проверка актуальности задач и их приоритетов. Задачи, которые больше не имеют значения для проекта или устарели, нужно удалить. Также можно добавить новые задачи, которые возникли в ходе изменений. Например, из-за откликов пользователей или изменений на рынке. При этом важно пересмотреть приоритеты задач. Ведь те, что были отложены, могут стать более важными.

Допустим, компания создала мобильное приложение и после первого релиза получила отзывы пользователей, что авторизация не работает должным образом. Поэтому во время ревизии бэклога задача «проверить и улучшить процесс авторизации» становится приоритетной. А задача «улучшить UI личного кабинета» становится второстепенной.

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

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

Например, при разработке веб-сайта на груминге команда поймет, что задача «создать форму регистрации» слишком общая и нуждается в деталях. Задача может быть разбита на несколько более мелких задач:

1. разработать макет формы;
2. добавить поля для ввода данных;
3. реализовать валидацию данных и т. д. 

Такое дробление задачи поможет точнее оценить трудозатраты и спланировать спринт.

что такое груминг

Что в итоге

• Бэклог — инструмент, который помогает команде фокусироваться на важных и срочных задачах. Он помогает расставить приоритеты и избежать бесполезной работы.
• Бэклог состоит из функций продукта, ошибок и багов, исследовательских задач и задач по тестированию и программированию.
• Для создания бэклога используют Product Roadmap, User Stories и Customer Journey Map. А для организации задач в бэклоге — эпики, фичи и пользовательские истории.
• Для приоритизации задач можно использовать методы: MoSCoW, RICE, оценки задач по ценности и трудозатратам, матрицы Эйзенхауэра, WSJF и других методов.
• Чтобы бэклог не терял актуальность, нужно проводить ревизии и груминг.

И да: подписывайтесь на телеграм-канал Awake Journal, чтобы не пропускать новые экспертные материалы про маркетинг, управление проектами и продуктами, разработку, а также дизайн 💪