Вы измеряете ROI от AI неправильно: метрики, которые реально показывают эффект для команды

Вы купили команде Copilot или Claude, а через три месяца финансовый директор присылает простой вопрос: «Оно того стоит?» И вы понимаете, что ответа у вас нет. Открываете дашборд, который даёт вендор, и видите цифры вроде «принято 8 200 предложений» или «сгенерировано 340 тысяч строк кода». Звучит внушительно. Не значит ничего.

Вендор показал мне, что команда приняла 71% предложений. Я спросил: а мы доставляем быстрее? Тишина. — engineering manager на одном из моих тренингов

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

Почему LOC и acceptance rate вводят в заблуждение

Количество сгенерированных строк кода — худшая метрика, какую можно выбрать. Больше кода — не значит лучше кода, часто наоборот. AI с радостью сгенерирует 200 строк шаблонного кода там, где сеньор написал бы 20 строк элегантного решения. Когда вы поощряете объём, вы поощряете раздувание кодовой базы, больше площади для багов и больше кода для поддержки. Строки кода как метрика продуктивности были глупостью ещё в 90-е; с AI они опасны.

Acceptance rate — процент принятых разработчиком предложений — звучит умнее, но измеряет готовность нажать Tab, а не качество результата. Разработчик может весь день принимать автодополнение, а потом час чинить то, что принял. Высокий acceptance rate прекрасно сосуществует с падающей продуктивностью. Вы измеряете, как часто люди говорят AI «да», а не то, помогло ли это.

Что измерять вместо этого: результаты, а не активность

У хороших метрик есть одно общее свойство: они измеряют, что происходит с работой, а не сколько её произвёл AI. Вот те, что работают на практике.

• Cycle time — от первого коммита до деплоя в продакшен. Самый прямой сигнал того, доставляет ли команда быстрее.
• Время code review — от открытия PR до мёрджа. Именно здесь AI часто помогает больше всего (pre-review, генерация описания PR, объяснение диффа).
• Time-to-first-PR для новичков — сколько времени новому человеку нужно, чтобы отправить первый осмысленный PR. Хороший индикатор того, ускоряет ли AI онбординг.
• Частота инцидентов и bug rate — защита от того, чтобы скорость шла в ущерб качеству. Ключевое: отслеживайте это вместе с cycle time, а не отдельно.
• Developer-reported friction — короткий регулярный вопрос команде: «Где AI сэкономил вам время в этом спринте, а где замедлил?»

Обратите внимание: ни одна из них не берётся из дашборда AI-инструмента. Cycle time, время ревью и bug rate уже есть в вашей истории Git, в Jira или Linear. Вам не нужно покупать новый инструмент — достаточно смотреть на данные, которые вы уже собираете.

Самая сильная пара — cycle time + bug rate. Когда cycle time падает, а bug rate остаётся ровным или тоже падает, у вас есть реальное доказательство, что AI помогает. Когда cycle time падает, а баги взлетают, команда просто быстрее выкатывает некачественный код — а это хуже, чем ничего.

Baseline: без цифры «до» у вас нет ничего

Самая частая ошибка: компания внедряет AI и только потом начинает измерять. Тогда ей не с чем сравнивать. «Cycle time — 3,1 дня» — это не информация, это цифра без контекста. «Cycle time упал с 4,8 до 3,1 дня за квартал» — это информация, которую вы защитите перед руководством.

Прежде чем разворачивать AI широко, соберите baseline за 2–4 недели. Большинство этих метрик можно вытащить задним числом из Git и трекера задач, так что baseline часто удаётся восстановить и постфактум — посчитайте cycle time и время ревью за последний месяц до того, как команда начала реально пользоваться AI.

# Lightweight baseline from Git (before AI rollout)

## Cycle time (commit -> deploy)
- Median over last 4 weeks: ___ days

## Review time (PR open -> merge)
- Median over last 4 weeks: ___ hours

## Bug rate
- Production bugs / month: ___

## Onboarding
- Time-to-first-PR of last new hire: ___ days

=> Measure the same metrics in a quarter and compare.

Не игнорируйте качественные сигналы

Не всё помещается в график. Некоторые из самых ценных сигналов — качественные, и они приходят от регулярных вопросов команде. На ретроспективе задайте два вопроса: «Где AI помог вам больше всего в этом спринте?» и «Где он замедлил вас или завёл в тупик?»

Ответы расскажут то, чего не видно в цифрах: что AI отлично справляется с тестами, но ужасен на вашем legacy-модуле; что джуниорам он экономит часы, а сеньоров иногда замедляет; что после внедрения AI code review люди меньше выгорают на скучных PR. Это реальные эффекты, которые cycle time не уловит. Отслеживайте и простой сентимент — «не хотел бы от этого отказываться» — сигнал сильнее любого процента.

Лёгкий план измерения на один квартал

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

• Неделя 0: Вытащите baseline из Git и трекера задач — cycle time, время ревью, bug rate, time-to-first-PR. Запишите цифры.
• Недели 1–2: Внедряйте AI целенаправленно (а не письмом «теперь мы используем AI»), дайте людям время и обучение.
• Каждый спринт: Два вопроса про AI на ретроспективе. Записывайте, что говорят люди.
• Неделя 12: Измерьте те же метрики, что и в baseline. Сравните. Добавьте качественное резюме из ретроспектив.
• Решите: Какие кейсы явно работают (масштабируйте их), какие нет (перестаньте их проталкивать), где нужно больше обучения.

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