Показатели и правила расчёта

Определения показателей, формулы, состав данных и ограничения выводов о результате внедрения. Организация мониторинга, согласование оценок и разбор результатов — в гайде РП; настройка и проверка автоматического сбора — в гайде ИИ-инженера.

Матрица показателей

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

Уровень, область, назначение и границы выбранных показателей фиксируются в плане мониторинга. Несопоставимые результаты разных продуктов сохраняются отдельными группами.

Основные понятия

Виды показателей

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

Назначение зависит от цели: дефекты — показатель баланса при ускорении поставки и результата при улучшении качества. Объём агентских задач и сокращение HITL не доказывают эффект сами по себе. Классификация адаптирована из Model for Improvement; постановка цели и проверка изменений — в гайде улучшений.

Когорты и сроки наблюдения

• Недельная когорта — задачи, впервые переданные агенту с проработанными и согласованными требованиями в течение одной календарной недели.
• Неделя формирования когорты — календарная неделя, в течение которой в неё включаются переданные агенту задачи.
• Период наблюдения за когортой — заранее установленный срок наблюдения за этими задачами после недели передачи. Рекомендуем две следующие недели.
• Окно оценки когорты — весь интервал: неделя формирования когорты и последующий период наблюдения за ней. Рекомендуемое окно — три календарные недели.
• Отсечка — момент завершения окна оценки когорты. По событиям до неё фиксируется её итог.

Например: неделя 25 — формирование когорты → недели 26–27 — период наблюдения за когортой → начало недели 28 — итоговый отчёт. Окно оценки когорты охватывает недели 25–27.

Что фиксируется после отсечки

• До отсечки показатели предварительные, после — итоговые.
• Задачи без решения, принятой передачи человеку или отмены к отсечке относятся к «Проблемным».
• Позднее завершение проблемной задачи не возвращает её в показатели нормального решения этой когорты.

Слайд · Выбранные показатели проекта — шаблон · Пример заполнения.

Границы измерения эффекта

Целевой показатель относится к трудозатратам на производство ПО: техническому проектированию, коду, проверкам, тестированию, исправлениям и подготовке выпуска на основе согласованных требований. Бизнес-анализ и эксплуатация в него не входят. Для каждого потока фиксируется учитываемый состав работ; исходная оценка без агентов и оценка участия людей с агентами используют одинаковые границы.

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

Типовые метрики команды

Метрики выбираются под согласованные цели внедрения. Метрики результата показывают достигнутый прогресс относительно согласованных целей внедрения. Метрики процесса и баланса нужны для управления: помогают обнаружить задержки, препятствия, ухудшение качества или рост нагрузки и затрат, чтобы выбрать действие. Для выбранного показателя задаются поток, период наблюдения, исходная база, целевое значение или ориентир и допустимые отклонения. Формирование целей — по гайду целей и результатов; организация измерения — в гайде РП.

Результат команды

Процесс команды

Баланс команды

Баланс измеряется до и после изменения на сопоставимых задачах при одинаковом способе выявления проблем. Допустимое отклонение и условия вмешательства задаются заранее. Отсутствие найденных дефектов при сокращении проверок не доказывает сохранение качества.

B1. Возвраты с тестирования

Доля возвратов = задачи хотя бы с одним подтверждённым возвратом на исправление / задачи с завершённым первым проходом согласованного тестирования и полным окном наблюдения × 100%. Числитель — подмножество знаменателя; при нулевом знаменателе — «н/д». Повторные возвраты одной задачи не увеличивают долю, но число циклов показывается отдельно. Возвратом считается подтверждённый дефект исходного согласованного объёма; новые требования, сбой стенда и ожидание данных выделяются отдельно.

По тем же задачам учитываются возвраты, обнаруженные в согласованном окне наблюдения; незавершённые проверки, ещё не созревшие задачи и известные по ним возвраты показываются рядом. Сравниваются типы задач, режим разработки, состав тестирования и критичность дефектов. Если тестирование стало тщательнее, рост возвратов нельзя целиком приписать переходу на HOTL.

B2. Дефекты после приёмки

Доля задач с пропущенным дефектом = принятые задачи с хотя бы одним подтверждённым дефектом, найденным после приёмки / принятые задачи с полным окном наблюдения × 100%. Числитель берётся из того же знаменателя; при нулевом знаменателе — «н/д». Окно после приёмки задаётся одинаково для сравниваемых задач. Для ещё не созревших задач показываются возраст и уже известные дефекты, без включения в итоговую долю.

Рядом показываются количество и критичность дефектов, место обнаружения — следующий этап, UAT или production — и полнота связи с исходной задачей. Один дефект, затронувший несколько задач, не размножается в числе дефектов; правило отнесения фиксируется заранее. Поздняя находка сохраняется в истории качества и отдельном наблюдении, не меняя исход S/H/C/P когорты задним числом.

B3. Нагрузка проверяющих

По каждой проверяющей роли показываются оценённые активные часы проверки за период и на проверенную задачу: сумма часов проверки / число задач с известной оценкой проверки. Рядом — покрытие оценками, количество обработанных задач, число и рабочий возраст открытых ожиданий. Периодная нагрузка учитывает работу с задачами любых когорт и обозначается отдельно от когортного эффекта; одна активность не дублируется в общих затратах.

Количество ожидающих проверок — число открытых запросов на проверку по каждой роли на дату среза; напоминание по тому же запросу не создаёт новую проверку. Рядом показываются рабочий возраст ожиданий и количество обработанных проверок.

Включаются ревью, разбор доказательств и последующие HOTL-проверки и замечания. Длительность ожидания не подменяет активное время человека. Источники и ограничения автоматической оценки — по правилам Hᵢ. Снижение времени на задачу при перегрузке роли и растущей очереди не подтверждает допустимую общую нагрузку.

Объём, сроки и трудозатраты

P1 описывает размер потока, P2 и P3 — эффект в выбранных границах. Обозначения N, S/H/C/P и правила исходов приведены ниже.

P1. Объём задач когорты в идеальных часах

Объём когорты — суммарная оценка того, сколько активных человеко-часов потребовалось бы команде для выполнения переданного агенту объёма обычным способом, без агентов и без ожиданий. Это размер входящего объёма задач, а не время работы агентов, расход токенов или длительность календарной недели.

Для задачи i обозначим эту оценку Eᵢ. Это оценка того, сколько идеальных часов потребовалось бы людям для выполнения согласованного состава работ без агентов. Основания — требования, контекст кодовой базы, сложность изменений и сопоставимые задачи.

В проекте выбирается один из двух способов оценки:

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

При любом способе оценка проходит согласование с РП. Уточнение оценки участниками команды или РП входит в этот порядок и не образует отдельного способа оценки.

Для каждой версии сохраняются источник и автор оценки, дата, версия требований, учитываемый состав работ и краткое обоснование. Готовая оценка команды используется при совпадении единиц и состава работ. Story points не переводятся в часы без отдельно проверенного правила проекта. Для сравнения задач потока используется единый выбранный способ оценки; его изменение указывается в версии правил, а не выбирается по величине экономии.

Предварительная оценка может быть зафиксирована до передачи задачи в работу. Она помогает оценивать входящий объём, но не является условием запуска. Итоговая оценка фиксируется после приёмки результата, когда понятны согласованный выполненный объём и выявленная сложность работы. Если предварительная оценка была, её проверяют и при необходимости корректируют; если её не было, оценку впервые формируют после приёмки. При неизменном значении также отмечается переход к итоговой оценке.

При корректировке сохраняются исходное и новое значения, дата, автор и причина: например, обнаруженная сложность интеграции, уточнение предположений или изменение согласованного объёма. Изменение объёма отделяется от уточнения сложности прежнего объёма. Новые возможности не увеличивают задним числом объём, переданный на старте: исходные границы и добавленный объём показываются отдельно. Eᵢ и Hᵢ для расчёта экономии всегда относятся к одному составу работ.

Например, до начала задачи команда оценила работу в 8 идеальных часов. При выполнении выяснилось, что согласованное поведение требует обработки дополнительного состояния интеграции; после приёмки оценка обычной человеческой работы уточнена до 12 часов. Сохраняются обе оценки и объяснение разницы в 4 часа. Число попыток агента или длительность его работы сами по себе такую поправку не обосновывают: оценивается необходимая работа людей без агентов, без переноса на неё лишних действий и ошибок агента.

В предварительных сводках используется последняя доступная версия Eᵢ. После приёмки — итоговая; её отсутствие показывается явно, а экономия по такой задаче остаётся предварительной. По незавершённым, переданным и отменённым задачам используется последняя обоснованная оценка переданного объёма с отметкой её статуса; она не заменяется оценкой только выполненной части. В сводке отдельно показываются число предварительных и итоговых оценок. Если оценки нет, действует правило неполных данных ниже.

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

Vₙ = Σ Eᵢ по всем N задачам когорты. По завершении окна оценки когорты дополнительно показываются Vₛ, Vₕ, V꜀, Vₚ — объёмы решённых, переданных, отменённых и проблемных задач; при полной оценке Vₙ = Vₛ + Vₕ + V꜀ + Vₚ. До отсечки вместо P используется U. Объём S показывает завершённый агентом объём, объём N — сколько команда доверила агентам.

Указываются идеальные человеко-часы и покрытие число задач с оценкой / N. Если оценено 8 из 10 задач, сумма восьми обозначается как известный объём, покрытие 8/10, а полный Vₙ — «н/д». Неоценённая задача не равна нулю. N и распределение исходов показываются даже при полном покрытии: рост объёма сам по себе не доказывает успешного завершения задач.

P2. Time to market

Для задачи TTMᵢ = t_endᵢ − t0ᵢ. Начало — передача готовых требований агенту по правилу когорты. Конечная точка определяется проектом: например, влитие всех необходимых MR в интеграционную ветку, успешное завершение согласованного набора тестов на нужной ревизии или выпуск. Название показателя должно называть точку: «TTM до main», «TTM до успешного тестирования».

TTM считается в календарных часах или днях, включая ночи, выходные, очереди, HITL и доработки. По S показываются медиана, при необходимости среднее, число валидных наблюдений и покрытие относительно S. Для чётного числа наблюдений медиана равна среднему двух центральных значений отсортированного ряда. При отсутствии наблюдений — «н/д».

Конечная точка TTM и условия исхода S могут различаться: MR уже влит, но приёмка ещё не завершена. Тогда итоговый TTM успешного решения публикуется только после подтверждения S в окне оценки когорты. Промежуточные времена по остальным задачам относятся к диагностике, а не к успехам. H/C/P исключаются из TTM успешного решения, но их число, затраты и возраст незавершённой работы остаются рядом. Нельзя улучшать TTM, молча удаляя долгие задачи.

Если нужных MR несколько, конец интеграции — влитие последнего необходимого MR. Успешное тестирование — подтверждённый итог всех обязательных проверок целевой ревизии; результат теста другой ветки или старого коммита не подходит. Два разных конечных события могут отслеживаться отдельными показателями, без смешивания в одной медиане.

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

Для решённой агентом задачи Δᵢ = Eᵢ − Hᵢ, где Hᵢ — оценённые активные трудозатраты людей на тот же состав работ, что включён в Eᵢ. Для когорты Δₛ = Σ(Eᵢ − Hᵢ) по решённым задачам с обеими величинами. Отрицательная экономия сохраняется: она означает, что участие людей с агентом превысило оценку работы без агентов, а не ошибку формулы.

Здесь сравниваются только трудозатраты людей: идеальная оценка работы без агентов и оценка участия людей при решении задачи с агентом. Работа платформы, токены и стоимость платформы в Eᵢ, Hᵢ и разность Δᵢ не включаются. Финансовую оценку с учётом стоимости платформы команда при необходимости настраивает отдельно при внедрении.

Доля экономии = Δₛ / Σ Eᵢ × 100% при положительном знаменателе, по той же выборке. Проценты отдельных задач не усредняются. При неполных данных указываются сумма по известной выборке и её размер, а полная экономия когорты — «н/д». Отсутствие наблюдаемых действий не означает отсутствие работы человека.

Границы Eᵢ и Hᵢ фиксируются до Пилота. Если Eᵢ оценивает работу после готовых требований, Hᵢ включает весь соответствующий труд после передачи: уточнения, сопровождение, разработку человеком, ревью, тестирование, исправления и интеграцию. Подготовка до передачи показывается отдельно. Если команда включает подготовку в экономию, она включается в обе величины. Число часов подготовки не меняет t0 календарного TTM.

Нельзя считать экономию как Vₙ − часы всех задач: отменённый или незавершённый объём дал бы фиктивную выгоду. Рядом с Δₛ показываются часы H/C/P и общие затраты внедрения. При полном учёте можно добавить отдельный консервативный показатель: оценка эффекта потока = Vₛ − Hₙ, то есть ценность завершённого агентом объёма в идеальных часах минус оценённый труд по всем N задачам в тех же границах и до отсечки. Это отдельная оценка, а не экономия каждой задачи; ручное продолжение H и ограничения его наблюдения раскрываются.

Идеальные часы E и оценённые затраты H — две оценки с разными основаниями, а не измеренная реальность. Поэтому Δ обозначается оценкой высвобожденного времени, не денежной экономией или сокращением штата. На исторических человеческих задачах проверяют систематическое завышение/занижение оценок; изменение шкалы оценивания отмечается в сравнении когорт.

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

A = (1 − H / E) × 100%, где H — фактические часы работы людей, E — идеальные часы выполненного объёма без агентов.

Для выбранной когорты в E включается только выполненный и принятый в окне наблюдения объём. В него могут входить задачи, завершённые агентом или доделанные людьми; факт ручного завершения должен быть подтверждён. Исход H «передано человеку» сохраняется даже после ручного завершения и не становится S. Незавершённый и отменённый объём в знаменатель не входит.

В числителе учитывается труд людей по всем задачам этой когорты в тех же границах производства ПО и окне наблюдения: уточнения, помощь агентам, HITL-ревью, асинхронные проверки HOTL, тестирование, исправления, ручное завершение, а также работа над отменёнными и незавершёнными задачами. Это сумма активных часов всех участников; параллельный час двух специалистов даёт два человеко-часа. Ожидание ответа или вычислений само по себе рабочим временем человека не считается. Общие расходы внедрения и сопровождения показываются отдельно по правилам границ.

Например, принятый объём оценён в 100 идеальных часов. Если люди потратили 30 часов, A = 70%; если после ревью и HOTL пришлось добавить ещё 40 часов исправлений, A = 30%. При 100 часах участия людей показатель равен 0%, при 120 — −20%. Отрицательные значения сохраняются; среднее процентов отдельных задач не используется.

Фактические часы берутся из доступного учёта, если он есть. При использовании автоматической оценки участия людей результат называется оценкой автономности по трудозатратам: источник и покрытие указываются явно, оценённые часы не выдаются за измеренный факт. Разные способы учёта не смешиваются молча. Нового обязательного табеля или запросов участникам о потраченном времени показатель не вводит.

При E = 0 показатель — «н/д». Если нет необходимых оценок объёма или данных о человеческом труде, полный показатель также не рассчитывается; пропуск не заменяется нулём. Пока запланированные HOTL-проверки и последующие исправления не завершены или не наблюдаются, показатель предварительный либо недоступен. Позднее выявленный человеческий труд отражается с периодом и версией расчёта; его нельзя скрывать за успешным завершением задачи. Исходы и отсечка когорты не переписываются ради поздних результатов.

Рядом показываются выполненный объём, фактические или оценённые часы людей, полнота данных, исходы задач и режимы контроля. Рост показателя отражает уменьшение участия людей; решение о смене HITL/HOTL принимается по действующему гейту.

Оценённые трудозатраты людей

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

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

По каким признакам оценивать

Сначала агент находит свидетельство выполненного человеком действия, затем оценивает его объём и сложность. Наличие большого MR само по себе не доказывает, что его прочитали. Учитываются авторство и содержание: текст, созданный агентом, не становится человеческой работой из-за публикации от имени участника.

Правила расчёта и полнота

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

Оценки используют зафиксированные правила выделения действий, признаки сложности, коэффициенты и диапазоны часов. Универсальная норма «минут на строку» не задаётся. Предварительная и итоговая Eᵢ ведутся по правилам оценки объёма; Hᵢ выводится из наблюдаемого участия людей и не рассчитывается как доля Eᵢ или желаемая экономия. Уточнение Eᵢ после приёмки не меняет независимо оценённую Hᵢ.

Для каждого действия автоматически сохраняются ссылки на основания, исполнитель, связанные задачи, тип и объём работы, центральная оценка часов, диапазон и уверенность с объяснением. Эти записи нужны для воспроизводимости; вручную заполнять их не требуется. Оценки и извлечённые признаки сохраняются с версией правил, чтобы повторная агрегация не давала произвольных новых чисел.

• Одно действие учитывается один раз: обсуждение замечания в чате и MR связывается, повторные уведомления исключаются. Общая работа нескольких задач распределяется по правилу навыка без увеличения её суммы.
• Hᵢ складывается из оценок уникальных действий; когортный итог — из оценок задач. Диапазон получается суммой нижних и верхних границ. Он отражает неопределённость модели оценки, а не статистический доверительный интервал.
• Для экономии показываются центральная оценка и диапазон: при Hᵢ ∈ [Lᵢ; Uᵢ] получаем Δᵢ ∈ [Eᵢ − Uᵢ; Eᵢ − Lᵢ]. Неопределённость самой Eᵢ рассматривается отдельно. Если диапазон пересекает целевой порог, центрального значения недостаточно для уверенного вывода о достижении цели.
• Работа вне наблюдаемых систем, неоднозначное авторство и пропущенные источники отмечаются как ограничения. Отсутствие свидетельств не приравнивается к нулю. При неполном покрытии публикуются известная часть и размер выборки; полный итог — «н/д».
• Изменение коэффициентов версионируется. Для сравнения когорт используются одинаковые правила либо явно показывается изменение метода; пересчёт сохраняет предыдущую версию отчёта.

В недельной сводке показываются оценённые часы и диапазон по всем N задачам и отдельно по S/H/C/P, число задач с достаточными данными и ограничения. Для S добавляются среднее и медиана центральных оценок часов на задачу. Общие затраты настройки, обучения и развития процесса показываются отдельно.

По H оценки до передачи и ручного продолжения в окне оценки когорты показываются раздельно. Если ручное продолжение не наблюдается, это пробел данных. Поздняя работа может отражаться в календарной сводке, но не возвращает задачу в S. Календарный TTM и рабочие часы ожидания ответа рассчитываются по событиям отдельно от оценки активного труда.

Исходы, качество, ресурсы и этапы

Уровень команды: показатели её процесса выполнения задач и работы агентов.

Эти показатели помогают выбрать управляющее воздействие. Их рассматривают совместно: изменение одной величины само по себе не доказывает причину проблемы.

Порядок разбора и выбор действий.

Исходы задач

Для итоговой когорты N = S + H + C + P. До отсечки вместо P учитывается U — ещё открытые задачи: N = S + H + C + U. В основном отчёте дополнительно показывается объединённое C+P, но составляющие сохраняются: отмена и затянувшийся процесс требуют разных действий.

Каждая задача имеет один исход. После принятой передачи выполнение относится к H, даже если позже люди завершили или отменили работу. Дальнейший результат не становится успехом агента S. Для повторного полноценного запуска того же объёма не создаётся новая запись ради улучшения статистики. Небольшая консультация или обычное ревью сами по себе не означают передачу; границу существенного ручного выполнения команда задаёт до Пилота.

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

При сложности для агента решение о помощи или передаче принимается до истечения окна оценки когорты; действуют ограничения доработок. Отметка «передать» без принявшего человека не спасает задачу от P.

Доли исходов = соответствующее число / N. При N = 0 доли не определены. Новые требования и существенное изменение объёма фиксируются отдельно; незавершённый прежний объём нельзя скрыть в новой задаче.

Замечания: три независимых распределения

По решённым задачам S отдельно считаются замечания: 1. К коду. 2. К автотестам. 3. По результатам тестирования человеком.

В каждом канале: 0 / 1 / 2 и более, дополнительно не проверено или нет данных / неприменимо. Сумма пяти категорий одного канала равна S. Каналы пересекаются: одна задача может иметь 0 замечаний к коду, 2 к тестам и 1 по человеческой проверке. Складывать эти распределения нельзя.

Единица — отдельный подтверждённый недостаток исходного результата, требующий исправления. Один комментарий с несколькими независимыми недостатками может содержать несколько замечаний. Повтор того же недостатка или ответ в его ветке не увеличивает счётчик; возврат после неудачного исправления отражается в циклах доработки. Уточнения без требуемого исправления, отозванные/необоснованные замечания и новый объём отделяются от замечаний к исходному результату.

В эти распределения входят замечания людей клиента и сопровождения при ревью предъявленного результата. Собственная отладка агентов и диагностические сообщения инструментов не считаются человеческими замечаниями автоматически. Если человек подтверждает найденный инструментом недостаток, он учитывается один раз в соответствующем канале.

Замечания и циклы доработки — разные показатели. В одном цикле могут быть несколько замечаний. Граница замечания и правила устранения дублей согласуются до Пилота и одинаково применяются ко всем когортам.

«Без замечаний» можно поставить только после фактической проверки соответствующим способом. Отсутствие ревью не означает идеальное качество. Неприменимость объясняется заранее: например, задача не затрагивала автотесты и правила потока не требовали их изменения. Если нужные тесты не написаны, это пробел или замечание.

Доли 0/1/2+ рассчитываются от проверенных применимых решённых задач своего канала. Число непроверенных и неприменимых показывается рядом. Указываются режим ревью и способ человеческого тестирования: собственные проверки, оценка доказательств или сочетание. При смене режима сравнение оговаривается.

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

Число циклов доработки задачи

Единица — один завершённый цикл «пакет замечаний → исправление → повторная проверка». Показатель — целое число таких циклов по задаче в окне наблюдения. Повторное сообщение о том же пакете и смена запуска агента счётчик не увеличивают; незавершённый цикл показывается отдельно. Для сравнения групп задач можно использовать медиану по исходным значениям с указанием числа наблюдений. Порядок доработок и передачи человеку.

Критичность замечаний

Условия повышения автономности.

Токены агента: вход, выход, кэш, день и ночь

Суммируются все вызовы по задачам когорты в окне оценки, включая повторные и неудачные попытки с фактическим usage. Общие эксперименты и настройка, не относимые к задачам, учитываются отдельно.

Для каждой модели/провайдера и версии тарифа показываются: - вход без кэша; - выход; - чтение из кэша; - запись в кэш, если выделена источником/тарифом; - разбиение каждого показателя на день и ночь; - при наличии тарифов — стоимость и валюта.

Схема источника должна быть известна. Если общий вход уже включает cached tokens, кэш не прибавляется к нему повторно; для разбивки выделяются непересекающиеся категории. Если источник не позволяет отличить запись/чтение кэша или общий вход, указываются исходные поля и ограничение, а не выдуманная детализация. Разные модели и тарифы не усредняются перед расчётом стоимости.

Границы дня/ночи и часовой пояс определяются правилами тарификации проекта. Рабочий календарь людей для этого не используется. Ночной дисконт применяется только по согласованному тарифу; до его появления показываются объёмы без обещания экономии.

Предпочтительно распределять расход по времени usage-событий/тарификации. Если доступна только итоговая запись длинного вызова, действует заранее выбранное правило отнесения, соответствующее биллингу; приближение явно отмечается. Неопределённые события остаются отдельной строкой. Отсутствие данных не равно нулю.

Стоимость = сумма объёмов непересекающихся категорий × соответствующий тариф с его единицей расчёта. Оценка выгоды ночного тарифа — разница со стоимостью тех же ночных объёмов по дневным ставкам той же модели; это не доказательство роста продуктивности.

Медианы этапов

Цель — по задержке сразу определить, к какой роли обращаться за управляющим действием. У каждого этапа ровно один ответственный. Для времени работы агента это ИИ-инженер; для человеческой работы — конкретная роль, которая выполняет действие. Организатор отчётности не подменяет ответственного за этап.

Отчёт строится по тем же недельным когортам. Для этапов по умолчанию используются календарные часы в зоне ответственности одной роли; рабочие часы реакции человека — отдельный показатель. Это не активные трудозатраты: учитываются очередь, ночь и ожидание действия этой роли. Время, когда дальнейшая работа передана другой роли, относится к её этапу.

Каталог этапов

Это стартовый набор, а не обязательная для всех проектов статусная модель. Проект выбирает нужные этапы и связывает их с реальными событиями, даже если в трекере нет соответствующего статуса.

Для M1 команда заранее определяет комплект полного результата. Если нужны несколько MR, учитывается готовность всего обязательного комплекта. При блокирующем обращении к человеку или DevOps интервал агента приостанавливается; после ответа или устранения блокера продолжается. Время ожидания записывается на роль адресата. Если агент продолжает другую работу параллельно, её подтверждённое время сохраняется — ожидание по одной ветке не останавливает всю задачу автоматически.

M2 и M2-Т начинаются с передачи готовой ревизии назначенному проверяющему. Для каждого проверяющего сохраняются его роль и события. Вердикт «требуются изменения» завершает раунд; исправление относится к M3, следующее предъявление открывает новое ревью. Если ревью проводит ИИ-инженер на PoC, для него создаётся отдельная строка с ответственным «ИИ-инженер». В одну медиану разные роли не объединяются. Merge может заменить отдельный вердикт только при подтверждённом выполнении ревью тем же ответственным; ожидание последующего merge относится к отдельному этапу.

Для тестирования точка начала определяется готовностью результата и передачей на проверку, а не самим фактом merge. Приёмку аналитиком, проверку человеком, работу агента и подготовку среды измеряют отдельными этапами с конкретной ролью. Тестирование до merge сохраняет свой реальный порядок. Отчёт с дефектами завершает проверку; циклы исправления не продлевают её до успешного результата.

При передаче работы между ролями граница подтверждается событием и ожидаемым действием. Для блокера со средой ответственным указывается DevOps клиента. Если невозможно восстановить, у какой роли находилась работа, этот интервал отмечается как неполнота данных и не попадает в медиану конкретной роли. Его длительность и количество показываются отдельно, а не исчезают из отчёта.

Расчёт медианы этапа

1. Отобрать задачи когорты, где этап применим и начался до отсечки. Управленческая диагностика использует не только S: завершённые интервалы H/C/P тоже помогают увидеть проблему процесса.
2. Восстановить интервалы по подтверждённым событиям и роли ответственного. Разделить интервалы при передаче работы другой роли; учесть паузы и возобновления. Для повторяющегося этапа и нескольких MR получить длительность на задачу: сумму непересекающихся интервалов одного этапа с одной ролью. Параллельные интервалы этой выборки объединить, чтобы не считать один час дважды.
3. В основной медиане этапа одна задача даёт одно наблюдение. Для M2 объединяются интервалы ревью кода, включая повторные; для M2-Т — только ревью автотестов; для M3 — только исправления агента во всех циклах. Ответственный каждой строки фиксируется в плане мониторинга. Диагностика «на MR» или «на цикл» допускается отдельно, с явным названием и знаменателем; её нельзя смешивать с медианой на задачу.
4. Посчитать медиану длительностей задач с завершённым этапом. При чётном числе — среднее двух центральных значений. Рядом показать число наблюдений, число применимых задач, открытых этапов, прерванных этапов и задач с неполными данными. Если у задачи остаётся открытый интервал этого этапа, она не считается завершённым наблюдением основной медианы.
5. Для открытых этапов показать накопленное время ответственной роли до момента среза, для итогового отчёта — до отсечки; хотя бы медиану и максимум. Время пауз с передачей другой роли не включается; во время такой паузы счётчик исходной роли не растёт. Отмена или передача не притворяется успешным завершением этапа: оборванный интервал показывается отдельно. Известные завершённые интервалы такой задачи можно анализировать отдельно с явной пометкой.

Повторное открытие этапа до отсечки обновляет его длительность и состояние; окно оценки когорты остаётся прежним. Если событий недостаточно, выводится «н/д» и причина. Нельзя закрывать интервал текущим временем, концом недели или сообщением агента без подтверждения факта.

Медианы этапов не складываются в TTM: разные задачи образуют разные выборки, этапы могут перекрываться, а медиана суммы не равна сумме медиан. Для точного разбора конкретной задачи строится её временная линия. Для накопленной медианы используются исходные длительности, а не среднее недельных медиан.

Среднее и медиана ожидания реакции человека

Единица наблюдения — завершённый интервал ожидания содержательной реакции на запрос агента, а не задача целиком.

• Начало: явный запрос доставлен назначенному адресату в согласованном канале и содержит понятное ожидаемое действие.
• Конец: получен содержательный ответ, решение или выполнено запрошенное действие, позволяющее продвинуть работу.
• Автоматическая квитанция, уведомление о прочтении и «посмотрю позже» ожидание не завершают.
• Напоминания об одном запросе не создают новые интервалы и не сбрасывают начало.
• Если возникает новый самостоятельный вопрос после ответа, это новый интервал.

Длительность — сумма пересечений интервала с рабочим календарём ответственного адресата: рабочие часы, часовой пояс, выходные и праздники, согласованные перерывы. Для очереди одной роли заранее задаётся её календарь. При передаче вопроса другой роли закрыть участок прежнего адресата как переданный и открыть участок нового; передача не считается содержательным ответом. Длительности переданных участков показываются отдельно по роли.

Пример: при графике пн–пт 09:00–18:00 без исключаемых перерывов запрос в пятницу 17:00 и ответ в понедельник 10:00 дают 2 рабочих часа. Праздничный понедельник изменит расчёт по календарю.

Среднее = сумма рабочих длительностей / число завершённых интервалов. Медиана — середина отсортированного ряда (для чётного числа — среднее двух центральных). Это интервальная статистика: задача с несколькими запросами даёт несколько наблюдений. Она не измеряет суммарную задержку задачи; параллельные ожидания нельзя просто складывать в её TTM.

Сводка строится по запросам задач когорты, доставленным в окне оценки когорты и завершённым до отсечки. Незавершённые запросы не попадают в среднее/медиану завершённых; рядом обязательны их количество и рабочий возраст (медиана/максимум), чтобы длительное молчание не скрывалось. Запросы, снятые без содержательного ответа, показываются отдельно и не записываются как нулевая реакция. Ответ после отсечки не меняет итоговую метрику реакции когорты.

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

Недельные когорты Пилота

Когорта — все задачи выбранного потока, впервые переданные агенту в работу с проработанными и согласованными требованиями в течение одной календарной недели. Момент передачи t0 — первое подтверждённое разрешение взять готовую задачу по маршруту агента: сообщение уполномоченного человека в чате либо переход в статус трекера при выполнении заданных условий выборки. В обоих случаях определены задача и согласованный объём/версия требований. Учитывается время этого разрешения, а не начало вычислений; ожидание запуска входит во время решения. Если разрешение продублировано вторым способом, сохраняются один t0 и одна задача когорты.

Подготовка требований, обсуждение идеи и черновой вызов агента для уточнения постановки не включают задачу в когорту реализации. Произвольный статус «В работе» или назначение агента не заменяют выбранный сигнал допуска. Для маршрута через трекер подтверждением служит именно переход в настроенный статус с нужными условиями, а для чатового — поручение в установленном канале. Если событие передачи или согласованная версия требований не найдены, агент показывает нераспределённый запуск как пробел данных; инженер уточняет факт по источникам, не назначает удобную неделю. Количество таких запусков обязательно показывается рядом со сводками.

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

До Пилота фиксируются календарь недель, год и даты когорты, часовой пояс, критерий готовности входных требований, критерий решения и конечная точка TTM. Все показатели задач относятся к неделе их передачи агенту, даже если ревью, тестирование или расход токенов произошли позже. Рекомендованное окно оценки когорты — неделя передачи плюс две полные следующие недели. Это не 14 дней от передачи каждой задачи.

Отсечка — точный момент начала недели 28 в часовом поясе проекта; учитываются события до него. Другое окно оценки когорты допускается по предварительной договорённости, не продлевается задним числом ради неудобных задач. Пока окно оценки когорты открыто, когорта предварительная; после отсечки — созревшая. Открытые когорты не смешиваются с итоговыми.

Когортная оценка эффекта применяется на Пилоте. На PoC проверяются возможности и качество; статистика эффекта не является обязательной.

Сопоставимость и итоговый вывод

До Пилота выбираются сопоставимые типы задач, исходная база, целевые значения, правила качества и достаточный объём данных. Историческая база с только успешными задачами не описывает доли передач, отмен и просрочек; это ограничение фиксируется либо собирается подходящая база.

Относительное снижение = (база − Пилот) / база × 100%, при базе > 0, одинаковых метрике, границах и способе отбора. Человеческие часы, календарный TTM, токены и реакция людей не сворачиваются в один показатель.

Для заданного снижения на r% при сопоставимом базовом значении B > 0 целевое значение равно B × (1 − r/100). Например, для медианы TTM база и целевое значение должны относиться к одной конечной точке и сопоставимым задачам. При отсутствии сопоставимой базы процент снижения не объявляется измеренным фактом; можно задать абсолютный ориентир или сначала собрать базу.

Для накопленного результата используют сопоставимые созревшие когорты. Числа и суммы складываются; доли считаются от суммарного знаменателя; средние взвешиваются по числу наблюдений. Медианы нельзя восстановить усреднением недельных медиан: нужен расчёт по исходным значениям в системе-источнике. Если доступны лишь сводки, накопленная медиана отмечается как недоступная. Это не требует новой ручной карточки каждой задачи.

Хорошее время S при высокой доле H/C/P не доказывает успех всего потока. Рядом всегда видны полный состав, качество, объём и полнота данных. Численные пороги и достаточность выборки согласуются для проекта заранее; новые критерии формальной самостоятельности не добавляются.

По каждой сводке указываются период, версия правил, дата среза, источник и пропуски данных. Поздно полученное событие, фактически случившееся до отсечки, допускает исправление с историей и основанием. Реально позднее решение или передача не является исправлением данных и не меняет P.

Перед выводом о достижении цели всегда показываются N и исходы, полнота оценок/часов/событий, число наблюдений медианы, открытые ожидания и существенные дефекты. Эти сведения сопровождают выбранные показатели и не могут быть отключены ради более красивого отчёта. Нельзя сравнивать скорость двух когорт, не проверив различия объёма, типов задач и режима проверки.

Пример итоговой когорты

В когорте 25 запущено 10 задач. К концу недели 27: S = 6, H = 2, C = 1, P = 1. Итого N = 10; решено 60%, передано 20%, отменено или просрочено 20% (10% + 10%).

По шести решённым задачам: - Код: 3 без замечаний, 2 с одним, 1 с двумя и более; сумма 6. - Автотесты: 2 без замечаний, 1 с одним, 1 с двумя и более, 2 неприменимы; сумма 6, знаменатель долей замечаний — 4. - Тестирование человеком: 4 без замечаний, 1 с одним, 1 с двумя и более; сумма 6.

В начале недели 28 публикуется эта сводка. Ручное завершение двух H на неделе 29 не превращает их в S; позднее решение P не меняет его категорию. Часы и расход всех десяти задач внутри окна оценки когорты остаются видны.

Допустим, оценки всех десяти задач известны: Vₙ = 160 идеальных часов, из них S — 96, H — 32, C — 16, P — 16. Оценённые трудозатраты людей в одинаковых границах: S — 36 часов, H — 20, C — 4, P — 8; всего 68. Это автоматически полученные оценки, а не табельные часы. Оценка экономии на S: 96 − 36 = 60 часов, или 62,5%. Консервативный эффект потока: 96 − 68 = 28 часов. Выражение 160 − 68 использовать нельзя: оно включает незавершённый агентом объём в выгоду.

Допустим, диапазон оценённых затрат S составляет 30–42 часа. При фиксированном Eₛ = 96 диапазон экономии — 54–66 часов, или 56,25–68,75%. Например, при завышении оценки ревью из-за включения генерируемых файлов поправка получает обоснование и новую версию расчёта.

TTM шести S равен 24, 36, 48, 48, 72 и 96 календарным часам: медиана — 48 часов, среднее — 54. Все числа в этом примере учебные; они не задают норму или целевые значения проекта.

Учёт затрат развития

Создание и отладка временных скриптов, поддерживаемых тестов и требований для конкретных задач входят в затраты этих задач. Общие инструменты, обучение и развитие инфраструктуры учитываются отдельно. Одна активность учитывается один раз. Рост числа тестов или текстов сам по себе не доказывает эффект.

Порядок рассмотрения итогов и подготовки решения — в гайде РП.

Показатели предприятия

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

Результат предприятия

Охват внедрением оценивается по двум событиям: подтверждённым GATE-02 и GATE-03. У обеих долей один состав команд области программы; команда, завершившая Пилот, входит в оба числителя, доли не складываются. Дополнительный критерий «регулярного применения» для этих показателей не вводится. По GATE-03 отдельно видно основание завершения: достигнутые цели или поддержанный план их достижения; факт завершения этапа не подменяет метрики эффекта.

Процесс предприятия

Для каждой доли публикуются числитель и знаменатель; при нулевом знаменателе — «н/д». Изменение области программы получает дату и основание. Отложенные, приостановленные и исключённые проекты показываются отдельно; наступивший срок оценки не исчезает из знаменателя из-за неудобного результата. Открытые внедрения до срока оценки не смешиваются с созревшими, рядом видны их число и возраст.

Баланс предприятия

Объединение результатов команд допускается при сопоставимых определениях, единицах и границах. Проценты улучшения разных продуктов не усредняются в общий эффект; медианы рассчитываются по исходным наблюдениям. Показатели затрат программы не меняют границы трудозатрат на производство ПО в показателях команд.

Подготовка сводки предприятия и работа с различиями проектов описаны в гайде офиса внедрения ИИ, оценка программы — в гайде масштабирования. Ритм и распределение ответственности остаются в этих гайдах.