Аруна Бердыева

Памятка по 6 областям знаний для БА от Aruna Berdi tg:@ArunaBerdi

28.09.2025

Этот документ составлялся как практическая памятка по шести областям знаний BABOK, оформленная максимально с опорой на реальные задачи бизнес-аналитика. Если у Вас есть идеи что можно дополнить в данном документе или просто хотите выразить благодарность автору: Tg:ArunaBerdi

Предисловие (Не пропускать!)

 
Зачем нужны области знаний BABOK?
BABOK чуть ли не самая главная книга БА — он помогает мыслить системно: понимать, что, зачем и когда делать, чтобы анализ не превращался в хаос. Каждая область отвечает на свой ключевой вопрос:
  • как спланировать работу;
  • как общаться со стейкхолдерами;
  • как управлять требованиями;
  • как смотреть на бизнес шире;
  • как формализовать решение;
  • и как убедиться, что всё это реально приносит пользу.
Что в этом документе?
Для каждой области ты найдёшь:
  • краткое описание сути,
  • перечень создаваемых документов и артефактов,
  • разбор, что они включают, зачем нужны и в каком формате можно оформить,
  • краткий вывод зачем вообще это всё делать.
Как применять эту памятку на практике?
Важно помнить, что этот документ — не список обязательных форм и шаблонов, а скорее набор инструментов, из которых ты сам выбираешь, что использовать.
В реальности не всегда есть смысл делать всё, что описано. Особенно если ты работаешь в стартапе, где всё быстро меняется, — навалить на команду кучу формальностей будет абсолютно неверно.
Суть не в том, чтобы заполнять документацию ради документации. Суть — в том, чтобы понимать:
  • что ты делаешь,
  • зачем ты это делаешь,
  • и как это поможет команде и продукту.
Примеряй каждую идею из этой памятки на свой проект, команду и ритм работы. Где-то достаточно просто составить краткий список требований или список стейкхолдеров, а где-то и BRD с диаграммами будет в тему.
Используй ровно столько, сколько нужно, чтобы было понятно, полезно и эффективно. Не больше.
Удачи!
 

1. 📝 Планирование и мониторинг бизнес-анализа

Глава про то, как организовать свою работу:
  • какие техники использовать,
  • кто наши стейкхолдеры,
  • как с ними работать,
  • как управлять требованиями.
Основные документы которые формируются на этом этапе:
  • 1.1 План бизнес-анализа (Business Analysis Plan / Approach)
    • Зачем: определить, каким способом и по каким правилам будет организована работа аналитика на всём протяжении проекта.
    • Что включает: уровень детализации требований, выбранный подход (Agile, Waterfall), методы анализа и модели, артефакты и роли.
    • 📌 Возможный формат: документ в Confluence и др.
  • 1.2 План вовлечения заинтересованных сторон (Stakeholder Engagement Plan)
    • Зачем: понять, кого, когда и как вовлекать в работу с требованиями, чтобы избежать сопротивления и получить нужную информацию.
    • Что включает: список и роли стейкхолдеров, уровень их интереса/влияния, стратегия взаимодействия (уведомлять, вовлекать, консультировать и т.д.).
    • 📌 Возможный формат: таблица, RACI, карта влияния и др.
  • 1.3 План управления бизнес-анализом (Business Analysis Governance Plan)
    • Зачем: задать правила, как принимаются решения по требованиям, кто утверждает, и как обрабатываются изменения.
    • Что включает: процесс утверждения требований, управление изменениями, эскалации, работа с версиями.
    • 📌 Возможный формат: раздел в BA-плане, отдельный документ, схема процесса и др.
  • 1.4 План информационного менеджмента (Information Management Plan)
    • Зачем: определить, где, в каком виде и как долго будут храниться артефакты бизнес-анализа, и кто к ним имеет доступ.
    • Что включает: где и как хранятся требования, формат (Jira, Excel, Confluence), версии и доступы, архивирование.
    • 📌 Возможный формат: Confluence-документ, часть общего плана и др.
  • 1.5 Оценка готовности и производительности бизнес-анализа (Performance Assessment)
    • Зачем: проанализировать, насколько эффективно был выполнен бизнес-анализ, и что можно улучшить в будущем.
    • Что включает: что сработало/не сработало, ретроспектива BA-практик, предложения по улучшениям.
    • 📌 Возможный формат: отчет, ретроспектива в Confluence, чек-лист и др.
Вывод: Область "Планирование и мониторинг бизнес-анализа" самая формализованная в BABOK. Все пять задач имеют чётко определённые Outputs в виде документов, и каждый из них по сути представляет собой отдельный управленческий план. Эти документы основа вашей эффективной работы аналитика. Они помогают задать правила до того, как начинается работа с требованиями, и существенно уменьшают хаос в будущем.
 

2. 🗣️ Сбор и взаимодействие

Про умение вытащить суть из разговоров и наладить контакт со стейкхолдерами:
  • интервью, воркшопы, наблюдения,
  • умение понять настоящую боль,
  • выстроить доверие.
Основные документы которые формируются на этом этапе:
  • 2.1 План сбора требований (Elicitation Activity Plan)
    • Зачем: заранее продумать, какие методы использовать, с кем взаимодействовать и как организовать процесс.
    • Что включает: цели сессий, список участников, формат сбора (интервью, воркшопы, опросы и т.д.), дата и ресурсы.
    • 📌 Возможный формат: таблица в Excel, Confluence-документ и др.
  • 2.2 Протоколы и заметки сессий (Session Notes / Meeting Minutes)
    • Зачем: зафиксировать, что обсуждалось и какие требования были высказаны.
    • Что включает: краткое содержание встречи, выявленные требования, спорные моменты, действия по итогам.
    • 📌 Возможный формат: Протокол в Confluence, email-резюме и др.
  • 2.3 Сводка выявленных требований (Elicited Requirements Summary)
    • Зачем: собрать все зафиксированные требования в едином формате.
    • Что включает: описание требований, источник (от кого получены), приоритет/боль, потенциальные конфликты.
    • 📌 Возможный формат: Excel, таблица в Confluence и др.
  • 2.4 Визуализации и карты (Customer Journey Map, Event Storming, Process Map)
    • Зачем: отразить путь пользователя или бизнес-процесс в наглядной форме.
    • Что включает: шаги и действия, эмоции или точки контакта, системные взаимодействия.
    • 📌 Возможный формат: Miro, Figma, Draw io и др.
  • 2.5 Лог обратной связи (Feedback Log)
    • Зачем: отразить, как стейкхолдеры отреагировали на собранные данные.
    • Что включает: список комментариев, автор, решение (принято, отклонено, требует обсуждения).
    • 📌 Возможный формат: таблица, Confluence и др.
  • 2.6 Подтверждение требований (Sign-Off, Validation Summary)
    • Зачем: получить формальное или неформальное подтверждение правильности собранных требований.
    • Что включает: перечень требований, участники согласования, статус: подтверждено / не подтверждено.
    • 📌 Возможный формат: таблица с подписями, email-ответ и др.
Вывод: Область "Сбор и взаимодействие" в BABOK это про управляемый и итеративный процесс, где важно не только слушать, но и уточнять, валидировать, документировать и договариваться.
 

3. 🔄 Управление жизненным циклом требований

Про то, как требования живут, меняются и актуализируются:
  • отслеживание,
  • контроль изменений,
  • поддержание актуальности.
Основные документы которые формируются на этом этапе:
  • 3.1 Реестр требований (Requirements Register / Repository)
    • Зачем: централизованно хранить и актуализировать все требования.
    • Что включает: № и описание требований, категория (бизнес, пользовательские, нефункциональные), статус (черновик, утверждено, реализовано), владелец и источник, приоритет.
    • 📌 Возможный формат: Excel таблицы, Google Sheets, Confluence и др.
  • 3.2 Трассировочная матрица требований (Requirements Traceability Matrix, RTM)
    • Зачем: обеспечить прослеживаемость требований от целей до реализации и тестов.
    • Что включает: связь требований с бизнес-целями, зависимые и дочерние требования, связь с компонентами решений и тестами.
    • 📌 Возможный формат: таблица в Excel, Confluence и др.
  • 3.3 Лог изменений требований (Requirements Change Log)
    • Зачем: отслеживать все изменения требований, причины и принятые решения.
    • Что включает: № и описание изменения, инициатор, дата, решение (принято / отклонено), обоснование.
    • 📌 Возможный формат: Excel, Change Log в Confluence и др.
  • 3.4 Процедура управления изменениями (Change Control Process)
    • Зачем: формализовать, как инициируются, оцениваются и утверждаются изменения.
    • Что включает: шаги подачи запроса, формат заявки (Change Request), роли: кто подаёт, кто оценивает, кто утверждает.
    • 📌 Возможный формат: инструкция в Confluence, BPMN-схема, документ-регламент и др.
  • 3.5 Журнал согласования требований (Approval Log / Sign-off Log)
    • Зачем: фиксировать, кто, когда и какие требования утвердил.
    • Что включает: список требований, участники согласования, дата подтверждения, способ (подпись, комментарий, email).
    • 📌 Возможный формат: Excel, Google Sheets, комментарии в Jira, Confluence и др.
  • 3.6. Матрица версий требований (Requirements Versioning Table)
    • Зачем: отслеживать историю изменений каждого требования.
    • Что включает: версии, дата изменения, суть правки, автор.
    • 📌 Возможный формат: табличка, журнал правок и др.
Вывод: Область "Управление жизненным циклом требований" это «операционка» бизнес-анализа. Здесь аналитик выступает как хранитель порядка: он следит за статусами, связями, согласованиями и изменениями.
 

4. 🎯 Анализ стратегии

Про умение смотреть шире задачи:
  • понять, зачем всё это,
  • куда движется компания,
  • какие есть альтернативы.
Основные документы которые формируются на этом этапе:
  • 4.1 Анализ текущего состояния (Current State Assessment)
    • Зачем: понять, как работает бизнес сейчас, какие есть проблемы, ограничения, возможности.
    • Что включает: описание процессов, систем, людей, данных, политики, технологий, метрики и показатели, проблемы и узкие места.
    • 📌 Возможный формат: PDF-отчёт, презентация, BPMN/архитектурные схемы, таблицы в Excel и др.
  • 4.2 Анализ будущего состояния (Future State Definition)
    • Зачем: определить, чего хотим достичь, как будет выглядеть целевое состояние.
    • Что включает: бизнес-цели и KPI, целевые процессы и архитектура, новые роли, функции, технологии, ограничения (финансы, ресурсы, сроки).
    • 📌 Возможный формат: презентация, диаграммы TO-BE, текстовое описание, модели в BPMN и др.
  • 4.3 Оценка рисков (Risk Assessment / Risk Register)
    • Зачем: выявить, какие угрозы и неопределенности могут повлиять на достижение будущего состояния.
    • Что включает: список рисков, вероятность и влияние, способы реагирования (избежать, снизить, принять), ответственные лица.
    • 📌 Возможный формат: таблица в Excel, шаблон по PMBOK/ISO 31000, диаграмма рисков и др.
  • 4.4 Бизнес-кейс (Business Case / Justification for Change)
    • Зачем: обосновать, почему нужно запускать проект/изменение, какие выгоды и затраты.
    • Что включает: цель изменений, выгоды и издержки, возможные варианты реализации, рекомендуемый подход, критерии успеха.
    • 📌 Возможный формат: документ Word, Google Docs, презентация для стейкхолдеров и др.
  • 4.5. Стратегия изменений (Change Strategy Document)
    • Зачем: описать, как именно будет достигаться целевое состояние.
    • Что включает: что будет меняться (процессы, роли, системы), порядок внедрения (фазы, MVP), кто отвечает за что, критерии оценки эффективности изменений.
    • 📌 Возможный формат: текстовый документ, диаграмма перехода от AS-IS к TO-BE, карта этапов и др.
Вывод: Область "Анализ стратегии" помогает четко сформулировать направление изменений. Это фаза, где аналитик действует как стратег и архитектор будущего состояния.
 

5. 🧩 Анализ требований и определение решений

Про то, как превратить хотелки в понятные и реализуемые вещи:
  • уточнение требований,
  • моделирование,
  • создание спецификаций.
Основные документы которые формируются на этом этапе:
  • 5.1 Уточненные и структурированные требования (Specified Requirements)
    • Зачем: превратить сырые идеи в формализованные, проверяемые требования.
    • Что включает: функциональные и нефункциональные требования, бизнес-правила, ограничения, интерфейсы, структура (по приоритету, ролям, юз-кейсам).
    • 📌 Возможный формат: SRS, BRD, User Stories, Excel, шаблон в Confluence и др.
  • 5.2 Модели требований и решений (Models, Diagrams, Schemas)
    • Зачем: визуализировать логику, поведение и структуру решений.
    • Что включает: BPMN, UML (Use Case, Activity, Sequence), ER-диаграммы, диаграммы вариантов решений, mockup-прототипы.
    • 📌 Возможный формат: Miro, Figma и др.
  • 5.3 Подтвержденные требования (Validated Requirements)
    • Зачем: убедиться, что требования полные, корректные, реализуемые и полезные для бизнеса.
    • Что включает: результаты проверки требований (по чек-листу BABOK), комментарии и правки, финальный список после валидации.
    • 📌 Возможный формат: таблица с отметками, лог подтверждения, Jira / Confluence, с комментариями от стейкхолдеров и др.
  • 5.4 Варианты решений (Solution Options)
    • Зачем: описать возможные подходы к реализации требований.
    • Что включает: сравнение 2–3 вариантов реализации, плюсы/минусы, затраты, риски, сложность.
    • 📌 Возможный формат: сравнительная таблица, презентация, архитектурная схема, Miro-доска и др.
  • 5.5 Архитектура требований (Requirements Architecture)
    • Зачем: показать, как все требования связаны между собой и с целью решения.
    • Что включает: карта связей требований, иерархия (от бизнес-требований до пользовательских и системных), модули и компоненты.
    • 📌 Возможный формат: схема в Lucidchart, ArchiMate, табличное дерево в Confluence и др.
  • 5.6 Рекомендованное решение (Recommended Solution Option)
    • Зачем: выбрать наилучший вариант решения и обосновать выбор.
    • Что включает: краткое описание выбранного варианта, сравнение с альтернативами, расчет ценности/затрат, влияние на стейкхолдеров.
    • 📌 Возможный формат: документ Word, презентация и др.
Вывод: Область "Анализ и определение требований" ключевая фаза, где аналитик превращает идеи и гипотезы в формализованные, проверенные и полезные требования. Здесь создаются конкретные артефакты для разработки, тестирования и архитектуры.
 

6. 📊 Оценка решения

Про то, как понять — сработало или нет:
  • достигли ли цели,
  • есть ли польза,
  • нужно ли дорабатывать.
Основные документы которые формируются на этом этапе:
  • 6.1 Оценка текущей работы решения (Solution Performance Assessment)
    • Зачем: собрать данные о том, как работает решение на практике.
    • Что включает: KPI и метрики (время обработки, уровень удовлетворенности, снижение затрат и т.д.), данные мониторинга, количественные и качественные результаты.
    • 📌 Возможный формат: Excel-отчёты, BI-дэшборды, таблицы, JSON-логи, SQL-запросы и др.
  • 6.2 Анализ показателей решения (Solution Performance Analysis / Issue Log)
    • Зачем: интерпретировать собранные данные, выявить проблемы и причины.
    • Что включает: сравнение с целевыми значениями, выявленные дефекты / недоработки, карта проблемных зон.
    • 📌 Возможный формат: диаграммы, fishbone-анализ, документ с интерпретацией, лог инцидентов и др.
  • 6.3 Рекомендации по устранению ограничений (Solution Limitation Assessment / Recommendation)
    • Зачем: выявить, что мешает решению работать эффективнее.
    • Что включает: технические ограничения (перегрузки, баги, интерфейс), функциональные ограничения (неудобный фильтр, лишние шаги), предложения по улучшению.
    • 📌 Возможный формат: презентация, таблица GAP-анализа, backlog улучшений и др.
  • 6.4 Оценка ограничений со стороны предприятия (Enterprise Limitation Assessment)
    • Зачем: выявить внешние факторы, мешающие решению приносить ценность.
    • Что включает: организационные барьеры (обучение, сопротивление, процессы), недостаток ресурсов, несогласованность с другими системами.
    • 📌 Возможный формат: документ с причинами, презентация для руководства, список организационных рисков и др.
  • 6.5 Рекомендации по повышению ценности (Recommended Actions / Improvements)
    • Зачем: предложить шаги для повышения полезности и возврата инвестиций.
    • Что включает: список quick wins и долгосрочных улучшений, предложения по оптимизации процессов, roadmap улучшений.
    • 📌 Возможный формат: улучшенный backlog, презентация, roadmap в Miro или Confluence и др.
Вывод: Область "Оценка решения" помогает завершить цикл: от идеи и требований к реальной пользе. Здесь аналитик становится своего рода аудитором и советником по улучшениям.