Показатели мониторинга · «Заявки»

Шаблон · Правила расчёта

Вымышленный пример выбора показателей, а не отчёт о работающем сборе. Имена соответствуют примеру команды; пути и решения ниже условные, пороги не являются нормативами методологии.

Команда выбрала показатели: 02.10.2026; implementation/decisions/2026-10-02-monitoring.md. Мониторинг и представление результатов организует: Павел Соколов — РП внедрения; готовит показатели для общего отчёта и статуса. Сбор настраивает: Елена Смирнова — ИИ-инженер сопровождения. Проверяет со стороны клиента: Илья Петров — ИИ-инженер клиента. Аномалии идеальных часов и оценённого участия людей проверяет: Анна Волкова — РП клиента; раз в неделю перед разбором итогов внедрения. Навык сбора: /ai-methodology/skills/implementation-monitoring/, версия 1. Журнал с результатами: implementation/pilot-journal.md.

Общие границы

• Поток задач: изменения форм/фильтров и правил статусов; показатели этих двух типов задач рассматриваются отдельно и совместно с проверкой состава.
• Процессы команды: project/task-workflow.md — статусы и переходы; project/git-workflow.md — ветки, MR и ревью; версии 1.
• Работа с агентами: project/task-route.md, версия 1; в этом примере выбран запуск сообщением в чате. Связи задач с MR, запусками и прогонами проверяет сборщик по плану мониторинга.
• Календарь когорт и часовой пояс: понедельник–воскресенье, Москва, UTC+3. Начало — сообщение о передаче готовых и согласованных требований в работу агента. Предварительная оценка объёма сохраняется при наличии; итоговая фиксируется после приёмки.
• Окно оценки когорты и публикация итога: неделя формирования и две следующие недели наблюдения; отсечка — начало следующего понедельника, отчёт в понедельник до 12:00. Для задач, переданных 05–11.10.2026, период наблюдения за когортой — 12–25.10, окно оценки когорты — 05–25.10; отсечка — 00:00 26.10, отчёт — 26.10.
• Что включено в оценку идеальных часов и оценённые трудозатраты: техническое проектирование, реализация, ревью, проверки, исправления и подготовка выпуска после передачи согласованных требований. У исходной оценки без агентов и оценки участия людей одинаковый состав работ. Бизнес-анализ, эксплуатация, общие затраты внедрения и сопровождения учитываются отдельно. Стоимость платформы и токены в человеко-часы не включаются.
• Способ оценки идеальных часов: агент. До запуска предлагает предварительную оценку по требованиям и кодовой базе; после приёмки уточняет её по согласованному объёму и выявленной сложности. Например, 8 часов уточнены до 12 из-за обнаруженной сложности интеграции; обе версии, состав работ, автор и причина сохранены в трекере. Если до запуска оценки не было, она формируется после приёмки. Анна проверяет выделенные аномалии; результаты и оценки в составе недельной сводки согласовывают Анна и Павел по общему порядку. Их уточнения не меняют выбранный способ оценки.
• Рабочий календарь для реакции людей: пн–пт 09:00–18:00, перерыв 13:00–14:00, праздники и отсутствие — по календарю адресата. Это правило M7; M1/M2/M5 измеряют календарное время только своей ответственной роли.
• Версия правил и дата применения: версия 1 с 05.10.2026.
• Ежедневный сбор: каждый день к 09:00 по Москве агент по расписанию собирает сведения за предыдущие сутки. Дневной интервал — 00:00–00:00, правая граница не включается.
• Пропуски и пересборка: Павел проверяет наличие результата; при сбое просит агента собрать нужные даты тем же навыком. Например: «Пересобери сведения за 25–27 октября 2026 года». Результат хранит период, версии правил, источники и пробелы; повтор не удваивает события.
• Публикация: дневные обновления после сбора; закрытие когорт и согласование оценок еженедельно. Пробная сборка и сверка с источниками — в FLOW-06 журнала PoC.

Агент оценивает участие людей по ревью MR, обсуждениям, правкам и результатам приёмки. В сводке показывает часы, диапазон и полноту данных, а для Анны готовит список аномалий. Анна еженедельно проверяет только аномалии идеальных часов и оценок участия людей, записывает поправки с основанием и сохранением исходного значения; Елена исправляет правила навыка. Например, завышение ревью из-за сгенерированных файлов требует поправки правила, а не запроса часов у разработчика. Регулярных запросов времени и ручных отчётов участников нет.

Выбранные показатели

Объём и эффект

P1 · Объём когорты

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: какой объём человеческой работы передали агенту и какая его часть завершена; объёмы N и S, остальные исходы рядом.
• События для расчёта: Передача готовой задачи и версия оценки Eᵢ; задача и версия требований связываются по чату и трекеру.
• Единица и выбранная граница: идеальные человеко-часы по последней доступной версии оценки; состав работ задан выше. Для принятых задач используется итоговая оценка, для остальных статус оценки виден отдельно; история предварительных значений сохранена. Анна проверяет только автоматически выделенные аномалии; обычные оценки не требуют её подтверждения.
• Цель или ориентир: наблюдаем без порога; увеличение объёма оцениваем вместе с качеством и исходами.

P2 · TTM до main

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: результат.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: как быстро агент и команда доводят переданный объём до интеграции.
• События для расчёта: Передача задачи в чате и merge последнего необходимого MR в Git; набор MR определяется описанием процесса.
• Единица и выбранная граница: медиана календарных дней от передачи в чате до влития последнего необходимого MR в main; итог — по S с завершённой приёмкой в окне оценки когорты.
• Цель или ориентир: не более 3,2 дня на сопоставимых задачах; историческая медиана — 4 дня.

P3 · Оценка сэкономленного времени

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: результат.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: разницу между идеальной оценкой обычной человеческой работы и оценёнными трудозатратами людей на решённые агентом задачи.
• События для расчёта: Приёмка, итоговая Eᵢ и подтверждённые действия людей в чате, MR, трекере и отчётах проверок; границы объёма одинаковы.
• Единица и выбранная граница: оценка часов и доли от идеальной оценки того же решённого объёма, с диапазоном неопределённости; оценённые затраты H/C/P показываются рядом.
• Цель или ориентир: не менее 30% на сопоставимом завершённом объёме с достаточным покрытием данных; при пересечении порога диапазоном оценки достижение цели не подтверждаем. Отрицательные значения сохраняются.

P4 · Автономность по трудозатратам

• Уровень и область: команда продукта «Заявки», выбранный поток изменений и недельные когорты.
• Назначение: процесс.
• Связанная цель и срок проверки: снизить участие людей в производстве ПО за период Пилота.
• Что показывает: участие людей относительно идеальных часов выполненного объёма с учётом HOTL и доделок.
• События для расчёта: приёмка результата, в том числе после передачи человеку; оценки идеальных часов; артефакты работы всех участников, последующих проверок и исправлений.
• Единица и выбранная граница: проценты по P4; в этом проекте часы людей оцениваются автоматически, поэтому публикуется оценка автономности с покрытием и ограничениями, а не показатель по фактически измеренным часам.
• Цель или ориентир: наблюдаем динамику на сопоставимых задачах; незавершённые HOTL-проверки и неучтённые доделки не считаются отсутствием труда.

Диагностика процесса и баланс

O1 · Исходы задач

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: какие задачи решены агентом, переданы людям, отменены или стали проблемными.
• События для расчёта: Решение S, принятая передача H, отмена C и отсутствие этих исходов к отсечке; источники решений заданы в процессе.
• Единица и выбранная граница: количество и доля каждого исхода от всех задач N; до отсечки открытые задачи показаны отдельно.
• Цель или ориентир: доля проблемных выше 10% — разбор причин и ограничение вывода об эффекте; передачи и отмены разбираются по причинам независимо от порога.

M1 · Подготовка результата агента

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: время на стороне платформы до первого предъявления полного результата.
• События для расчёта: Передача задачи, предъявление полного комплекта и интервалы блокирующего ожидания; чат, MR и журналы агентов.
• Ответственный: ИИ-инженер.
• Единица и выбранная граница: медиана календарных часов на задачу от передачи готовых требований до полного комплекта MR и доказательств; интервалы блокирующего ожидания людей и DevOps исключаются и показываются по соответствующей роли.
• Цель или ориентир: первые две созревшие когорты — наблюдение; затем инженеры предложат ориентир по типу задач.

M2 · Ревью кода

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: очередь и выполнение ревью разработчиком, включая повторные предъявления.
• События для расчёта: Передача готовой ревизии проверяющему и законченный вердикт каждого раунда; Git/MR и сообщения процесса.
• Ответственный: Разработчик клиента.
• Единица и выбранная граница: медиана календарных часов на задачу; каждый интервал начинается с передачи готовой ревизии на ревью и заканчивается законченным вердиктом. Draft и исправления агента не входят. Ревью автотестов считается отдельно при включении M2-Т.
• Цель или ориентир: медиана выше 24 часов — обратиться к разработчику по очереди и доступности ревью.

M5 · Проверка результата человеком

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: очередь и выполнение проверок ручным тестировщиком.
• События для расчёта: Готовность ревизии и условий, передача тестировщику и отчёт; чат, журналы тестовой среды и отчёт проверки.
• Ответственный: Тестировщик клиента (ручное тестирование).
• Единица и выбранная граница: медиана календарных часов на задачу от передачи готовой ревизии на доступной UAT с данными до отчёта «пройдено» или «есть дефекты»; последующие исправления исключены, повторные проверки учитываются отдельными интервалами той же роли.
• Цель или ориентир: медиана выше 8 часов — обратиться к тестировщику по очереди проверок.

M7 · Ответ на вопрос по требованиям

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: процесс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: ожидание ответа аналитика на вопрос агента.
• События для расчёта: Доставленный запрос аналитику и содержательный ответ; связанная пара сообщений с адресатом и временем.
• Ответственный: Аналитик клиента.
• Единица и выбранная граница: среднее и медиана рабочих часов завершённых запросов аналитику; количество и возраст открытых запросов показываются рядом. Обращения к другим ролям в эту строку не входят.
• Цель или ориентир: необычно долгие открытые вопросы разбираются ежедневно с аналитиком; когортная медиана показывает изменение скорости ответов.

Q1 · Замечания по трём каналам

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: баланс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: качество кода, автотестов и результата при проверке человеком.
• События для расчёта: Подтверждённые замечания к коду, тестам и результату, завершённые проверки и их применимость; MR и отчёты.
• Единица и выбранная граница: числа и доли S с 0/1/2+ подтверждёнными замечаниями отдельно по каждому каналу; непроверенные и неприменимые случаи видны отдельно.
• Цель или ориентир: наблюдаем динамику при одинаковом режиме проверок; критические дефекты разбираем независимо от количества замечаний.

R1 · Потребление ресурсов агентом

• Уровень и область: команда продукта «Заявки», выбранный поток изменений.

• Назначение: баланс.

• Связанная цель и срок проверки: сократить срок поставки и участие людей в выбранном потоке за период Пилота.

• Что показывает: расход моделей на задачи когорты, включая повторы и неудачные попытки.
• События для расчёта: Usage по запускам агентов, связанным с задачей, моделью и временем вызова; журналы агентов и платформы.
• Единица и выбранная граница: токены вход/выход/кэш по моделям и тарифным интервалам день/ночь; стоимость — только при наличии тарифа.
• Цель или ориентир: наблюдаем без порога; изменение расхода сравниваем с объёмом задач и результатом.

Баланс при изменении режима

B1 · Возвраты с тестирования после перехода разработки на HOTL

• Уровень и область: команда — продукт «Заявки», типовые изменения форм.
• Назначение: баланс.
• Связанная цель и срок проверки: сократить ожидание ревью; наблюдать переход на HOTL в течение Пилота.
• Что показывает: не ухудшилось ли качество передачи в тестирование.
• События для расчёта: разрешённый переход разработки на HOTL, первый завершённый проход тестирования, подтверждённый возврат по дефекту исходного объёма; трекер, результаты тестов, MR и проверенная ревизия.
• Ответственный: тестировщик.
• Единица и выбранная граница: доля по B1; окно наблюдения — 14 календарных дней после первого завершённого прохода; новые требования и сбои среды отдельно.
• Цель или ориентир: не выше сопоставимой базы HITL; рост требует разбора причин и решения о корректировке или возврате режима. Это условие учебного проекта, не общий порог.

Отложенные показатели и вопросы

• M3, исправления агента: Елена и Илья настраивают выделение интервалов исправления с исключением ожидания людей. Ответственный за этап — ИИ-инженер; повторное ревью остаётся в M2.

N, исходы, полнота данных, число наблюдений, открытые ожидания и существенные дефекты публикуются всегда. Алгоритмы извлечения и расчёта находятся в навыке, а значения, выводы и следующие действия — в журнале.