Как вести беклог продукта: правила и шаблон

Что такое беклог и зачем он нужен

Беклог — это не свалка идей, это упорядоченный список того, что команда может взять в работу. Ключевое слово «упорядоченный»: если ты не можешь сказать что важнее, A или B, у тебя нет беклога, у тебя есть Trello-помойка.

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

Зачем продакту вкладываться в беклог: команда видит куда идём, стейкхолдеры видят что внутри, новые задачи попадают в сравнение с существующими, а не «давай сделаем срочно».

Симптомы плохого беклога:

• больше 200 задач, и в них нельзя ориентироваться;
• задачи лежат без обновления больше полугода;
• одинаковая идея описана в трёх разных карточках;
• AC сводятся к «фича работает»;
• спринт начинается с обсуждения «а что вообще берём».

Если хотя бы три симптома — пора чистить.

Структура беклога: 3 уровня

Самая рабочая структура — три уровня.

Уровень 1: цели квартала. Не задачи, а исходы. «Поднять retention D7 с 22% до 28%». Не больше 3–5 целей на команду.

Уровень 2: инициативы (epics). Большие куски работы, которые двигают цели. Каждая инициатива привязана к одной цели. «Переделать онбординг», «Запустить пуши», «Добавить рекомендации».

Уровень 3: задачи (tickets). Конкретные карточки разработки. Каждая привязана к инициативе.

Без этого расслоения беклог становится плоским списком из 300 задач, и непонятно зачем они нужны. С расслоением сразу видно: эта инициатива двигает цель X, в ней такие-то задачи, на следующий спринт берём первые три.

В Jira/Linear/Notion это делается через эпики и метки. Без инструмента — три страницы в Notion с ссылками между ними.

Ориентир по объёму:

• 3–5 целей на квартал;
• 8–15 инициатив (часть на квартал, часть на следующий);
• 50–100 проработанных задач сверху, дальше — заметки;
• 30–50 идей в отдельном «Idea backlog» без приоритетов.

Шаблон карточки задачи

Карточка должна отвечать на вопрос: что делаем, для кого, как поймём что готово, и что ломается если не сделаем.

Название: короткая фраза в формате «что делаем»

Контекст:
- Какая проблема
- Каких пользователей касается
- Какие данные подтверждают (метрика, отзыв, эксперимент)

Что делаем:
- Описание решения
- Скриншоты/мокапы

Acceptance criteria:
- Условие 1 выполнено
- Условие 2 выполнено
- Условие 3 выполнено

Метрика успеха:
- Что измеряем после релиза
- Какое целевое значение

Не делаем (out of scope):
- Что не входит в этот тикет

Зависимости:
- От кого ждём
- Кому отдаём дальше

Что пропускают чаще всего: метрику успеха и out of scope. Без метрики ты потом не поймёшь сработала фича или нет. Без out of scope разработчик доделает половину соседней фичи.

Хорошие vs плохие AC:

Плохо	Хорошо
Фича работает	При нажатии «Сохранить» данные сохраняются и пользователь видит подтверждение
Кнопка появляется	Кнопка «Купить» отображается на странице товара только при наличии остатка
Email уходит	Email с подтверждением заказа уходит на адрес из профиля в течение 60 секунд

Базовое правило: AC проверяется без знания контекста, по факту наличия или отсутствия события.

Приоритизация: RICE, ICE, MoSCoW

Несколько способов приоритизировать. Все они приближённые, но любой лучше чем «по ощущению».

RICE. Score = (Reach × Impact × Confidence) / Effort.

• Reach: сколько пользователей в месяц затрагивает.
• Impact: насколько сильно меняет их поведение (1 — чуть, 3 — сильно).
• Confidence: насколько уверены в оценках (50% / 80% / 100%).
• Effort: человеко-недели.

Если фича касается 10000 человек, влияет умеренно (2), уверены на 80%, 4 недели работы — score = 10000 × 2 × 0.8 / 4 = 4000.

ICE. То же самое, без Reach. Подходит когда reach сложно оценить.

MoSCoW. Must / Should / Could / Won't. Хорошо для фиксации скоупа фичи или релиза, не для общего беклога.

Главная ошибка с RICE — фейк-точность. Не делай оценки до второго знака после запятой, score говорит о порядке, не о точном значении. Если у двух задач RICE 2000 и 2200 — они равны, выбираешь по другим соображениям.

Сравнение методов:

Метод	Когда подходит	Минус
RICE	Большой беклог, продуктовые фичи	Иллюзия точности
ICE	Ранний продукт, мало данных	Reach игнорируется
MoSCoW	Скоуп релиза или фичи	Не сортирует внутри Must
Kano	Понять wow-фичи vs базовые	Сложно собрать данные
WSJF	SAFe-команды, большие зависимости	Тяжёлая обвязка

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

Груминг: ритуал, без которого беклог гниёт

Груминг (он же refinement) — еженедельная встреча на 30–60 минут, где команда смотрит верх беклога и приводит карточки в порядок.

Что происходит:

• Продакт показывает 5–10 верхних задач.
• Команда задаёт вопросы.
• Продакт уточняет описания, AC, метрики.
• Команда ставит грубые оценки (S/M/L или человеко-дни).
• То что не понятно — отправляется на доработку, не в спринт.

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

Раз в квартал делаешь «большую уборку»: всё, что лежит в беклоге больше 6 месяцев и не приоритизировано, удаляешь. Если задача важна — она вернётся. Если не важна — освободил место.

Чек-лист груминга:

• задача привязана к инициативе и цели;
• контекст и метрика прописаны;
• AC дискретные и проверяемые;
• оценка размера есть (S/M/L или дни);
• зависимости перечислены;
• out of scope зафиксирован.

Если карточка не проходит чек-лист — она не идёт в планирование, а возвращается в работу к продакту.

Что не должно быть в беклоге

Несколько типов записей, которые засоряют беклог.

• «Подумать про X». Это не задача, это идея. Идеи в отдельный список «Idea backlog».
• Баги без приоритета. Баги ведутся отдельно, иначе они забивают пользовательские задачи.
• Задачи технического долга без обоснования. Долг — это нормально, но в карточке надо объяснить какая боль уйдёт после рефакторинга.
• Чужие задачи. Если задача про работу маркетинга или продаж — она в их беклоге, не в твоём.

Ещё антипаттерны:

• задачи, в которых описано «как сделать», но нет «зачем»;
• задачи, которые год не двигались, но никто не решается их закрыть;
• задачи с фразой «пока не понятно, что делать» — место таким в идеях;
• задачи-зомби, которые приходят с прошлой стратегии и не пересмотрены.

Как обсуждать беклог со стейкхолдерами

С маркетингом, продажами и поддержкой беклог обсуждается отдельно от инженерного груминга. Их интересует не «как мы это сделаем», а «когда и зачем».

Шаблон ежемесячного апдейта:

1. Что выпустили в прошлом месяце и какой эффект.
2. Что в работе сейчас и сроки.
3. Что в next-up (следующие 1–2 месяца).
4. Что точно не делаем в этом квартале и почему.

Главный приём — показать, что ничего не «забыто». Если запрос отклонён, у него есть письменное обоснование. Это сильно снижает количество «давайте срочно» через личку.

Антипаттерн: пускать стейкхолдеров напрямую заводить тикеты в инженерный беклог. Через две недели у тебя 50 запросов без приоритета, а команда не понимает, что важно. Лучше — отдельная форма запроса в Notion, продакт сам разбирает раз в неделю.

Частые ошибки

• Беклог как helpdesk. Каждый запрос от стейкхолдера сразу в беклог без приоритета — через месяц 200 задач.
• Нет связи задача → инициатива → цель. Команда не понимает зачем делает.
• Acceptance criteria формальные. «Фича работает» — это не AC, это пожелание.
• Приоритизация по громкости стейкхолдера. Кто сильнее давит, того задача наверху. Это не приоритизация.
• Не делать груминг. Беклог гниёт за 2–3 недели без обновления.
• Хранить всё. Задача 2 года в беклоге — почти всегда удаляется без последствий.
• Делать RICE с точностью до второго знака. Это иллюзия объективности.
• Забывать ставить метрику успеха. После релиза не получится сказать, сработало или нет.

Связанные темы

• Как писать user story
• Acceptance criteria: что писать
• Как поставить цели на квартал продукту
• Как оценить эффект фичи

FAQ

Какой инструмент лучше для беклога?

Тот, в котором уже работает команда разработки. Jira, Linear, Notion, YouTrack — разница невелика, важнее ритуал.

Сколько задач должно быть в беклоге?

Верхние 20–30 — детально проработанные. Дальше — крупные карточки и идеи. Если детально проработанных больше 50, ты тратишь время впустую.

Кто пишет карточки — продакт или команда?

Первичное описание — продакт. Технические детали и подзадачи — команда. AC обсуждаются вместе.

Как часто пересматривать приоритеты?

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

Что делать с задачами от CEO?

Обсуждать в едином потоке с остальными. RICE/ICE считается одинаково для всех. Если CEO настаивает — это сигнал, что цели команды и компании разошлись, нужен разговор.

Должны ли баги быть в общем беклоге?

Лучше — в отдельной очереди с собственными SLA по тяжести. В общем беклоге баги забивают продуктовые задачи. Раз в спринт продакт принимает решение, какой объём багфиксов брать.

Как поступать с техническим долгом?

Закладывать 15–25% спринта на тех. долг. Каждая карточка долга описывается через боль: «без рефакторинга мы тратим N часов в неделю на ручные правки» или «без рефакторинга риск инцидента в Y».

Стоит ли показывать беклог пользователям?

В B2B и dev-tools — частично да, через публичный roadmap (Trello-публичный, Canny). В B2C обычно нет, чтобы не плодить ожиданий и не подсказывать конкурентам.

---

Тренируйте продуктовые кейсы — откройте Карьерник с 2500+ вопросами для собеса.