Метрики разработки при агентах считают готовые задачи в проде, а не часы и коммиты

На /open показаны 34 коммита за 6 октября. На /services вечером 7 октября показаны 112 готовых задач в неделю. Это разные единицы и разные окна замера.

Темп /services рассчитан из влитых PR за последние 30 дней. PR обозначает пакет правок. Его можно влить, а страница так и не откроется.

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

Опубликованные 20–60 для команды из десяти являются оценкой страницы. Сопоставимого эксперимента нет: делить числа и обещать выигрыш клиенту нельзя.

Исследование SPACE, опубликованное в 2021 году, тоже отделяет активность от продуктивности. Число коммитов не показывает, решил ли разработчик нужную задачу.

Вопрос об эффекте ИИ в цифрах разобран отдельно. Здесь вопрос уже: какую единицу результата руководитель примет и сможет проверить?

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

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

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

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

На /open медиана 25 минут по 115 задачам относится к срезу 27 августа 2026. Ряд начинается с реплики владельца и заканчивается мержем.

Автономные ветки без реплики владельца исключены. Мерж не доказывает успешный выпуск. Эта медиана не обещает срок клиентского результата.

Руководителю нужен срок от согласованного запроса до приёмки в проде. Сохраните промежуточные даты: так видно, задачу долго делали или она ждала ответа и проверки.

В DORA отсчёт изменения начинается с коммита и заканчивается выпуском. DORA и ускорение разработки разобраны в соседней статье; очередь до коммита измеряйте отдельно.

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

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

Для доли возвратов выберите группу принятых задач и одинаковый срок наблюдения. Свежую группу нельзя сравнивать со старой, у которой уже успели проявиться ошибки.

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

Если замер сорвался, покажите «нет данных» и дату последнего успеха. Ноль ставят, когда замер состоялся, но ничего не нашёл.

В нашей машине это проверено поломками. Ниже показаны случаи, после которых изменили правило или проверку. Объём коммитов не сообщил бы руководителю, что произошло.

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

Определите готовность и соберите журнал задач. Иначе дашборд красиво повторит старую неоднозначность: задача на витрине снова окажется PR.

На разборе выберите задержку или возврат и измените правило. На следующем разборе повторите прежний замер: помогло ли изменение?

Это работа руководителя разработки при агентах. Если пока непонятно, кто принимает результат и отвечает за проверки, начните с теста для руководителя.

1. Считайте согласованную задачу после успешного выпуска и приёмки. PR и коммиты привяжите к ней как след работы.

2. Сохраняйте время запроса, работы, проверки, выпуска и приёмки. Незавершённые задачи показывайте рядом с завершёнными.

3. Читайте темп вместе с возвратами и стоимостью. Сравнивайте одинаковые типы задач, определения готовности и окна наблюдения.

4. Отличайте отсутствие данных от нуля. По итогам разбора меняйте одно правило и проверяйте, помогло ли оно на следующем замере.