Что такое бэклог продукта и как он составляется?

Product Backlog: Определение, структура и составление

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

Определение

Product Backlog — это упорядоченный по приоритету список:

• User Stories
• Features (функции)
• Improvements (улучшения)
• Technical Debt (технические долги)
• Bugs (ошибки)
• Research/Spikes (исследования)

Каждый item содержит:

• Описание что нужно сделать
• Acceptance Criteria (критерии приемки)
• Estimate (оценка сложности или времени)
• Priority (приоритет)
• Business Value (какую ценность приносит)

Структура типичного Product Backlog item'а

ID: PBI-42
Title: Как клиент, я хочу сохранять избранные товары в список wishlist

Description:
Позволить пользователям сохранять товары, которые они хотят купить позже.
Это повышает engagement и позволяет отправлять reminder'ы по сохранённым товарам.

Acceptance Criteria:
- Когда пользователь нажимает на иконку сердца, товар добавляется в wishlist
- Иконка сердца становится красной/заполненной
- На странице профиля есть раздел "My Wishlist"
- Пользователь может удалить товар из wishlist
- Wishlist синхронизируется между браузером и мобильным приложением

Business Value: 8/10 (средне-высокая)
- Увеличивает repeat visits на 15% (по анализу конкурентов)
- Даёт нам данные о потребительских интересах

Estimate: 8 Story Points (примерно 3-4 дня работы)

Priority: High (текущий спринт)

Dependencies:
- Должна быть готова User Auth система
- API для wishlist должен быть готов

Notes:
- Дизайн уже готов в Figma
- Нужно A/B тестировать положение иконки wishlist

Кто составляет Product Backlog

В классическом Agile:

• Product Owner (PO) — основной ответственный
• Business Analyst — помогает выявлять требования
• Stakeholders — предоставляют идеи
• Team — дают feedback по feasibility

В реальности:

• Small Startup: часто один человек (PO + BA)
• Mid Company: PO создаёт, BA детализирует, Team оценивает
• Enterprise: комплекс процессов с несколькими уровнями backlogs (Epic Backlog, Feature Backlog, Team Backlog)

Как составлять Product Backlog

Шаг 1: Сбор идей

Идеи приходят из разных источников:

• Customer interviews — клиенты жалуются на боли
• Market research — что делают конкуренты
• User behavior analytics — где users теряются в интерфейсе
• Business goals — что нужно компании для роста
• Technical debt — что нужно улучшить в коде
• Support tickets — что пользователи просят

Примеры: "Клиентам трудно найти нужный товар" → Feature: улучшить поиск "Наш сайт медленный" → Technical work: оптимизировать database "Конкуренты имеют wishlist" → Feature: wishlist

Шаг 2: Формулирование как User Story

Лучший формат:

Как [роль], я хочу [что сделать], так чтобы [какая ценность]

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

Шаг 3: Определение Acceptance Criteria

Что означает "готово":

✓ Когда пользователь нажимает кнопку, список обновляется мгновенно
✓ Каждой фильтр сохраняется в URL, чтобы можно поделиться ссылкой
✓ На мобильном устройстве фильтры доступны через меню
✓ Нет фильтров, которые ничего не возвращают (хотя бы 1 товар всегда)

Шаг 4: Приоритизация

По разным критериям:

• Business Value — насколько важно для компании (1-10 или High/Medium/Low)
• Urgency — насколько срочно (customer просит, конкурент реализовал)
• Dependencies — есть ли зависимости от других features
• Risk — какой риск, если не сделаем
• Effort — сколько работы нужно

Формула часто: Priority = (Business Value × Urgency) / Effort

Пример приоритизации:

Шаг 5: Оценка (Estimation)

Варианты оценок:

• T-shirt sizes: XS, S, M, L, XL (когда неясна масштабность)
• Story Points: 1, 2, 3, 5, 8, 13, 21 (Fibonacci — для относительной сложности)
• Days/Hours: 0.5d, 1d, 3d, 1w (более конкретно, но менее гибко)

Примеры:

• Wishlist: 8 points (3-4 дня одного разработчика)
• Dark Mode: 5 points (2 дня)
• Advanced Search: 13 points (неделя, потому что много логики)

Структура Product Backlog в трудных проектах

В больших проектах бэклог организуют иерархически:

Epics (большие инициативы на квартал или год)
  ├─ Epic 1: Improve Search
  │   ├─ Feature 1.1: Advanced Filters
  │   │   ├─ PBI: Filter by price
  │   │   ├─ PBI: Filter by brand
  │   │   └─ PBI: Save search preferences
  │   ├─ Feature 1.2: Search Analytics
  │   └─ Feature 1.3: AI Recommendations
  ├─ Epic 2: Mobile App
  └─ Epic 3: Payment Gateway Upgrade

Что входит в Product Backlog

Features (новая функциональность)

• User-facing features (wishlist, filters)
• Internal features (admin panel, reporting)

Improvements (улучшения)

• Существующие feature становятся лучше
• Performance улучшения
• UX улучшения

Technical Debt (технический долг)

• Рефакторинг кода
• Обновление зависимостей
• Улучшение архитектуры
• Покрытие тестами

Bugs (ошибки)

• Image upload не работает
• Скидки считаются неправильно
• Email notification не отправляется

Research/Spikes (исследования)

• Исследовать, как реализовать AI recommendations
• Провести A/B test дизайна кнопки
• Analyse competitor features

Правила для хорошего Product Backlog

1. INVEST критерий

• I — Independent (независимый от других)
• N — Negotiable (можно обсудить детали)
• V — Valuable (приносит ценность)
• E — Estimable (можно оценить)
• S — Small (маленький, можно сделать за спринт)
• T — Testable (можно протестировать)

2. Top items детализированы, нижние — нет

Top (Next Sprint):
- PBI-42: Wishlist (8 points) — детализирован, ready to code

Middle (Current quarter):
- PBI-50: Dark Mode (5 points) — средне детализирован

Bottom (Future):
- Epic: AI Recommendations — только идея, много вопросов

3. Регулярное обновление

• Еженедельно добавляются новые идеи
• Приоритеты меняются в зависимости от рынка
• Готовые items удаляются
• Пришедшие в backlog items rethink-уются

Антипаттерны Product Backlog

❌ Backlog из сотен items без приоритизации ❌ Items написаны как "Улучшить систему", не clear acceptance criteria ❌ Items никогда не обновляются ❌ Backlog составляет только один человек без вовлечения team ❌ Старые items на 5 месяцев не трогали, но они всё ещё там

Product Backlog для разных методологий

Agile/Scrum:

• Items в sprint планируются из top backlog
• Каждый спринт 2 недели, backlog переоценивается

Kanban:

• Backlog вытягивается в работу когда есть capacity
• Нет спринтов, continuous flow

Waterfall (если вообще используется):

• Backlog — требования документ
• Не меняется часто (frozen на проект)

Product Backlog — живое сердце любого agile проекта, которое отражает видение продукта и стратегию развития компании.