Модуль 8. Управление бэклогом и согласования
Картина целиком: что такое управляемый бэклог
Бэклог — единый, приоритизированный список работ (эпики → фичи → истории/таски), связанный с целями из BRD, требованиями из SRS и NFR.
Задача BA: превратить потребности в формализованные элементы, обеспечить трассируемость «цель → требование → работа → тест → эффект», наладить ритмы согласований и изменений.
Зоны ответственности:
- PO/Заказчик: бизнес-приоритет, «что войдёт в релиз».
- BA: формулировки, критерии готовности/приёмки, взаимосвязи, риски.
- PM/Delivery: план релизов, зависимости, ресурсы.
- Архитектор/Безопасность/Данные: ограничения и «гейт» согласований.
Структура бэклога и типы элементов
- Epic (недели–квартал): результат/ценность, метрики, допуски.
- Feature (1–3 спринта): законченная функциональность.
- Story (до одного спринта): «Как [роль], хочу [действие], чтобы [ценность]» + AC (Given/When/Then) + NFR.
- Enabler/Tech task/Data task: миграции, витрины, индексы, RLS, DQ.
- Defect/Incident: регресс, SLA/DQ-срыв.
- Change Request (CR): изменение согласованных требований/методологии.
Переходы статусов (рекомендуемый поток): New → Triaged → In Analysis (BA) → Ready → In Progress → Blocked/On Hold → In Review (UAT) → Done → Released.
Приоритизация: WSJF и MoSCoW на практике
WSJF (Weighted Shortest Job First)
Формула:
WSJF = (Business Value + Time Criticality + Risk Reduction / Opportunity Enablement) / Job Size
Шкала 1–8/13. Job Size — относительная трудоёмкость (S=3, M=5, L=8, XL=13).
Пример (эпики BI/DWH):
|
Epic |
BV |
TC |
RR/OE |
Σ |
Job Size |
WSJF |
|---|---|---|---|---|---|---|
|
RLS-доступы по регионам |
9 |
5 |
9 |
23 |
5 |
4.6 |
|
DQ-дашборд и алерты |
7 |
7 |
8 |
22 |
8 |
2.75 |
|
Признак промо (маппинги) |
8 |
8 |
6 |
22 |
8 |
2.75 |
|
Витрина GM (месячная) |
8 |
6 |
5 |
19 |
13 |
1.46 |
→ Порядок: RLS → DQ/Promo (параллельно разным командам) → GM-витрина.
Советы:
- Баллы ставим относительно, быстро (dot-voting, план-покер).
- Пересматриваем при появлении новой информации (издержки задержки, рег. требования).
MoSCoW
- Must — без этого релиз не имеет смысла.
- Should — важно, но может подождать.
- Could — приятно иметь.
-
Won’t (now) — осознанно вне релиза.
Для каждого Must есть AC/NFR, владелец и тест.
Roadmap: как делать план без «обещаний на год вперёд»
Виды дорожных карт:
- Now/Next/Later — простая коммуникация с бизнесом.
- Квартальная — эпики→вехи, окна интеграций, blackout-периоды (фин. закрытия).
- Release Train (если несколько команд): общие вехи, межкомандные зависимости.
Состав дорожной карты:
- Цели/темы (OKR/BRD).
- Эпики и ожидаемый outcome (метрики эффекта).
- Зависимости (системы, лицензии, доступы, данные).
- Capacity (скорость/ресурс) и риски.
- Маркеры «обязательных согласований» (архитектура, безопасность, данные).
Definition of Ready / Definition of Done
DoR (история готова в разработку, чек-лист)
- Есть формулировка Как/Хочу/Чтобы.
- AC (Given/When/Then) + негативные сценарии.
- NFR (отклик/свежесть/доступы) применимы.
- Ссылки на SRS/BRD (правила расчёта, STT, RLS).
- Макет/пример (если UI/BI).
- Оценка (Story Points/Job Size).
- Риски/зависимости/данные известны, согласованы владельцы.
- Тестовые данные/эталоны обозначены.
- «Гейт» архитектуры/безопасности пройден, если требуется.
DoD (история «сдана», чек-лист)
- Пройдено UAT по всем AC (протокол).
- NFR выполнены (p95, Freshness, RLS-тесты).
- Логи/алерты/DQ-правила на месте.
- Документация: паспорт дашборда, словарь метрик (версия), release notes.
- Обучающие заметки/линки опубликованы.
- Мониторинг пост-релиза настроен (маяк-метрики).
DoR/DoD для DWH-тасков (пример дополнений):
— партиционирование/индексы определены; — SCD-тип зафиксирован; — объём/кардинальности оценены; — тест производительности на эталонном объёме; — lineage и владельцы данных указаны.
Change Management и версионирование требований
Классы изменений (семанвер для требований)
- MAJOR — меняет поведение/методологию (влияет на тренды/суммы). Требует согласования SteerCo, миграции, баннера «изменена методика».
- MINOR — добавляет совместимые возможности (новый фильтр/поля).
- PATCH — исправляет дефект без изменения смысла.
Артефакты:
- CR-карточка: причина, обоснование ценности/рисков, влияние (scope/срок/стоимость/качество), план миграции, обратная совместимость/feature-flag, владелец.
- Change-log в SRS/словаре метрик + Release Notes.
Процесс CR
New → Impact Analysis (BA/Арх/Безопасность/Данные) → Decision (PO/SteerCo) → Implement (feature flag/ветка) → Communicate (баннер/ньюслеттер/FAQ) → Close (замер эффекта).
Согласования (governance) и эскалации
Гейты согласований (типовые):
- Архитектура: соответствие стандартам, производительность, DR.
- Безопасность/ПДн: RLS, маскирование, SSO/MFA, выгрузки.
- Data Governance: владельцы, DQ-правила, контракты данных.
- Лицензии/Закупки: наличие лимитов, TCO.
- Юридические/Регуляторные (если нужно).
Куда эскалировать и когда:
- Blocked > 2 раб. дней или критичная зависимость → PM/PO.
- Архитектурный конфликт → Арх-борд.
- Безопасность/ПДн → DPO/SecOps.
-
Бюджет/Лицензии → Финансы/IT Ops.
Шаблон эскалации: факт → влияние → срок «крайней даты» → варианты решений → рекомендация.
План релиза: как связать приоритеты, зависимости и мощность
Шаги:
- Формируем инкременты (эпики → фичи → истории), отмечаем Must/WSJF-ранг.
- Считаем capacity (скорость команд × число спринтов; окна интеграций, отпуска).
- Развешиваем зависимости (данные/интеграции/согласования).
- Фиксируем критерии релиза (DoD at release: p95, Freshness, RLS, обучение).
- Пишем план отката/feature flags.
- Готовим коммуникации: кто, когда, что увидит; паспорт дашбордов обновлён.
Пример скелета плана (квартал):
- R1 (нед 1–4): RLS (Must), DQ-дашборд (Should).
- R2 (нед 5–8): Промо-признак (Must), GM-витрина (Should).
- R3 (нед 9–12): Exec-панель (Could), перф-агрегаты (Must, если p95>5с).
Метрики управления потоком (flow-метрики)
- Lead Time / Cycle Time, Throughput/Velocity.
- Predictability (доля «в срок», p85 цикла).
- Flow Efficiency (время работы / общее время).
- WIP Aging (старение незавершёнки).
- Backlog Health: % элементов с AC/NFR, с оценкой, дубликаты, «age of item», churn (% перетасованных задач за спринт).
- Spillover (вынос в следующий релиз) и его причины.
BA использует их на ретро и SteerCo для корректировок roadmap/вместимости.
Риски и как их снимать
|
Риск |
Симптом |
Меры |
|---|---|---|
|
«Хочу всё и сразу» (scope creep) |
Постоянные «ещё чуть-чуть» |
MoSCoW+WSJF, CR-процесс, чёткие Won’t |
|
Неготовые истории идут в работу |
Блоки/переделки |
Жёсткий DoR, трёхступенчатое уточнение (triage → analysis → ready) |
|
Конфликты согласований |
«Арх говорит одно, безопасность другое» |
Гейты заранее, единый протокол решений, владелец эскалации |
|
Паралич из-за зависимостей |
Ждём доступов/источников |
План параллельности, мок-данные, feature flags, вариант B |
|
Разнобой методологии |
«GM% у всех разный» |
Версионирование словаря, change-log, баннеры, паспорт дашборда |
|
Нереалистичный roadmap |
Переносы, «спилловер» |
Планировать от capacity и зависимости, а не от желаний; буфер на интеграции/согласования |
|
«Забытые» NFR |
Красивый UI, но 12 сек отклик |
NFR в DoR/DoD и в AC, перф-тесты до UAT |
Теория — «ровно сколько нужно»
- WSJF минимизирует «стоимость ожидания» (Cost of Delay). Полезно пересматривать ежемесячно.
- Классы обслуживания (Kanban): Expedite (инциденты/SLA), Fixed Date (регуляторика/фин. закрытие), Standard, Intangible (перф/рефакторинг).
- Базелайн требований: версию SRS/словара метрик «замораживаем» на релиз; изменения — только через CR.
- Принцип малых партий: дробите фичи до «демонстрируемых» инкрементов → выше предсказуемость.
Вопрос–ответ (FAQ)
Q: WSJF и MoSCoW вместе не конфликтуют?
A: Нет. MoSCoW задаёт «грубую сетку», WSJF ранжирует внутри каждого класса, особенно Must/Should.
Q: Кто финально решает приоритет?
A: PO/SteerCo. BA готовит обоснования (WSJF, связи с целями, риски/зависимости) и протокол.
Q: Как защитить перенос фичи?
A: Показать ограничения capacity/зависимостей, риски для Must-элементов и альтернативы (feature flag/MVP-срез).
Q: Что делать с «вечными исследованиями»?
A: Timebox (Spike) на 1–2 спринта, конкретный вопрос и критерий выхода (ответ/прототип/решение «не делаем»).
Q: Как держать согласования под контролем?
A: Единый календарь гейтов, чек-листы перед бордом, owner у каждого согласования, SLA ответа (напр., 3 раб. дня), эскалация по молчанию.
Практика (что сдать по итогу модуля)
A. План релиза (1–2 страницы)
- Цели релиза (метрики эффекта), состав (эпики/фичи), Must/Should/Could, зависимости, capacity, риски, критерии релиза (DoD at release), план отката/feature-flags, коммуникации.
B. DoR/DoD вашей команды (карточки)
- Общие пункты + специфичные для BI/DWH (RLS, DQ, Freshness, перф-бюджет, паспорт дашборда).
C. Матрица приоритизации (WSJF + MoSCoW)
- Таблица по 6–10 эпикам/фичам, результаты ранжирования, комментарии по компромиссам.
D. Шаблон CR + журнал версий
- Форма изменения, примеры MAJOR/MINOR/PATCH, change-log в SRS/словаре метрик.
Мини-шаблоны (скопируйте в Confluence/Jira)
Карточка Epic (вкратце):
Цель/эффект · KPI · Out of scope · Зависимости · Риски · DoR/DoD · Ссылки (BRD/SRS/NFR) · WSJF · MoSCoW.
Шаблон CR:
Описание → Причина/ценность → Влияние (scope/срок/стоимость/качество) → Совм-ть/feature-flag → План миграции → Риски → Владелец → Решение/дата → Release notes.
Passport дашборда:
Назначение · Аудитория · KPI · Версия методологии · Дата свежести · Источники · Ограничения · Владелец · Контакты поддержки.
Чек-листы готовности
Бэклог здоров:
- 90% элементов приоритизированы, у 80% есть AC/NFR, у 100% Must — оценка.
- Дубли/«сироты» отсутствуют; трассируемость к BRD/SRS есть.
- Регулярные ритмы: triage (еженед.), refinement (еженед.), SteerCo (ежемес.).
Релиз готов:
- Capacity ≥ объёма Must; зависимости закрыты/прописаны.
- План отката/flags есть; коммуникации и обучение готовы.
- DoD at release: p95, Freshness, RLS, паспорта/релиз-ноты, мониторинг post-релиза.
Вы превращаете разрозненные запросы в очередь ценности, которая проходит через понятные гейты согласований, держится в рамках capacity, меняется только через CR, а результат релиза измерим по метрикам эффекта. Такой бэклог — инструмент управления, а не список желаний. Если нужно, могу упаковать ваш реальный бэклог (Jira/YouTrack) в полный комплект: WSJF-оценки, DoR/DoD, план релиза и шаблоны согласований.
