Мониторинг внедрения: гайд РП
Гайд для РП клиента и РП внедрения. Он описывает выбор показателей, подготовку сводок, согласование оценок и решения по результатам. Определения и расчёты находятся в показателях, техническая настройка — в гайде ИИ-инженера.
Когда применять и что нужно на входе
Начальная настройка выполняется до измерений: выбор показателей — на Подготовке, пробная сборка — на PoC, регулярные когортные сводки — на Пилоте. На PoC статистика эффекта не обязательна: проверяются возможности и качество, в том числе пробная сборка по журналу кейсов. На Пилоте результаты и решения записываются в недельный журнал.
Для настройки сбора нужны процесс задач, Git-процесс, маршрут работы с агентами и план мониторинга. Для регулярного разбора нужны выбранные показатели и цели, версия автоматической сводки, источники и ограничения данных, список аномалий, предыдущие решения и факты их исполнения. Даты публикации и встреч берутся из общего календаря паспорта. Отдельные встречи и параллельные отчёты для двух РП не требуются.
На предприятии гайд используется для организации общих сводок в области программы; сопоставимость и объединение результатов команд определяет порядок оценки программы. Подключение команды не меняет её правила измерения автоматически.
Разделение документов и ответственности
- Методология задаёт смысл, расчёт и ограничения показателей.
- Выбранные показатели проекта — короткий перечень того, что команда действительно отслеживает: название/ID, краткий смысл, единица, выбранная граница, цель или ориентир. Без SQL, промптов и алгоритмов извлечения.
- Навык мониторинга агента внедрения в литературе проекта содержит алгоритм сборки: источники, связи, события, вычисления, проверки и версию. Создание, настройка и исправление навыка, включая выбранный способ оценки идеальных часов, получение оценок команды, предварительные и итоговые версии с причинами изменений и оценку участия людей, обеспечивает ИИ-инженер. Работа входит в общие обязанности двух специалистов; её фактическую передачу от специалиста сопровождения специалисту клиента отражают в журнале.
- Журнал этапа хранит полученные сводки, ограничения, решения и действия команды. Новая ручная карточка каждой задачи не требуется: технические данные задачи собираются автоматически для воспроизводимости расчётов.
РП внедрения отвечает за организацию мониторинга и представление результатов: обеспечивает выпуск сводок к нужным датам, включает показатели и ограничения в общий отчёт/презентацию, готовит вопросы на решение. Сбор и расчёт выполняются автоматически; оценки Eᵢ агент формирует сам либо получает из выбранного процесса оценки команды. ИИ-инженер настраивает и поддерживает навык. РП клиента предоставляет факты своей команды и раз в неделю проверяет только аномалии оценок идеальных часов и участия людей. Оба РП участвуют в общем разборе и обеспечивают исполнение решений своей стороной; владельцы источников обеспечивают доступ и исправление исходных данных. Цели и решения по процессу определяет команда.
Передача настройки и поддержки между инженерами выполняется по гайду автоматического сбора.
Выбор показателей и запуск мониторинга
- Вместе с командой определить цели по гайду целей и ожидаемых результатов, выбрать метрики результата, процесса и баланса, сопоставимые типы задач, исходную базу, целевые значения, правила качества и достаточность данных.
- Зафиксировать в перечне показателей выбранные метрики, единицы и границы, календарь когорт и отсечку, конечную точку TTM, ответственных и рабочие календари. Для этапа наблюдения указать ровно одну ответственную роль; несколько ролей требуют отдельных этапов.
- Выбрать для потока один из двух способов оценки идеальных часов — агентом или командой — и источник результатов. Уточнения командой и РП относятся к согласованию. Способ применять последовательно; не выбирать его для отдельной задачи по получаемой экономии. Определения предварительной и итоговой оценок, сроки их фиксации и правила корректировок сохраняются в описании Eᵢ.
- В плане мониторинга связать каждую выбранную метрику с переходами процесса задач, шагами Git и маршрутом агента, указать нужные подтверждения. Передать ИИ-инженеру версии этих документов и доступные источники; организовать устранение пробелов. Получить пробную сводку и результат проверки по гайду автоматизации. При недостатке реальных данных явно отличать проверку алгоритма на контрольных случаях от подтверждения работоспособности сбора.
- Зафиксировать ежедневный сбор за прошлый день, часовой пояс, время и способ запуска — по расписанию или просьбой агенту. При ручном запуске назначить обращающегося и порядок догрузки пропущенных дней. Проверить сбор выбранным способом и доступность сводок; назначить подготовку материалов к общему статусу. Результат — связанные процессы задач/Git, маршрут агента и план мониторинга, проверенный сбор, ответственные за запуск, публикацию и согласование, известные ограничения. Новая ручная карточка каждой продуктовой задачи не требуется.
Ежедневный сбор
РП организует выполнение суточного сбора, проверяет наличие результата и покрытие дат. При запуске по просьбе назначенный участник ежедневно обращается к агенту за прошлый день. При пропуске или ошибке задаёт даты для догрузки либо пересборки; расчёты вручную не выполняет. Ежедневный сбор событий и еженедельные согласование оценок и разбор результатов сохраняют свой ритм.
Согласование оценок
Независимо от источника оценок РП клиента и РП внедрения, если он назначен, согласовывают их в составе недельной сводки. Проверяют состав работ, применённые правила и версии оценок, ограничения данных и результаты разбора аномалий. Согласование относится к оценкам как агента, так и команды; источник оценки сохраняется после уточнений.
Проверка аномалий
К недельному разбору агент автоматически готовит для РП клиента короткий список аномалий идеальных часов Eᵢ и оценок участия людей Hᵢ со ссылками и объяснениями. Проверка применяется к оценкам агента и команды. Сигналы — необычно большие или малые оценки относительно сопоставимых задач, несоответствие состава работ, слабое обоснование, низкая уверенность, пробелы и вероятные дубли. Правила и пороги отбора задаются в навыке отдельно для Eᵢ и Hᵢ. Среди сигналов возможного завышения экономии — завышенные Eᵢ и заниженные Hᵢ.
РП клиента раз в неделю проверяет только выделенные аномалии: оставляет оценку, корректирует её с основанием либо отмечает недостаток данных. Подтверждать оценку каждой задачи, каждую запись человеческого действия и опрашивать всех участников не требуется. Обычные оценки используются в расчётах без индивидуального подтверждения РП и не образуют очередь на проверку; запуск задачи проверки не ждёт. Неразобранные аномалии остаются видны с ограничением; молчание РП не означает их закрытие или подтверждение точности. Отсутствие ручной проверки обычных оценок не считается пробелом данных.
При корректировке сохраняются исходное и новое значения, дата, автор и причина. Проверка опирается на согласованный объём и условия обычной человеческой разработки: можно учитывать выявленную сложность необходимой работы, но нельзя подгонять Eᵢ под скорость или успешность агента и желаемую экономию. Изменение требований учитывается отдельно с сохранением исходной оценки и истории решения.
Систематические ошибки передаются ИИ-инженеру по порядку исправления навыка. Проверка РП оценивает правдоподобие и не превращает рассчитанные часы в фактически измеренные.
Фиксация результата
Результат согласования фиксируется в журнале Пилота: версия сводки, участвовавшие РП, подтверждённые оценки и поправки, неразрешённые вопросы. При отсутствии РП внедрения согласование выполняет РП клиента. Оценки с неразрешёнными вопросами остаются предварительными; ограничения вывода показываются явно. Согласование сводки не требует индивидуального подтверждения каждой обычной оценки и не блокирует запуск продуктовых задач.
Как выбирать следующий этап наблюдения
На ежедневной сверке инженеры смотрят открытые ожидания и необычно долгие задачи. На недельном разборе ИИ-инженер сопровождения и ИИ-инженер клиента сопоставляют медианы, возраст открытой работы, объём и исходы. Для нового этапа формулируют управленческий вопрос, одну ответственную роль, начало, конец, правила передачи ответственности, единицу наблюдения и предполагаемое действие. Этап с несколькими ответственными разделяется до включения в показатели управления.
Например: вырос M2 — обратиться к разработчику клиента по очереди ревью; вырос M5 — к тестировщику ручного тестирования; вырос M1 или M3 — к ИИ-инженеру по очереди и работе агента; вырос M7 — к аналитику по ответам на вопросы. Роль для действия известна из строки показателя; конкретную причину задержки уточняют по связанным событиям.
Список этапов открыт. ИИ-инженер сопровождения обновляет навык сбора, ИИ-инженер клиента проверяет соответствие реальному процессу, команда фиксирует выбор в документе показателей. Изменение определения получает версию и дату применения; старые и новые ряды не сравниваются без пересчёта по сохранённым исходным данным либо явного ограничения.
Недельный разбор и действия
РП внедрения обеспечивает сводку к установленному сроку; РП клиента предоставляет факты и позицию команды. После проверки аномалий и согласования оценок команда сопоставляет метрики результата, процесса и баланса с целями, учитывает ограничения данных, исходы задач и предыдущие меры. Предварительные значения помогают реагировать сейчас; для сравнения эффекта используются созревшие сопоставимые когорты.
| Показатели | Что помогает обнаружить | Какое воздействие рассмотреть |
|---|---|---|
| Исходы задач | Рост передач людям, отмен и проблемных задач | Уточнить выбор задач, ограничение доработок и своевременность помощи или передачи |
| Замечания к коду, автотестам и по результатам человеческого тестирования | Повторяющиеся дефекты, неоднозначные требования, недостаточные проверки | Скорректировать требования, литературу агента, навыки и правила проверки результата |
| Токены и стоимость | Рост потребления относительно объёма и результата, дорогие повторные попытки | Изменить промпты, состав контекста, выбор моделей и организацию запусков |
| Медианы этапов и ожидание реакции человека | Задержки, очереди, повторные циклы и открытые ожидания | Изменить маршрутизацию, доступность участников, инфраструктуру или регламент работы |
При сбое сборки РП ставит задачу ИИ-инженеру с указанием сводки и обнаруженного пробела. При задержке этапа обращается к ответственной роли по событиям конкретных задач. Изменение одного показателя не доказывает причину проблемы. Результат разбора — согласованная сводка, ограничения вывода и действия с ответственными, сроками, ожидаемым изменением показателя и когортами для проверки эффекта; каждый РП обеспечивает выполнение своей стороной.
Показатели рассматриваются во времени с отметками изменений моделей, навыков и правил; наблюдения участников дополняют числа. До улучшения фиксируется ожидаемый эффект, после ограниченной проверки — результат и решение по циклу PDSA. Записи ведутся в действующем журнале, новые формы на каждую задачу не нужны.
Итоги Пилота
РП внедрения готовит общий итоговый отчёт и презентацию, РП клиента обеспечивает факты и позицию команды. До вывода о достижении цели сверяют полноту и сопоставимость по правилам расчёта.
Два основания завершения сохраняются: цели достигнуты либо вся рабочая команда клиента и сопровождения, включая стейкхолдера, поддерживает конкретный план их достижения. Во втором случае фактическое недостижение целей и недостаток данных не скрываются. Решение и следующие действия фиксируются в журнале Пилота и плане достижения целей.