---
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/`.