---
name: future_state
description: >
  Скилл BABOK 6.2 — Определение будущего состояния (to-be). Используй этот скилл когда
  BA хочет описать целевое состояние бизнеса, поставить SMART-цели с KPI, провести
  gap-анализ или зафиксировать ограничения и потенциальную ценность изменения.
  Триггеры: «будущее состояние», «future state», «to-be», «цели», «gap-анализ»,
  «ограничения», «потенциальная ценность», «SMART-цели», «define future state».
project: "AI-powered Platform AInalyst (AI Платформа AIналитик)"
copyright: "Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com"
---
# SKILL: Define Future State (BABOK 6.2)

## Когда читать этот скилл

Читай этот файл когда:
- BA говорит «нужно описать целевое состояние», «как должно быть», «будущее состояние»
- BA хочет поставить бизнес-цели с KPI
- BA проводит gap-анализ или описывает разрыв между as-is и to-be
- Запрос содержит: «будущее состояние», «future state», «to-be», «цели», «gap-анализ»,
  «ограничения», «потенциальная ценность», «SMART-цели»

## Что это за задача

BABOK 6.2 — Define Future State — описывает куда движется организация.

**Два ключевых выхода:**
1. **Описание будущего состояния** — 8 элементов «как должно быть» + SMART-цели с KPI
2. **Gap-анализ** — структурированное сравнение текущего и будущего состояний (вход для 6.4)

**Почему это важно:**
- Без будущего состояния нет основания оценивать дизайн-опции в 7.5
- SMART-цели с KPI дают baseline для измерения успеха в Главе 8
- Gap-анализ — прямой вход для 6.4: стратегия изменений строится на явном разрыве
- Потенциальная ценность в 6.2 — контекст для детального расчёта в 7.6

---

## MCP-инструменты (7 шт.)

| Инструмент | Когда вызывать |
|------------|----------------|
| `scope_future_state` | Первый шаг — контракт анализа, что описываем |
| `capture_future_state_element` | Для каждого элемента из скоупа (итеративно) |
| `define_goals_and_objectives` | Для каждой бизнес-цели с KPI (SMART-валидация) |
| `capture_constraints` | Для каждого ограничения по категории |
| `run_gap_analysis` | После заполнения всех элементов — явный артефакт |
| `assess_potential_value` | Структурированная оценка выгод (входные данные для 7.6) |
| `check_future_state_completeness` | Перед финализацией — coverage check |
| `save_future_state` | Финальный шаг — Markdown-отчёт + проброс в 7.3 |

> Примечание: `save_future_state` — 8-й вызов в pipeline, но в списке инструментов
> платформы считается как часть 7 основных инструментов задачи.

---

## Алгоритм работы

### Шаг 1 — Скоуп (обязательно первым)

Вызов `scope_future_state`. Явный контракт: что анализируем, какая глубина.

**Вопросы BA:**
- Те же элементы что в 6.1 или расширяем? → elements_in_scope
- Уровень детализации: стратегический срез или глубокая проработка? → analysis_depth
- Есть ли уже известные цели от спонсора? → known_goals

При наличии 6.1 — система автоматически читает скоуп текущего состояния как контекст.
Это рекомендованная отправная точка: те же элементы, но смотрим на «как должно быть».

---

### Шаг 2 — Сбор данных по элементам (итеративно)

Вызов `capture_future_state_element` для каждого элемента.

**Порядок работы:**
1. Начинай с `business_needs` — какие потребности будут удовлетворены
2. Потом `capabilities` — новые / улучшенные процессы
3. Потом `technology` — целевой технологический стек
4. По необходимости: `org_structure`, `policies`, `architecture`, `assets`, `external`

**UX-паттерн «прошлое рядом с будущим»:**
Если есть данные 6.1, инструмент автоматически покажет текущее состояние элемента рядом.
Используй это: BA описывает не «что добавить», а «как должно быть в итоге».

**Признак качественного описания:**
- Ориентировано на результат, не на процесс внедрения
- Есть целевые метрики (`target_metrics`)
- Трассировано к BN из 6.1 (`linked_business_needs`)
- Не дублирует текущее состояние

**Признак плохого описания:**
- «Будет CRM-система» — это решение, не будущее состояние
- «Всё будет лучше» — нет конкретики
- Описывает процесс внедрения, а не целевое состояние

Подробнее о 8 элементах: читай `references/future_state_guide.md`

---

### Шаг 3 — Бизнес-цели и KPI

Вызов `define_goals_and_objectives` для каждой бизнес-цели.

**SMART-валидация (подробнее: `references/future_state_guide.md`):**
- Инструмент проверяет критерии и предлагает улучшения
- Каждая цель привязана к BN из 6.1 → трассировка `BN → BG → FR`
- Цель регистрируется как узел `business_goal` в репозитории 5.1 (ADR-062)

**Структура `objectives_json`:**
```json
[
  {
    "title": "Сократить время обработки заявок",
    "metric": "Время обработки (часы)",
    "baseline": "8 часов",
    "target": "2 часа",
    "deadline": "2025-12-31"
  }
]
```

Цель без измеримого KPI — не цель. Помоги BA найти метрику.

---

### Шаг 4 — Ограничения

Вызов `capture_constraints` для каждого ограничения.

**Типы:** `budget | time | technology | policy | resources | compliance | other`

**Зачем фиксировать явно:**
- В 7.5 дизайн-опции разрабатываются в рамках ограничений
- Предполагаемые ограничения (`assumed`) нужно валидировать — могут оказаться мифами
- Неизвестные ограничения = риски проекта

---

### Шаг 5 — Gap-анализ (отдельный явный инструмент)

Вызов `run_gap_analysis`.

**Важно:** gap-анализ — инструмент мышления, не технический шаг.
BA должен запустить его осознанно после заполнения всех элементов.

Без данных 6.1: `current_description = null` — gap формулируется только по future.
С данными 6.1: автоматически сравнивается текущее и будущее состояние по элементам.

Результат (`{project}_gap_analysis.json`) — **обязательный вход для 6.4**.

Типы изменений: `new | improve | eliminate | replace`
Оценка сложности: `low | medium | high`

Подробнее: `references/future_state_guide.md` → раздел «Gap-анализ»

---

### Шаг 6 — Потенциальная ценность

Вызов `assess_potential_value`.

Качественная оценка, без формулы. Структурированный список выгод.
Это **контекст для 7.6**, не замена ему.

**Параметры:**
- `benefits_json` — JSON-список выгод (тип + magnitude + confidence + привязка)
- `investment_level` — качественная оценка уровня вложений
- `value_summary` — суммарный тезис для коммуникации со спонсором

Подробнее о типах выгод, magnitude, confidence: читай `references/value_guide.md`

---

### Шаг 7 — Проверка полноты

Вызов `check_future_state_completeness` перед финализацией.

Что проверяет:
- Все ли скоупированные элементы заполнены?
- Есть ли хотя бы одна цель с KPI?
- Привязаны ли BN к целям (если 6.1 есть)?
- Есть ли хотя бы одно ограничение?
- Запущен ли gap-анализ?
- Есть ли оценка потенциальной ценности?

Это предупреждения, не блокировки. Аналитик принимает решение идти дальше.

---

### Шаг 8 — Финализация

Вызов `save_future_state`.

**Параметр `push_to_business_context`:**
- `false` (по умолчанию) — только сохраняет отчёт 6.2
- `true` — готовит данные для передачи в 7.3. BA затем вызывает:
  `set_business_context(from_strategy_project_id="project_id", ...)`
  и данные из целей 6.2 предзаполнят бизнес-контекст для валидации требований (ADR-065)

---

## Интеграция с другими задачами

### Вход: 6.1 → 6.2 (опционально, ADR-060)

6.1 **не является обязательным** для работы 6.2 — graceful degradation.
При наличии 6.1 — автоматически читается:
- `{project}_current_state_scope.json` → контекст для скоупа 6.2
- `{project}_business_needs.json` → BN для трассировки целей
- `{project}_current_state.json` → текущее состояние для gap-анализа

### Выход: 6.2 → 5.1 (трассировка целей)

BG-xxx узлы регистрируются в репозитории 5.1 с типом `business_goal` (ADR-062).
Сквозная цепочка: `BN-001 → derives → BG-001 → satisfies → FR-001 → verifies → TC-001`

### Выход: 6.2 → 6.4 (стратегия изменений)

`{project}_gap_analysis.json` — обязательный вход для 6.4.
Стратегия изменений строится на явном перечне gaps и их типов.

### Выход: 6.2 → 7.3 (бизнес-контекст)

`set_business_context` в 7.3 принимает `from_strategy_project_id` (ADR-065).
При передаче — предзаполняет бизнес-цели и future_state из данных 6.1 + 6.2.
Старый параметр `from_current_state_project_id` deprecated, но работает.

### Выход: 6.2 → 7.6 (потенциальная ценность)

`add_value_assessment` в 7.6 при наличии 6.2 читает benefits как pre-fill контекст.
BA уточняет качественные оценки количественно — не начинает с нуля.

---

## Артефакты 6.2

| Файл | Назначение |
|------|------------|
| `{project}_future_state_scope.json` | Контракт: что анализируем |
| `{project}_future_state.json` | Элементы, цели, ограничения, ценность, статус |
| `{project}_future_state_goals.json` | Цели и KPI (+ регистрация в 5.1) |
| `{project}_gap_analysis.json` | Gap-анализ — вход для 6.4 |
| `6_2_future_state_{project}.md` | Читаемый отчёт (REPORTS_DIR) |

---

## Reference-файлы

Читай когда нужны детали:

- **`references/future_state_guide.md`** — подробное описание 8 элементов, SMART-критерии,
  типы изменений gap-анализа, типы и статусы ограничений, UX-паттерны

- **`references/value_guide.md`** — типы выгод, magnitude/confidence, investment_level,
  структура benefits_json, типичные ошибки BA при оценке ценности