Реестр процессов агентной разработки: как оценить метрики, срок и стоимость автоматизации
Как команде из 5–30 человек выбрать один процесс, провести управляемый пилот и решить, стоит ли продолжать автоматизацию.
Команда может быстро подключить ИИ-агента к репозиторию, журналам или базе знаний. Это ещё не внедрение: пока не определены начало работы, принимаемый результат, полномочия агента и способ измерения, невозможно понять, стало ли лучше.
В этой статье — способ выбрать один повторяемый процесс, описать его в паспорте и провести контролируемый пилот. Результатом должно стать решение: продолжать автоматизацию, изменить её границы или остановить.
Материал рассчитан на продуктовую или инженерную команду примерно из 5–30 человек: одну–три рабочие группы с общим репозиторием, системой задач и ответственным за результат. Это граница статьи, а не официальное определение малого или среднего бизнеса.
Пять направлений практики
Это карта практики, а не этапы одного конвейера. Четыре предметных направления — бизнес-анализ (DISCOVERY), разработка продукта (DELIVERY), надёжность и инциденты (RELIABILITY), инфраструктура и платформа (PLATFORM). Внедрение ИИ в процессы (AI ENABLEMENT) — общая практика: выбрать конкретный процесс внутри любого направления, провести пилот и передать рабочий порядок команде.
Полная карта направлений и их назначение находятся в реестре.
Какие процессы уже есть в реестре
| ID | Направление | Конкретный процесс | Решение человека | Основная метрика |
|---|---|---|---|---|
| P-01 | DELIVERY | Разработка фичи по принятой спецификации | Проверка и решение о выпуске | Время до принятого результата |
| P-02 | RELIABILITY | Управление инцидентом | Влияние, восстановление и коммуникация | Время до оценки и восстановления |
| P-03 | PLATFORM | Изменение инфраструктуры через IaC | План, откат и применение | Доля воспроизводимых изменений |
| P-04 | DISCOVERY | Подготовка спецификации | Цель, требования и границы | Время до принятой спецификации |
| P-05 | DISCOVERY | Проверка продуктовой гипотезы | Запуск, риск и следующий шаг | Время от принятого вопроса до решения |
Строка реестра ведёт к Markdown-паспорту конкретного процесса. Он фиксирует назначение и точку входа, участников, шаги, входные и выходные артефакты, контроль человека, доступы, метрики, ресурсы и журнал запусков. Такой документ можно скопировать в репозиторий команды и уточнять по мере реальной работы.
P‑04 и P‑05 относятся к одному направлению, но решают разные задачи. Подготовка спецификации переводит принятую цель в требования и критерии приёмки. Проверка гипотезы нужна раньше, когда само предположение о проблеме, решении или ценности ещё может оказаться неверным. Для неё собран отдельный редактируемый раздел: правила, процесс, паспорт, реестр, пример и словарь. HADI используется внутри него как рабочий цикл «гипотеза → действие → данные → выводы», а не как замена исследованию аудитории.
Что здесь считается процессом
У процесса есть повторяемый триггер, рабочий ход и наблюдаемый результат. У запуска есть владелец, запись действий и решение о приёмке. Поэтому DELIVERY — направление, а «разработка фичи по принятой спецификации» — измеримый процесс.
ИИ-агент выполняет ограниченную часть работы. Он не становится владельцем и не получает права утверждать требования, принимать риск рабочей среды или выпускать изменение. Решение человека фиксируется как контрольная точка человека.
Управление инцидентом и PIR — не одно и то же
Дефект — несоответствие ожидаемому поведению, а инцидент — событие, которое уже мешает работе. При текущем воздействии сначала запускается P‑02: команда оценивает влияние и восстанавливает рабочий сценарий. Постоянное исправление после восстановления становится отдельной задачей P‑01.
Послеинцидентный разбор (Post-Incident Review, PIR) — документ и этап управления инцидентом, а не весь процесс. Команда заранее задаёт порог, при котором нужен полный разбор; для остальных событий достаточно записи в журнале. Подробный процесс и шаблоны собраны в разделе «Управление инцидентами».
Как считать результат
До пилота команда фиксирует исходное значение, затем цель и фактический результат. У каждого числа должны быть формула, начало и конец измерения, период и источник данных.
| Процесс | Основная метрика и формула | Защитная метрика | Источник |
|---|---|---|---|
| P-01 | Медианное время: принятие спецификации → принятие результата | Возвраты и дефекты после выпуска | Задачи, Git и CI |
| P-02 | Медианное время: сигнал → оценка; сигнал → восстановление | Повторения и просроченные действия | Канал, мониторинг и PIR |
| P-03 | Изменения из проверенного IaC ÷ все изменения инфраструктуры | Неуспешные применения и откаты | Git, развёртывание и мониторинг |
| P-04 | Медианное время: принятая вводная → принятая спецификация | Повторно открытые требования | Задачи и история документа |
| P-05 | Медианное время: принятый вопрос → записанное решение | Неопределённые результаты и пересмотр решений из-за ошибки данных | Реестр гипотез, паспорт и исходные данные эксперимента |
Пять–десять запусков помогают найти поломки процесса, но не доказывают рост производительности. Если сопоставимых запусков мало, команда фиксирует наблюдения, но не публикует процент улучшения. Симуляции и реальные инциденты считаются раздельно.
Как выбрать процесс и подготовить пилот
Небольшой команде не нужен отдельный отдел внедрения. Один человек может совмещать роли, но до старта должны быть назначены владелец процесса, технический владелец и проверяющий.
| Проверка | Что зафиксировать | Если этого нет |
|---|---|---|
| Процесс повторяется | История сопоставимых запусков или ожидаемая частота | Считать пилот исследовательским |
| Начало и результат наблюдаемы | События и системы, где они записываются | Сначала настроить учёт |
| Есть владелец | Кто принимает результат и решение по пилоту | Не начинать пилот |
| Ошибка обнаружима | Проверка до необратимого действия | Оставить чтение и черновик |
| Доступы ограничены | Системы, данные и разрешённые операции | Не подключать рабочие учётные данные |
| Есть ручной режим | Как команда продолжит работу без агента | Сначала восстановить ручной процесс |
Для первой попытки подходят подготовка спецификации, черновик изменения кода или план изменения инфраструктуры. Самостоятельный выпуск, изменение рабочей среды и внешняя коммуникация остаются за человеком.
Пилот на четыре недели
- Неделя 1. Заполнить паспорт, назначить роли и зафиксировать исходные значения.
- Неделя 2. Сравнить результат агента с обычной работой без изменения рабочих систем.
- Неделя 3. Разрешить только обратимые действия под подтверждением человека.
- Неделя 4. Посчитать скорость, качество, время проверки и стоимость; решить — расширить, изменить или остановить.
Для редкого процесса срок увеличивается. Исторические примеры, симуляции и реальные запуски учитываются раздельно.
Пилот останавливается при выходе за границы доступа, невоспроизводимом результате, ухудшении защитной метрики, превышении затрат на проверку над экономией или невозможности вернуться к ручной работе. Подробный ритм описан в процессе внедрения.
Из чего складывается стоимость
Полная стоимость включает часы обследования и настройки, часы владельца и проверяющего, интеграции, инструменты и резерв на исправления.
| Слагаемое | Учебное допущение | Расчёт |
|---|---|---|
| Обследование и настройка | 32 часа по 4 000 ₽ | 128 000 ₽ |
| Владелец и проверяющий | 12 часов по 3 000 ₽ | 36 000 ₽ |
| Модель и инструменты | Лимит пилота | 20 000 ₽ |
| Резерв | 15% | 27 600 ₽ |
| Итого | Округлено | 212 000 ₽ |
Это не тариф, а пример арифметики. Команда подставляет собственные ставки и лимиты. После пилота отдельно считается стоимость одного запуска: модель и инфраструктура плюс минуты человеческой проверки.
Как использовать раздел
Выберите строку в реестре или добавьте свой процесс, затем заполните паспорт и проведите пилот по подробной методике. Паспорт хранит факты конкретной команды; публичный пример показывает структуру и не заменяет обследование.
Основание и ограничения
Это авторская модель проектирования пилота, а не отраслевой стандарт и не отчёт об измеренном внедрении. Числа помечены как учебные допущения. Реальный результат появляется только в паспорте конкретной команды вместе с исходными данными и решением владельца.
Модель не подходит для полностью автоматического действия с необратимыми последствиями, если команда не умеет заранее проверить результат, ограничить полномочия и восстановить ручную работу.
Термины
- Исходное значение (baseline)
- Измеренное состояние процесса до пилота.
- Контрольная точка человека
- Место, где решение остаётся за человеком.
- Инфраструктура как код (IaC)
- Описание целевого состояния инфраструктуры в проверяемых файлах.
- Продуктовая гипотеза
- Причинное предположение о том, как конкретное изменение повлияет на наблюдаемое поведение выбранной аудитории.
- Послеинцидентный разбор (PIR)
- Документ об одном инциденте: влияние, хронология, причина, восстановление и предотвращающие действия.
- Теневой режим
- Агент готовит результат, но самостоятельно не изменяет рабочие системы.
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.