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