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

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

Что такое бэклог продукта

Бэклог продукта (Product Backlog) — это список всех задач, функциональностей, улучшений и требований к продукту, которые необходимо реализовать в ходе разработки. Понятие бэклога относится к артефактам методологии разработки Scrum. Бэклог используется для управления требованиями к продукту. Каждый элемент бэклога описывает фичи, полезные с точки зрения пользователя, и имеет свою приоритетность, оценку сложности и ожидаемую ценность для бизнеса. 

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

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

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

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

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

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

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

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

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

Из чего формируется бэклог продукта

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

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

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

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

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

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

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

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

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

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

Читайте также: «Дискавери-фаза проекта: зачем она нужна?»

Где вести бэклог

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

• веб-приложения — инструменты для работы с бэклогом есть почти во всех приложениях для управлениях проектами, таких как Jira, Azure DevOps, Asana, Microsoft Project, ScrumTrek, OmniPlan, Targetprocess и других;

• онлайн-таблицы — можно создать список задач в Яндекс.Документах или Google Sheets с колонками для описания, приоритета, статуса и сроков;

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

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

Как упорядочить бэклог

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

Оценка и приоритизация задач

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

Матрица 2×2

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

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

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

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

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

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

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

Метод INVEST

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

• Independent (независимость) — задача может быть реализована в любом случае, независимо от других задач;

• Negotiable (обсуждаемость) — задача оставляет возможность для изменения критериев и инструментов реализации;

• Valuable (ценность) — решение задачи имеет ценность для пользователей или бизнеса;

• Estimable (оцениваемость) — задача достаточно ясна, чтобы можно было оценить ее сложность и объем ресурсов;

• Small (компактность) — задача достаточно невелика, чтобы можно было выполнить ее за короткий промежуток времени или в рамках одного спринта;

• Testable (тестируемость) — результат решения задачи может быть проверен на соответствие требованиям.

Метод INVEST помогает более точно оценивать задачи и лучше организовывать работу над ними, что в конечном счете способствует успешному развитию продукта.

Метод DEEP

Схожий с предыдущим метод оценки. Он основывается на четырех критериях: 

• Detailed (детализированная) — задача может быть разделена на подзадачи, каждый ее компонент понятен и измерим;

• Estimated (оцененная) — задачу можно оценить с точки зрения времени и участия специалистов;

• Emergent (развивающаяся) — задача может быть изменена по мере реализации продукта;

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

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

Метод RICE

Метод RICE — фреймворк для приоритизации задач в бэклоге. Акроним RICE складывается из четырех критериев:

• Reach (охват) — оценка того, скольких пользователей или клиентов затронет решение задачи. Чем их больше, тем выше оценка охвата.

• Impact (воздействие) — оценка влияния задачи на бизнес-процессы или пользователей. Чем сильнее и положительнее, тем лучше.

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

• Effort (усилия) — оценка усилий, необходимых для выполнения задачи. Чем меньше усилий требуется, тем выше оценка.

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

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

Метод ROI

Метод ROI (Return On Investment) оценивает задачи с точки зрения возврата инвестиций. Этот метод помогает определить, какие фичи принесут наибольшую отдачу по сравнению с финансовыми затратами. Оценка задач по ROI имеет смысл, когда продукт уже запущен и приносит прибыль, но требует доработок или функциональных улучшений. И при условии, что вы можете достаточно реалистично прогнозировать финансовый эффект от внедрения тех или иных фич. Тогда остается разделить прогнозируемую прибыль на стоимость внедрения. Результат поможет понять, насколько вам выгодно браться за реализацию.

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

Декомпозиция задач

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

Допустим, у нас есть задача «Создать страницу регистрации пользователя». Ее следует разбить более мелкие подзадачи:

1. «Изучить требования к странице регистрации».

2. «Создать макет страницы регистрации».

3. «Разработать форму для ввода данных пользователя».

4. «Добавить валидацию данных».

5. «Создать кнопку “Регистрация” и обработать действие при нажатии».

6. «Связать форму регистрации с базой данных».

7. «Разработать страницу подтверждения успешной регистрации».

8. «Протестировать функционал страницы регистрации».

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

Планирование спринтов

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

Ошибки в управлении бэклогом

Итак, мы разобрались с тем, как работать с бэклогом. Осталось только предостеречь вас от типичных ошибок:

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

• Перегруженность — если бэклог спринта содержит слишком много задач, команда может допускать много ошибок, а потом исправлять в горящем режиме.

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

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

• Слабая связь с продуктом — если не обновлять бэклог достаточно часто, не расставлять статусы и не удалять неактуальные задачи, со временем он перестанет быть информативным. 

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

В заключение

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