# Процесс: разработка фичи по принятой спецификации

Учебный пример для продуктовой команды с общим Git-репозиторием и
автоматическими проверками. Значения заменяются данными команды до пилота.

## Зачем

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

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

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

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

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

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

- Принятая спецификация в системе задач или документов.
- Код и документация в каноническом Git-репозитории.
- Результаты автоматических проверок в CI.

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

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

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

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

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

- Git, система задач и CI команды.
- Версионируемые инструкции агента и скилл разработки в репозитории.
- Чек-лист ревью и критерии приёмки в задаче.

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

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

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

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

## Метрики

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

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

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

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

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

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

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