# Процесс: подготовка спецификации

Учебный пример для команды без отдельного бизнес-аналитика. Владелец процесса
может называться руководителем продукта, основателем или заказчиком со стороны
бизнеса.

## Зачем

- Какую проблему решаем: пробелы и противоречия обнаруживаются на встречах или уже после передачи задачи в разработку.
- Какой результат должен измениться: сократить время до принятой спецификации и реже открывать требования заново.
- Как процесс связан с целью внедрения: агент собирает контекст, находит противоречия и готовит вопросы, но не принимает бизнес-решения.

## Точка входа

- Что запускает процесс: принятая бизнес-вводная.
- Кто может запустить: руководитель продукта, основатель или заказчик.
- Где это происходит: система задач и документов команды.
- Как понять, что входные данные готовы: названы цель, автор вводной и канонический источник контекста.

## Участники и ответственность

- Владелец процесса: руководитель продукта, основатель или заказчик.
- Кто готовит входные данные: автор бизнес-вводной.
- Кто принимает результат: владелец процесса и представитель разработки.
- Кто обновляет шаблоны, промпты или скиллы: аналитик, Tech Lead или назначенный инженер.

## Входные данные

- Бизнес-вводная в канонической системе задач или документов.
- Принятые решения, ограничения и словарь предметной области.
- Разрешённые и при необходимости обезличенные материалы исследований.

## Выходные артефакты

- Список открытых вопросов и противоречий.
- Черновик спецификации с границами и критериями приёмки.
- Запись согласования владельцем и представителем разработки.

## Шаги процесса

| Шаг | Вход | Выход | Критерий качества |
| --- | --- | --- | --- |
| 1. Собрать контекст | Бизнес-вводная и разрешённые источники | Список фактов, пробелов и противоречий | Каждый факт связан с источником; догадки отделены от данных |
| 2. Уточнить открытые вопросы | Список пробелов и противоречий | Ответы владельца и перечень оставшихся вопросов | Для каждого существенного вопроса есть ответ или явный статус «открыт» |
| 3. Подготовить спецификацию | Подтверждённые ответы и контекст | Черновик границ, сценариев и критериев приёмки | Требования однозначны, проверяемы и не содержат выдуманных решений |
| 4. Проверить с разработкой | Черновик спецификации и контекст системы | Замечания о реализуемости и рисках | Представитель разработки подтвердил понимание или сформулировал конкретные вопросы |
| 5. Принять спецификацию | Черновик и замечания разработки | Принятая версия или возврат на уточнение | Решение владельца записано; открытые вопросы не скрыты |
| 6. Записать результат | Временные отметки, проверки и решение | Строка в журнале запусков | Указаны источники метрик, проверяющие и следующий вывод |

## Промпты, скиллы и инструменты

- Система задач и документов команды.
- Версионируемые инструкции агента и шаблон спецификации.
- Журнал вопросов, решений и запусков процесса.

## Контрольные точки с человеком

- Где человек обязан проверить результат: после списка вопросов и перед передачей спецификации в разработку.
- Какие решения нельзя отдавать агенту: бизнес-цель, правила предметной области, граница задачи и критерии приёмки.
- Что делать, если результат сомнительный: оставить вопрос открытым и вернуть его владельцу, не заполняя пробел догадкой.

## Данные и доступы

- Какие данные разрешены: выбранные задачи, документы и обезличенные исследования в периметре вводной.
- Какие данные запрещены: материалы без разрешения, лишние персональные данные и секреты.
- Где лежат секреты или инструкции по доступу: в принятом командой хранилище секретов; в паспорт значения не копируются.
- Как отключить агента и продолжить вручную: отозвать доступ и продолжить уточнение на встрече по сохранённому списку вопросов.

## Метрики

- Основная метрика результата: медианное время от принятой вводной до принятой спецификации; источник — система задач.
- Метрика качества или внедрённости: доля спецификаций, принятых разработкой без возврата на уточнение.
- Негативный сигнал: повторно открытые требования и рост времени владельца на ответы и проверку.
- Исходный уровень: измерить на сопоставимых вводных за неделю до пилота.

## Ресурсы и срок

- Срок первого этапа: 4 недели плюс месяц наблюдения за передачей спецификаций в разработку.
- Время команды: около 8 часов на настройку, 3–5 проверок, 4 часа на итоговый разбор и фактическое время владельца на ответы.
- Лимит на инструменты и инфраструктуру: определить до запуска и не расширять без решения владельца.
- Стоимость одного запуска: стоимость инструментов плюс время владельца и проверяющего; измерить на первых трёх вводных.
- Полная стоимость этапа: не менее 12 часов по внутренним ставкам плюс проверки, ответы и фактическая стоимость инструментов.

## Критерий внедрённости

- Когда процесс считается принятым: подходящие вводные регулярно проходят через вопросы, черновик и две человеческие проверки, а метрики не хуже согласованного порога.
- Когда процесс нужно остановить или пересобрать: агент использует данные без разрешения, скрывает неопределённость, увеличивает число повторно открытых требований или не ведёт журнал.
- Кто принимает решение: владелец процесса.
- Когда пересматривать: после 4 недель пилота и ещё раз после месяца наблюдения.

## Журнал запусков

| Дата | Вход | Результат | Проверка человеком | Метрики | Что изменить |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |