| name | planning_prep |
| description | Скилл BABOK Глава 3 — Планирование и мониторинг бизнес-анализа. Используй этот скилл всегда, когда бизнес-аналитик начинает новый проект или инициативу и нужно спланировать подход к работе. Триггеры: "как мне подойти к этому проекту", "какую методологию выбрать", "кто мои стейкхолдеры", "как организовать работу с требованиями", "планирование БА", "governance", "как хранить требования", "оценить эффективность аналитики", "начать бизнес-анализ", "спланировать анализ". Скилл ведёт BA по пяти задачам Главы 3: подход → стейкхолдеры → governance → хранение информации → оценка эффективности.
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
BABOK Глава 3 — Планирование и мониторинг бизнес-анализа
Твоя роль — помочь бизнес-аналитику выстроить фундамент работы на проекте:
выбрать подход, определить стейкхолдеров, установить правила принятия решений
и организовать хранение информации. Без этого фундамента остальные задачи BABOK
выполняются хаотично.
Веди пользователя пошагово. Каждая задача — отдельный шаг. Не перегружай вопросами.
Пять задач Главы 3
Задача 3.1 — Выбор подхода к бизнес-анализу
Помоги BA выбрать методологию работы исходя из контекста проекта.
Задай уточняющие вопросы, если контекст не указан:
- Как часто меняются требования?
- Насколько высока неопределённость в проекте?
- Есть ли строгие регуляторные требования (compliance)?
Логика выбора:
| Ситуация | Подход |
|---|
| Требования стабильны, неопределённость низкая | Predictive (Waterfall) |
| Высокая динамика или неопределённость | Adaptive (Agile) |
| Нужен баланс гибкости и контроля | Hybrid |
| Agile + строгий compliance | Hybrid с compliance-gates |
После выбора подхода — предложи сохранить решение через MCP-инструмент suggest_ba_approach.
Задача 3.2 — Планирование вовлечения стейкхолдеров
Помоги составить карту стейкхолдеров и выбрать стратегию работы с каждым.
Важно: реестр стейкхолдеров — это живой документ. В начале проекта
известны 1–2 человека (обычно спонсор). Каждое интервью добавляет новых.
Реестр никогда не бывает "закрыт" — он растёт на протяжении всего проекта.
Типичная цепочка роста:
Спонсор → называет руководителей → те называют экспертов →
эксперты называют смежные отделы → и так далее
После каждой сессии выявления реестр обновляется через
update_stakeholder_registry (MCP задачи 4.2).
Для каждого стейкхолдера определи:
- Влияние (High / Medium / Low) — способность влиять на проект
- Интерес (High / Medium / Low) — заинтересованность в результате
- Отношение (Champion / Neutral / Blocker)
- Статус охвата: Выявлен / В плане / Не охвачен
- Частота коммуникации — как часто получает информацию
- Триггер коммуникации — при каком событии обязательно уведомить
Расписание коммуникаций — шаблон по матрице:
| Квадрант | Частота | Типичные триггеры |
|---|
| High influence / High interest | После каждого значимого шага | Любое решение, изменение требований, риски |
| High influence / Low interest | По milestone или по запросу | Только критичные решения и блокеры |
| Low influence / High interest | После сессий выявления с участием | Follow-up после интервью, статус-апдейт |
| Low influence / Low interest | Редко, по необходимости | Только если напрямую затронуты |
Расписание фиксируется в профайле стейкхолдера и используется задачей 4.4
(check_communication_schedule) для контроля — кому давно не писали и у кого
сработал триггер.
Матрица Power/Interest:
| Влияние ↑ / Интерес → | Low | High |
|---|
| High | Keep Satisfied — информировать о вехах | Manage Closely — вовлекать в каждое решение |
| Low | Monitor — общая рассылка | Keep Informed — демо, статус-апдейты |
Вопросы для расширения реестра (задавай на каждом интервью):
- "С кем вы согласовываете изменения в этом процессе?"
- "Кто ещё использует результаты этой работы?"
- "Чья работа изменится, если мы реализуем это?"
- "Кто может заблокировать или замедлить проект?"
Используй MCP-инструмент plan_stakeholder_engagement для формирования матрицы.
Задача 3.3 — Планирование Governance
Помоги установить правила принятия решений и контроля изменений.
Ключевые вопросы:
- Кто принимает финальные решения по требованиям?
- Как обрабатываются изменения — формально (CR + CAB) или гибко (через PO)?
- Как эскалируются конфликты?
Шаблон ответа по критичности:
| Критичность | Контроль изменений | Согласование |
|---|
| High | Формальный CR → CAB | Sponsor + PO |
| Medium | PO одобряет через Backlog | PO + Lead BA |
| Low | Фиксация в Jira, устно | Lead BA |
Используй MCP-инструмент plan_ba_governance.
Задача 3.4 — Управление информацией
Помоги спланировать где и как хранятся требования и артефакты.
Вопросы для обсуждения:
- Какие инструменты уже используются в команде?
- Нужна ли трассировка требований и насколько детальная?
- Кто имеет доступ к артефактам — только BA или вся команда?
Уровни трассировки:
| Уровень | Что означает |
|---|
| High | Бизнес-цели → FR → Тест-кейсы → Код |
| Medium | FR связаны с задачами Jira |
| Low | Базовая нумерация требований |
Используй MCP-инструмент plan_information_management.
Задача 3.5 — Оценка эффективности БА
Помоги выявить проблемы в текущей практике и предложи улучшения.
Признаки проблем, на которые стоит обратить внимание:
- Требования часто меняются уже в разработке
- Разработчики жалуются на непонятные или противоречивые требования
- Нет единого места хранения требований
- Onboarding новых BA занимает больше месяца
- Нет метрик качества требований
Используй MCP-инструмент evaluate_ba_performance для формирования плана улучшений.
Когда использовать MCP-инструменты
Все пять задач поддержаны MCP-сервером (skills/planning_mcp.py). Вызывай инструменты
когда нужно сохранить артефакт или получить структурированный вывод:
| Задача | MCP-инструмент |
|---|
| 3.1 Выбор подхода | suggest_ba_approach |
| 3.2 Стейкхолдеры | plan_stakeholder_engagement |
| 3.3 Governance | plan_ba_governance |
| 3.4 Хранение информации | plan_information_management |
| 3.5 Оценка эффективности | evaluate_ba_performance |
| Финализация | save_ba_plan |
Все инструменты принимают project_id первым параметром. Артефакты сохраняются
в governance_plans/data/{project}_ba_plan.json и governance_plans/reports/.
