Паспорт процесса · P-04

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

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

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

Зачем

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

Точка входа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метрики

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

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

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

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

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

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

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