Модуль 20. Библиотека документов и шаблонов BA
Зачем библиотека и роль BA
Цель: превратить «разрозненные файлы» в управляемый набор артефактов, где каждый документ ведёт к решению: интервью → инсайты → требования → витрины/дашборды → UAT → релиз → пост-мортем → улучшение.
Роль BA:
- Дизайн шаблонов «ровно достаточных» (lean), без бюрократии.
- Губернанс: версии, владельцы, правила хранения, ревизии.
- Адаптация под домен: термины/метрики/регуляторика.
- Обучение и adoption: «как заполнять быстро», чек-листы, примеры.
Результат: меньше разночтений, быстрее согласования, выше качество приёмки и повторяемость успеха на проектах.
Управление библиотекой (governance)
Где хранить и как называть
Репозиторий: Confluence/Notion + Git (версии/экспорт .md/.docx).
Структура (пример):
/BA-Library /00-Standards (глоссарий, style-guide, IDs, версионирование) /10-Discovery (интервью-гайды, протоколы, stakeholder map) /20-Requirements (BRD/SRS, change request, RACI) /30-Delivery (паспорт дашборда, UAT-пакет, чек-листы) /40-Release (release notes, comms plan) /50-Operate (SLA/NFR runbooks, post-mortem, risk-register) /99-Examples (заполненные примеры)
Идентификаторы и имена:
-
Формат: DOC-<КАТ>-<КОД>-<YYYYMMDD>-vMAJOR.MINOR.PATCH.
Пример: DOC-UAT-CHK-20250819-v1.2.0. - Язык: RU интерфейс + EN термины для полей данных (см. Модуль 12).
Версионирование и статусы
- SemVer: MAJOR — меняет смысл/процесс; MINOR — совместимые улучшения; PATCH — мелкие правки.
- Статусы: Draft → Review → Approved → Deprecated.
- Release notes библиотеки: короткий лог изменений при обновлении шаблонов.
Метаданные документа (вставляйте в начало)
doc_id: DOC-UAT-CHK-20250819 title: UAT-пакет по витрине "Promo & GM%" owner: BA Practice Lead version: 1.2.0 status: Approved last_updated: 2025-08-19 linked_artifacts: [SRS-RET-014 v1.4, Glossary v2.0, DQ-Rules v1.1] confidentiality: Internal
Каталог ключевых шаблонов (10 штук, как просили)
Ниже для каждого: когда использовать, минимальный состав, антипаттерны, кусок готового шаблона.
Интервью-гайд (Interview Guide)
Когда: discovery проблем/гипотез, уточнение процессов/метрик.
Минимум: цель, портрет респондента, «скелет» вопросов, техники (5 Why, JTBD), блок данных/метрик, «next steps».
Антипаттерны: «почему так сделали?» (обвинение), слишком закрытые вопросы, отсутствие фиксации фактов.
Шаблон (фрагмент):
Интервью-гайд — проект <NAME> (версия v1.0) Цель сессии: ______________________________________ Респондент: Роль, зона ответственности, KPI, время в роли Контекст: (продукт/процесс/дашборд/метрика) Открывающие: - Расскажите, как сейчас вы решаете X? - Когда в последний раз это не сработало? JTBD: - Когда возникает потребность ____? - Что мешает выполнить работу быстрее? 5 Why по ключевой боли: 1) Почему это происходит? ... Данные/решения: - Какие данные/отчеты вы используете? - Какие решения принимаете на их основе? Завершение: резюме, проверка понимания, согласие на follow-up Следующие шаги: ____________________________________
Протокол встречи / борда (Meeting Minutes)
Когда: статусы, дизайн-сессии, борт комитет (SteerCo).
Минимум: повестка, решения (Decision Log), задачи (Action Items, владелец, срок), риски/эскалации.
Антипаттерны: «стенограмма без решений», отсутствие сроков/владельцев.
Шаблон (таблица):
|
Время |
Пункт повестки |
Решение |
Действия |
Владелец |
Срок |
|---|---|---|---|---|---|
|
10:00 |
Утверждение SRS |
Одобрено v1.4 |
Внести правки по NFR |
BA |
22.08 |
Паспорт дашборда (Dashboard Passport)
Когда: любой BI-отчёт/панель перед публикацией.
Минимум: цель, аудитория, решения, KPI/методология, источники/свежесть, NFR, RLS, владелец/поддержка, версия методики.
Антипаттерны: «красиво, но непонятно зачем», метрики без формул/единиц.
Шаблон (секции):
Название панели / версия методологии Цель: какое управленческое решение поддерживает панель Аудитория: роли/доступы (RLS) KPI и метрики: (название, формула, единицы, владелец метрики) Источники данных: таблица/частота/время готовности Свежесть (Freshness) и DQ: пороги, виджеты, реакции Фильтры/срезы: ... NFR: p95 отклика, доступность, экспорт/ограничения Владелец панели / Поддержка / Канал для инцидентов История изменений (release notes панели)
Мини-пример заполнения:
KPI: GM% = (Revenue − COGS − Logistics)/Revenue; формат 0.0%; владелец: Финконтролёр; методология v1.3.
RACI (распределение ответственности)
Когда: старт инициативы, смена команды, внешний вендор.
Минимум: work-packages и роли (R/A/C/I), определение границ.
Антипаттерны: «все консультанты», отсутствует единоличный A.
Шаблон:
|
Задача |
Product |
BA |
Data Eng |
BI Dev |
QA |
Sec |
Vendor |
|---|---|---|---|---|---|---|---|
|
SRS/Методология |
C |
R/A |
C |
C |
C |
C |
I |
|
DWH/ETL |
I |
C |
R |
I |
C |
C |
R |
|
BI-дашборды |
A |
C |
C |
R |
C |
I |
R |
|
UAT/Приёмка |
A |
C |
I |
C |
R |
I |
C |
Реестр рисков (Risk Register)
Когда: всегда; обновлять на каждом статус-митинге.
Минимум: риск, вероятность/влияние, владелец, план реагирования, статус.
Антипаттерны: без владельца и «мер по снижению».
Шаблон:
|
ID |
Риск |
P (1–5) |
I (1–5) |
RAG |
Владелец |
План |
Триггер |
Статус |
|---|---|---|---|---|---|---|---|---|
|
R-12 |
Freshness не укладывается в 07:00 |
3 |
4 |
х |
Data Lead |
Инкремент, оптимизация |
SLA провален 2 дня |
Открыт |
Change Request (CR)
Когда: изменение scope/методики/сроков/стоимости.
Минимум: описание, причина, эффект, оценка (часы/сроки/стоимость), влияние на SLA/вехи, решение.
Антипаттерны: «мелкие изменения на словах», отсутствие cut-off.
Шаблон:
CR-ID: CR-<PRJ>-<YYYYMM>-NN Запросил / Дата Описание изменения Причина/обоснование (value case) Влияние: Scope / Срок / Стоимость / SLA / Риски Оценка (вендор/команда) Решение (Approved/Rejected/Needs work) / Дата / Подписи Вступает в силу с версии: SRS vX.Y / Методология vZ.W
UAT-пакет (приёмка)
Когда: перед релизом/поставкой.
Минимум: сценарии/кейсы, эталоны, критерии прохождения, протокол дефектов, лист согласований.
Антипаттерны: «погоняли на глаз», нет эталонов/допусков.
Шаблон (структура):
- Объект приёмки (панель/витрина/процесс).
- Список Acceptance Criteria (нумерация AC-01…AC-NN).
- Тестовые наборы данных/эталоны и допуски.
- Протокол тестирования (кто/когда/статус/скриншот/SQL).
- Реестр дефектов (severity/SLA исправления).
- Итоговый акт (Pass/Fail), решения/исключения.
Release Notes (для BI/витрин)
Когда: каждая поставка/обновление методологии/данных.
Минимум: версия, дата, что изменилось (Added/Changed/Fixed), влияние на сравнимость, откат, известные проблемы.
Антипаттерны: «обновили тихо», сломали тренды.
Шаблон:
Release: BI Retail v1.6.0 — 2025-08-19 Added: Виджет OOS по KVI Changed: Формула GM% (исключили трансферы) — МЕНЯЕТ тренды с 2024-01 Fixed: RLS по региону Impact: сравн. с прошлой версией нарушена; ссылка на методологию v2.1 Rollback: tag v1.5.3 Owner: BI Lead
Post-mortem (инцидент/ретро)
Когда: SLA-срыв, метрика «упала», ошибка релиза. (Blameless)
Минимум: таймлайн, первопричина (5 Why/фишбоун), влияние (бизнес/пользователи), что узнали, действия (иммедиат/устойчивые), владельцы/сроки, проверка эффектов.
Антипаттерны: поиск виноватых, «действия без даты и владельца».
Шаблон:
Инцидент: #INC-2025-0819 — падение Freshness D-1 TL;DR: ... Таймлайн (UTC): обнаружено 07:05 → восстановлено 08:10 Влияние: 5 панелей D-1 не обновились; 3 команды — задержка решений Root Cause: ... (5 Why) Что сработало/нет: ... Действия: - Немедленно: алерт мульти-окно — Owner: SRE, до 23.08 - Устойчиво: переразбивка задач ETL — Owner: Data Eng, до 10.09 Проверка: KPI Freshness ≥99% за сентябрь — Owner: BA
Коммуникационный план к релизу (Comms Plan)
Когда: релиз «видимых» изменений или новая методология.
Минимум: аудитории, сообщения (что/зачем/когда), каналы, тайминг, «что делать, если».
Антипаттерны: «внезапные изменения», нет инструкции при сбое.
Шаблон (таблица):
|
Аудитория |
Сообщение |
Что изменится |
Когда |
Канал |
Owner |
FAQ/Инстр. |
|---|---|---|---|---|---|---|
|
Кат. менеджеры |
Обновление панели Promo & GM% |
Новая формула GM% |
D-2 |
Email+Confluence |
BA |
Ссылка |
|
Руководство |
Изменится тренд GM% с 2024-01 |
Причина и эффект |
D-1 |
Стендап |
PM |
Ссылка |
|
Поддержка |
Как реагировать на вопросы |
Шаблон ответа |
D-1 |
Slack |
Support Lead |
Ссылка |
Дополнительные быстрые шаблоны (бонус)
- Decision Log (ADR): решение / контекст / альтернативы / последствия.
- Stakeholder Map: влияние × интерес, каналы коммуникации.
- Problem Statement: кто/что/почему важно/как измерим успех.
- Value Case: гипотеза → эффект → метрики → риски → ROI.
Риски библиотеки и как их снять
|
Риск |
Симптом |
Что сделать |
|---|---|---|
|
«Бумажная бюрократия» |
Документы есть — ценности нет |
«Lean-уровни»: базовый и расширенный; максимум 1 стр. для повседневки |
|
Док-гниение |
Шаблоны устаревают |
Релиз библиотеки раз в квартал; владелец раздела; release notes |
|
Разночтения терминов |
«GM% у всех разный» |
Ссылка на глоссарий в каждом шаблоне; версия методологии в шапке |
|
Нет принятия |
Команда не заполняет |
Обучение 30 мин + примеры; авто-подстановки/макросы; «заполнить за 10 мин» |
|
Потеря контекста |
Документы разбросаны |
Единые метаданные, дерево, сквозные ID, шаблон ссылок «Связанные артефакты» |
|
Безопасность |
Утечка PII |
Политика маскирования/экспорта, уровни доступа, аудит |
Вопрос–ответ (FAQ)
Q: Сколько шаблонов реально нужно?
A: Начните с 8–10 (из этого модуля). Остальные добавляйте по мере зрелости. Главное — «ровно достаточно» для решения задачи.
Q: Как заставить команду пользоваться?
A: День «обучения+настройки», авто-заполнение (project name, owner, date), примеры «before/after», KPI adoption (доля артефактов со статусом Approved).
Q: Что хранить в Git, а что в Confluence?
A: Исходники (DDL, SQL, схемы, JSON панели) — в Git. Процесс/решения/протоколы — в Confluence. Ставьте ссылки и версии.
Q: На каком языке вести шаблоны?
A: RU-интерфейс + EN для технических полей/метрик; всегда указывайте соответствия (см. Модуль 12).
Q: Как не перегрузить UAT?
A: До 10–15 AC на поставку, эталоны заранее, чек-лист дефектов с SLA. Остальное — в регрессионный пакет релиза.
Q: Когда обновлять библиотеку?
A: Раз в квартал или после крупных инцидентов/изменений методологии; выпускайте release notes библиотеки.
Практика (сборка вашего пакета под стандарты)
A. Мини-бэклог внедрения (2 недели)
- Создать раздел /BA-Library и метаданные (шаблон YAML).
- Залить 10 шаблонов из модуля, настроить авто-подстановки (шаблоны Confluence/Google Docs).
- Добавить 3 «пример-артефакта» (заполненных) под ваш домен.
- Провести 60-мин обучающую сессию, собрать обратную связь.
- Выпустить Library v1.0.0 (release notes + владельцы разделов).
B. Acceptance для библиотеки
- Все шаблоны имеют doc_id, owner, version, status.
- Есть паспорт дашборда, UAT-пакет, CR, risk-register, post-mortem, comms plan.
- Шаблоны связаны ссылками на глоссарий/методологию.
- Есть 3 заполненных примера (retail/логистика/финансы — по вашей отрасли).
- Страница «Как пользоваться» + 10-минутное видео/скринкаст.
C. «Быстрые победы»
- Кнопки-макросы: «Создать протокол встречи», «Создать CR», «Создать UAT-пакет».
- Баннер «версия методологии» в паспорте дашборда.
- Виджет «свежесть артефактов» (дата последнего апдейта).
Чек-лист готовности (итог)
Стандарты
- Именование/ID/версионирование (SemVer) заданы и видны.
- RU/EN терминология и ссылки на глоссарий.
Артефакты
- 10 ключевых шаблонов размещены и описаны.
- Примеры заполнения прилагаются.
Процесс
- Владелец библиотеки назначен, есть календарь ревизий.
- Release notes библиотеки опубликованы.
- Команда обучена; adoption > 80% через месяц.
Вы оформляете библиотеку BA-артефактов — с ясными метаданными, версиями, примерами и «тонким» набором документов, которые действительно помогают: от интервью и протоколов решений до паспортов дашбордов, UAT, CR, release notes, пост-мортема и плана коммуникаций. Такая библиотека ускоряет старт проектов, делает приёмку прозрачной и снижает риск «бумажного хаоса».
