Приоритизация product backlog — это договорённость «что делаем первым и почему», где бизнес-аналитик помогает Product Owner связать фичи с деньгами и рисками: можно сократить хаос за 2–4 недели, но ключевой риск — превращение бэклога в список желаний без метрик и критериев готовности.

Hook: почему именно бизнес-аналитик должен лезть в приоритизацию (и да, PO не обидится)

Боитесь потратить квартал команды на «красивые улучшения», а потом выяснить, что воронка продаж всё равно течёт? Это нормальная боль. В компаниях с живым продуктом фичей всегда больше, чем времени, а «самая важная» обычно кричит громче всех — особенно если у неё есть должность и доступ к CEO.

Роль Product Owner — решать, что в итоге попадёт в спринт/релиз. Роль бизнес-аналитика — сделать так, чтобы это решение было не интуицией и политикой, а нормальной системой: данные, зависимости, риски, критерии успеха, понятные всем. Ирония в том, что BA часто умеет это лучше всех, но стесняется: «ну PO же приоритизирует». Да. А BA помогает приоритизировать так, чтобы потом не было стыда на демо.

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

1) Сначала договоритесь о цели: «скорость», «выручка», «качество» — это разные бэклоги

Тезис: приоритизация без цели — это конкурс харизмы. Один тянет «новый функционал», другой — «техдолг», третий — «клиент X попросил».

Обоснование: в любом продукте есть минимум 3 типа работ: рост (Growth), удержание (Retention/Support), фундамент (Tech/Platform). Если не задать «вектор квартала», вы будете миксовать их в каждом спринте и не увидите эффекта ни в одном направлении.

Практический вывод: BA инициирует короткий alignment с PO: 1 страница, где указаны North Star/OKR и 3–5 метрик, которые реально двигаем.

Подводный камень: цель формулируют как «улучшить UX» или «повысить качество». Это не цель, это лозунг на кружке.

• Пример целей: +5% конверсия в оплату, -20% обращений в поддержку по теме X, -30% время ответа API, +10% активация в первую неделю.
• Что делает BA: привязывает фичи к метрикам и фиксирует допущения (assumptions).

2) Приведите бэклог в вид, пригодный для ранжирования: «карточки» должны быть сравнимыми

Тезис: нельзя честно сравнить фичи, если одна описана как «сделать поиск нормальным», а другая — как набор user story с оценкой и рисками.

Обоснование: приоритизация — это сравнение альтернатив. Для сравнения нужны одинаковые поля: ценность, охват, риск, усилия, зависимости, срок “пока не поздно”.

Практический вывод: BA вводит «Definition of Ready для discovery»: минимальный набор данных, без которого фича не участвует в топе.

Подводный камень: команда превращает DoR в бюрократию на 20 пунктов и парализует поток идей. Держите до 6–8 полей.

3) Выберите «движок» приоритизации: WSJF, RICE, MoSCoW — и не устраивайте религиозных войн

Тезис: фреймворк нужен не чтобы быть умным, а чтобы спорить по структуре. Любая схема лучше, чем «мне кажется».

Обоснование (коротко по сути):

• RICE (Reach, Impact, Confidence, Effort): хорош для продуктовых фич и growth, когда есть данные по охвату.
• WSJF (Cost of Delay / Job Size): хорош для платформы/техдолга и зависимостей, когда важна цена задержки.
• MoSCoW: удобен для коммуникации со стейкхолдерами, но слабо помогает ранжировать внутри Must.

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

Подводный камень: «рисование баллов» ради баллов. Если confidence всегда 100%, это не уверенность, это самоуспокоение.

4) Считайте не только ценность, но и «цену задержки» (Cost of Delay) — тут BA особенно полезен

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

Обоснование: Cost of Delay складывается из потерь выручки, роста оттока, штрафов SLA, ручного труда в операционке, репутационных рисков. BA умеет вытаскивать это из бизнеса вопросами, а не телепатией.

Практический вывод: заведите отдельное поле в бэклоге: «что будет, если сделать через 3 месяца?» и «кто за это подписывается». Магия ответственности работает.

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

5) Разведите приоритизацию на два трека: Discovery vs Delivery

Тезис: нельзя в один список складывать «идею на салфетке» и «готовую к разработке историю». Иначе в топе окажутся самые проработанные, а не самые выгодные.

Практический вывод: BA помогает PO вести два уровня:

1. Opportunity backlog (идеи/проблемы) — быстро, без детальных оценок.
2. Delivery backlog (готово к разработке) — с критериями, зависимостями, тестами, rough effort.

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

6) Как проводить сессию приоритизации: сценарий на 60–90 минут

Тезис: хорошая сессия — это не «поговорили», а «вышли с топ-10 и красными флагами».

1. Разогрев (5 мин): PO фиксирует цель периода и ограничения (команда, сроки, обязательства).
2. Снятие мусора (10 мин): BA предлагает архивировать/объединить дубли, отметить “не сейчас”.
3. Ранжирование (30–50 мин): по выбранной модели (RICE/WSJF). BA ведёт таблицу, PO принимает решения.
4. Проверка зависимостей (10 мин): техлид/архитектор подсвечивает блокеры.
5. Фиксация результата (5 мин): топ-10, что требует discovery, что ready, что выкинули.

Подводный камень: звать на приоритизацию всех. Состав минимальный: PO, BA, техлид, QA/аналитик данных (если есть). Остальным — запись/итоги.

Коммерческие факторы (да, вам это тоже полезно): скрытая цена плохой приоритизации

Если вы учитесь на BA/PO или апгрейдитесь, вот где ROI прячется не в «сертификате», а в практике. Одна ошибка приоритизации — это не «ой, неприятно». Это:

• 2–6 недель разработки, которые не сдвинули метрику.
• Рост техдолга из-за костылей «быстро в прод».
• Выгорание команды: люди чувствуют, когда их время сливают в унитаз (пусть и красиво оформленный).

На рынке за умение приоритизировать платят не за «знание Scrum», а за способность связывать фичи с P&L, рисками и реальными ограничениями команды. Это и есть та самая редкая “взрослая” компетенция.

Экспертный вердикт и инструмент: чек-лист BA для совместной приоритизации с PO

• 1) Какая метрика выигрывает в этом квартале? Если ответа нет — приоритизации нет.
• 2) У каждой фичи есть измеримый эффект и базовый уровень? “Станет лучше” не считается.
• 3) Есть оценка усилий хотя бы S/M/L? Без effort вы выбираете «что нравится», а не «что окупится».
• 4) Посчитана цена задержки? Что теряем, если отложим на 1–3 месяца.
• 5) Зависимости явно отмечены? Иначе топ-1 окажется “невозможным” в момент планирования.
• 6) Разделены discovery и delivery? Чтобы сырьё не спорило с готовыми задачами.

Частые вопросы