# Метрики SDLC с ИИ должны измерять принятые изменения

> Метрики SDLC с ИИ должны учитывать принятые изменения, глубину ревью, переделки, стабильность и стоимость поставки с агентами.

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

Для этого не нужно отказываться от всех показателей поставки ПО. Нужно отделить поток от приемки, а приемку от успеха в продакшене. Я видел, как команды объявляли о резком росте продуктивности из-за удвоения числа слияний, а затем месяц разбирали сгенерированные изменения, которых никто толком не понял. Дашборд точно показывал активность, но неверно описывал поставку.

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

## Velocity измеряет договоренность о планировании, а не поставку

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

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

То же возражение относится к коммитам, пул-реквестам, сессиям агентов, промптам, токенам и доле принятого кода. Это показатели активности или данные для диагностики. Они объясняют стоимость и процесс, но не доказывают полезную поставку. Им место на операционном экране разработки, а не в материалах для совета директоров.

На уровне руководства замените velocity четырьмя вопросами:

- Дошло ли до продакшена изменение, связанное с клиентом, выручкой, риском или операционной целью?
- Сколько времени заняла принятая работа от обязательства ее выполнить до подтвержденного использования?
- Какая доля выпущенной работы вызвала немедленный сбой или позднюю переделку?
- Снизились ли стоимость и затраты человеческого внимания на одно принятое изменение?

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

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

## DORA по-прежнему измеряет систему поставки

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

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

Я бы добавил к исходным данным три среза, не создавая отдельную оценку «AI DORA»:

- Сервис или продуктовая область, поскольку зрелый API и новое мобильное приложение имеют разные профили риска.
- Класс риска изменения, основанный на затронутых компонентах и поведении, а не только на размере diff.
- Режим работы: код написал человек, человеку помогал ИИ или работу выполнил агент. Его нужно фиксировать для каждого изменения.

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

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

У этих показателей остается слепая зона. Они показывают, что изменение прошло безопасно, но не отвечают, стоило ли его делать. Свяжите каждое изменение в продакшене с целью и событием проверки. Поначалу связь может быть неполной. Явная категория «результат неизвестен» честнее и полезнее, чем притворство, будто все развертывания равноценны.

## Принятое изменение заменяет velocity

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

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

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

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

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

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

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

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

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

## Глубину ревью подтверждают свидетельства, а не комментарии

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

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

Измеряйте ревью через покрытие рисков. Классифицируйте каждое изменение по поведению, на которое оно может повлиять: авторизация, движение денег, разрушительные операции с данными, совместимость публичного API, приватность, конфигурация развертывания или обычная логика приложения. Для каждого класса нужны свои свидетельства. Изменение авторизации может требовать сценария угрозы, негативных тестов и ревью владельца этой границы. Изменение текста не должно ждать той же церемонии.

К полезным сигналам глубины ревью относятся:

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

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

Качество выборки тоже имеет значение. Раз в неделю старший инженер должен изучать небольшую случайную выборку изменений с участием агента и отвечать на конкретные вопросы. Соответствовало ли изменение задаче? Проверяли ли тесты поведение при сбоях? Мог ли проверяющий объяснить затронутый инвариант? Доказала ли проверка в продакшене заявленный результат? Разбирайте расхождения между проверяющими. Это ближе к аудиторской выборке, чем к оценке сотрудников.

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

## Единая модель событий связывает намерение с продакшеном

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

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

Этого компактного контракта достаточно для расчета первых полезных трендов:

```json
{
  "change_id": "chg_01J...",
  "objective_id": "obj_retention_4",
  "service": "billing-api",
  "work_mode": "agent_executed",
  "risk_classes": ["money_movement", "data_migration"],
  "events": [
    {"type": "committed", "at": "2026-07-01T09:12:00Z"},
    {"type": "review_evidence_passed", "at": "2026-07-01T14:05:00Z", "policy": "payments-v3"},
    {"type": "deployed", "at": "2026-07-02T08:30:00Z", "deployment_id": "dep_8841"},
    {"type": "outcome_verified", "at": "2026-07-09T08:30:00Z", "check": "invoice_error_guardrail"}
  ]
}
```

Четыре детали реализации защищают от ложных выводов. Во-первых, `work_mode` должен описывать способ создания финального изменения, а не сам факт открытия инструмента ИИ в течение недели. Во-вторых, разрешите смешанную атрибуцию, когда вклад человека и агента нельзя разделить, но закрепите правило в документации. В-третьих, версионируйте политику риска, чтобы историческое покрытие не менялось вместе с требованиями. В-четвертых, фиксируйте коммит, который прошел финальное ревью, чтобы успешный тест старого кода не удовлетворял условию.

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

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

## Быстрые пул-реквесты могут скрывать медленную компанию

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

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

Полная трассировка рассказывает другую историю. Агенты сократили время от первого коммита до открытия пул-реквеста. Очередь ревью тоже уменьшилась, поскольку проверяющие быстро одобряли diff, который выглядел небольшим. Время от обязательства до продакшена улучшилось, но время до подтвержденного использования выросло из-за провала проверок при развертывании. Выход годных развертываний упал, немедленные переделки выросли, а человеческого внимания на принятое изменение стало уходить больше. Ограничение переместилось из реализации в постановку и проверку.

Записи ревью объясняют причину. В пул-реквестах с миграциями были модульные тесты счастливого пути, но политика риска не требовала проверять повторные события или частичный откат. Проверяющие смотрели синтаксис и статус тестов, затем одобряли изменения. Никто не записал инвариант: одно событие счета должно создать не более одного списания. Агенты реализовали ровно то узкое поведение, которое у них запросили.

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

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

## Дашборд для совета директоров помещается на одном экране

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

В первом ряду разместите пять карточек:

- Результат: принятые изменения по бизнес-целям рядом с выходом годных развертываний.
- Поток: медианное время от обязательства до подтвержденного использования рядом с 85-м процентилем.
- Стабильность: доля неудачных изменений рядом со временем восстановления и долей повторных развертываний.
- Риск: изменения высокого риска без обязательных свидетельств рядом с самым старым неустраненным риском.
- Экономика: человеческое внимание и стоимость инструментов на принятое изменение рядом с общей стоимостью исправлений.

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

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

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

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

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

## Внедрение метрик не должно создавать систему слежки

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

Практическое внедрение состоит из четырех этапов:

1. Опишите контракты метрик и вручную разберите двадцать недавних изменений. Устраните разногласия о моменте обязательства, приемке, переделке и риске до автоматизации.
2. Настройте идентификаторы и события, затем публикуйте полноту данных и долю неизвестных значений. Не сравнивайте эффективность, пока соединения ненадежны.
3. Несколько циклов поставки показывайте дашборд только руководителям разработки и продукта. Каждый неожиданный график сверяйте с реальными изменениями и инцидентами.
4. Передайте совету директоров стабильное представление с пятью карточками, определениями и двумя или тремя решениями, на которые повлияли данные. Диагностические показатели оставьте для операционного разбора.

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

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

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

## Метриками должно владеть операционное руководство

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

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

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

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

Во время Team & AI Audit я использую эти свидетельства, чтобы найти места, где мощность агентов снимет ограничение, и места, где она просто переполнит следующую очередь. Цель не в установке моего любимого дашборда. Нужно принимать решения о штате, контролях и инструментах на основе одних и тех же фактов поставки.

Первое обсуждение с советом директоров не должно начинаться с вопроса «Сколько кода написал ИИ?». Спросите, какие проверенные результаты дошли до клиентов, сколько внимания они потребовали, что сломалось и какие проверки риска действительно провели. Когда ответы приходят из связанных событий, а не из историй, скоростью агентов можно управлять. До этого растущий график velocity доказывает лишь поступление большего объема работы в трубу.