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

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

Что такое бэклог

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

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

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

Зачем нужен бэклог продукта

• Момент приоритизации. Такой перечень задач помогает команде определить, над какими задачами стоит работать в первую очередь, а какие можно отложить на потом. Подход позволяет сосредоточиться на наиболее ценных изменениях, которые принесут максимальную пользу — и продукту и его пользователям.
• Момент прозрачности. Поскольку список задач является единым централизованным источником информации о планируемых задачах, все участники команды всегда в курсе текущего состояния (а не только сами разработчики). Все соответствует подходам Agile.
• Момент адаптивности. В отличие от жесткого плана, бэклог — живой документ, который можно гибко корректировать в зависимости от изменяющихся требований или новых идей. Команде удастся быстро реагировать на изменения, либо оперативнее адаптироваться к новым условиям.
• Момент фокусировки. Перечень задач помогает команде оставаться сфокусированной на наиболее важных задачах, а не распыляться на второстепенные цели.

Читайте также:

ТОП-8 самых популярных языков программирования: зачем он нужен и как его выбрать

Что входит в бэклог продукта

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

Разные User Stories

Описания сценариев с точки зрения конечного пользователя.

Исправление конкретных ошибок (Bug Fixes)

В список включаются задачи по устранению обнаруженных ошибок.

Технические задачи

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

Исследования, эксперименты

В этот список добавляют задачи по проведению исследований рынка, анализу поведения пользователей, A/B-тестированию или другим экспериментам, направленным на улучшение ПО.

Читайте также:

Вебмастер: кто это такой, чем занимается и за что отвечает

Примеры бэклога продукта

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

Для мобильного приложения по поиску ресторанов (агрегатов заведений)

• User Story — «Как пользователь, я хочу видеть список ближайших ресторанов со средним чеком, чтобы выбрать, где мне пообедать».
• Исправление конкретной ошибки — «Исправить ошибку, из-за которой приложение некорректно отображает карту на устройствах с Android 10».
• Техничка — «Оптимизировать загрузку изображений для уменьшения потребления трафика».

Для интернет-магазина одежды

• User Story — «Как пользователь, я хочу иметь возможность сохранять товары в избранное, чтобы купить их позже».
• Исправление конкретной ошибки — «Исправить ошибку, из-за которой не приходит подтверждение заказа на email пользователя».
• Исследование — «Провести анализ поведения пользователей на странице оформления заказа для выявления причин низкой конверсии».

Для образовательной онлайн-платформы

• User Story — «Как студент, я хочу иметь возможность отмечать пройденные уроки, чтобы отслеживать свой прогресс в курсе».
• Исправление конкретной ошибки — «Исправить проблему с воспроизведением видео на iOS устройствах при использовании Safari».
• Техническая задача — «Внедрить систему кэширования для ускорения загрузки учебных материалов».

Для фитнес-приложения

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

Для сервиса по доставке продуктов

• User Story — «Как клиент, я хочу иметь возможность оставлять заметки курьеру по доставке, чтобы уточнить детали получения заказа».
• Исправление конкретной ошибки — «Устранить проблему с некорректным отображением времени доставки в push-уведомлениях».
• Техническая задача — «Оптимизировать алгоритм распределения заказов между курьерами для сокращения времени доставки».

Для приложения по управлению личными финансами:

• User Story — «Как пользователь, я хочу получать еженедельные отчеты о моих расходах по категориям, чтобы лучше контролировать свой бюджет».
• Исправление конкретной ошибки — «Устранить проблему с некорректным отображением графиков при переключении между валютами».
• Техническая задача — «Интегрировать API нового банка — для автоматического импорта транзакций пользователей».

Как управлять бэклогом (на примере Jira)

Для эффективного управления разработчики обычно используют специализированные инструменты. У нас это Kaiten, а также Shtab, YouGile, «Битрикс24» и «Планфикс», зарубежом — Jira, Trello, Asana и другие. Все эти инструменты похожи тем, что позволяют создавать, структурировать, приоритизировать и отслеживать выполнение задач в бэклоге уже из коробки.

Рассмотрим на примере с Jira, как может выглядеть работа с таким списком:

1. Создали задачи. Члены команды создают задачи (issues). Затем описывают User Story. Уточняют ошибки. Или другие элементы бэклога.
2. Приоритизировали. Задачам присваиваются приоритеты на основе их ценности, срочности, сложности, и других критериев. Наиболее важные задачи получают высокий приоритет — они планируются к выполнению в первую очередь.
3. Оценили сложность. Команда оценивает сложность каждой задачи, используя различные подходы. Например, с помощью стори поинтов.
4. Организовали по спринтам. В рамках гибкой методологии SCRUM задачи из бэклога распределяются по спринтам — итерациям разработки продолжительностью 2-4 недели. Команда берет на себя обязательство выполнить определенный набор задач в каждом спринте.

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

Связь бэклога с Agile и SCRUM

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

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

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

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

Шаблоны для создания user stories

User stories — это короткое описание требования к продукту с точки зрения пользователя. Распространенный шаблон для написания user story:

Примеры я уже давал в первой части статьи. Здесь же обращусь к важным принципами при написании User Stories:

• Формулировка от лица пользователя.
• Краткость, максимальная ясность.
• Независимость от технических деталей реализации.
• Описание ценности для пользователя.

Приоритезация задач

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

Прежде всего, приоритет получают задачи, критически важные для достижения бизнес-целей и удовлетворения основных потребностей пользователей. Далее можно руководствоваться принципами Agile (а также — Lean-разработки). Примеры — концепция MVP, минимально жизнеспособного продукта. Другой пример — постепенное наращивание функциональности.

Полезные инструменты:

• Матрица «стоимость / ценность».
• Метод MoSCoW, который позволяет выделить важные и критически необходимые задачи для успешного завершения проекта. Согласно методу, все задачи делятся на четыре категории: Must have, Should have, Could have и Won't have.
• Регулярные приоритизационные сессии с широким кругом участников.

Примеры блогов для разных продуктов

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

• Функция отслеживания заказа в личном кабинет покупателя.
• Создание функциональности промокодов.
• Добавление системы скидок.

• Интеллектуальные рекомендации товаров на основе предыдущих покупок.
• Интеграции с разными платежными системами.
• Инструменты для анализа потребительского поведения.

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

Заключение

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

Коротко о главном

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