# Блок 11. Как измерять эффект от внедрения

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 11 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/metriki-dora-baseline/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 15 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

> Эффект от ИИ, который не измерен до старта, через квартал превращается в спор мнений, и выигрывает в нём не тот, кто прав, а тот, кто выше по должности.

Это ключевой блок всего курса. Всё, что было до него, объясняло, зачем и как внедрять, а всё, что идёт после, рассказывает о том, что мешает. Этот блок о том, как узнать, сработало ли внедрение. Без него внедрение заканчивается спором «нам кажется, что стало быстрее» против «а нам кажется, что нет», в котором побеждает тот, у кого выше должность.

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

## Ситуация: Финансовый директор хочет «было» и «стало»

**Финансовый директор · среда, 11:20:** Пилот одобрили, стартуете через 2 недели. Но объясни: через квартал как я пойму, что деньги не ушли в никуда? Мне нужны цифра «было» и цифра «стало», ответ «команде понравилось» меня не устроит.

Что известно:

- Метрики DORA никто не считает: данные разбросаны по 3 системам.
- Стоимость единицы поставки финансовый директор посчитает сама по своей таблице расходов.
- В том же квартале планируют автоматизировать регресс и нанять 6 человек.
- У инструмента есть панель поставщика: активные пользователи, принятые предложения, токены.

**Что вы ответите финансовому директору?**

- **A. Опрос до и после.** Опросить команду до пилота и через квартал: насколько быстрее и удобнее работать. Готово за день, пилот стартует вовремя. Финансовый директор получит оценки людей, а не данные систем.
- **B. Сначала снять baseline.** Перенести старт на месяц: настроить сбор, снять DORA, стоимость единицы поставки, дефекты и онбординг за 3 месяца, оставить 2 команды без ИИ для сравнения. Цифры будут сравнимы, но генеральный будет недоволен задержкой.
- **C. Взять панель поставщика.** Готовые цифры из панели инструмента: активные пользователи, доля принятых предложений, расход токенов. Они появятся с первого дня и без ручной работы, но описывают работу инструмента, а не поставку.

## Что происходит через квартал

Цифры условные: они показывают направление, но не величину. О том, что делать, когда замер показал узкое место, – в [блоке 12](/ai-cto/slozhnosti-vnedreniya-ii/).

### Вариант A: 8 из 10 «стали быстрее»

Пилот стартовал вовремя, а через квартал опрос показал то, что хотелось: 8 инженеров из 10 говорят, что работать стало быстрее, в среднем на четверть. Финансовый директор принесла свою таблицу: стоимость единицы поставки выросла на 9 процентов, потому что добавились токены, а деплоев осталось столько же. Из истории репозитория вы восстановили, что пул-реквесты стали заметно крупнее, а остальные данные сравнить не с чем. Мнение команды оказалось против таблицы, а такой спор выигрывают данные.

| Метрика | Было | Стало |
| --- | --- | --- |
| Ощущаемое ускорение (опрос команды) | нет данных | +25% |
| Стоимость единицы поставки (все расходы на разработку / число деплоев) | 100 | 109 |
| Частота деплоев (метрика DORA) | 14 в неделю (из таблицы финдира) | 14 в неделю |
| Размер пул-реквестов (восстановлен из истории репозитория) | 100 | 148 |
| Доля сбойных изменений (метрика DORA) | не снимали | 5,2% |

**Вердикт:** От вас ждали цифры, а вы принесли ощущения. Теперь мнение команды выглядит как оправдание.

### Вариант B: Эффект, который оказался не от ИИ

Месяц ушёл на то, чтобы свести данные из 3 систем в одну таблицу, а генеральный дважды спросил, где пилот. Зато baseline за 3 месяца был, а 2 команды работали без ИИ. Через квартал время от коммита до прода сократилось у всех, у пилотных команд и у контрольных: так сработала автоматизация регресса. От ИИ остались ускорившийся онбординг и выросшее ревью. Стоимость единицы поставки почти не изменилась, но финансовый директор знает почему.

| Метрика | Было | Стало |
| --- | --- | --- |
| Время от коммита до прода (метрика DORA, пилот и контроль одинаково) | 6 дн | 5 дн |
| Стоимость единицы поставки (все расходы на разработку / число деплоев) | 100 | 98 |
| Время ревью (медиана по пул-реквесту, пилот) | 1,1 дн | 1,6 дн |
| Доля сбойных изменений (метрика DORA, пилот) | 4,0% | 4,3% |
| Дней до первого смерженного изменения (онбординг, пилот) | 38 | 30 |

**Вердикт:** Красивой цифры нет, зато есть достоверная. Следующий шаг понятен: чинить ревью, а не покупать новые лицензии.

### Вариант C: Отчёт, в котором нет ответа

Цифры появились с первого дня и всё время росли: через квартал инструментом пользуются 9 инженеров из 10, принимают почти треть предложений, расход токенов вырос в 3 раза. Финансовый директор прочитала отчёт и спросила одно: а поставка-то ускорилась? Ответить нечем, потому что до старта вы ничего не сняли. Вдобавок половину токенов команды тратит один инженер на длинных агентных сессиях, а вы не знаете, лучший он или самый расточительный.

| Метрика | Было | Стало |
| --- | --- | --- |
| Доля активных пользователей (по данным инструмента) | 0% | 90% |
| Доля принятых предложений (панель поставщика) | нет данных | 31% |
| Расход токенов на инженера (к первому месяцу пилота) | 100 | 300 |
| Стоимость единицы поставки (по расчёту финансового директора) | 100 | 107 |
| Время от коммита до прода (метрика DORA) | не снимали | 5,8 дн |

**Вердикт:** Вас спрашивали об эффекте, а вы отчитались о внедрении. Финансовый директор заметила разницу первой.

## Что измерять и как отделить эффект ИИ

### Baseline: точка отсчёта

Baseline означает измеренное состояние до изменений. Только с ним можно потом сказать «стало лучше на столько-то». Снять baseline нужно до пилота, но именно это упускают чаще всего: команда начинает внедрять, через квартал хочет показать результат, а сравнивать ей уже не с чем.

Обязательный минимум для отчёта – 5 метрик: частота деплоев, время от коммита до прода, доля сбойных изменений (все 3 из [DORA](https://dora.dev/guides/dora-metrics/), о ней ниже), стоимость единицы поставки и число дефектов на проде. Если данные есть, добавьте остальные метрики DORA, время от постановки задачи до выкатки, время ревью и время онбординга нового сотрудника. Снимайте данные за 3 месяца до старта, чтобы сгладить случайные колебания. Если данных нет, сначала настройте сбор и только потом начинайте пилот, даже если это отложит его на месяц.

**Корпорация:** baseline собирается из трекера задач, системы деплоя и баг-трекера за 3 месяца и по всем командам, участвующим в пилоте. Сам расчёт – несколько дней работы платформенной команды или аналитика. Но если данные лежат в 3 системах, а выгрузки делают по заявкам, сбор займёт до месяца: заказывайте выгрузки до начала фазы 0 ([блок 14](/ai-cto/pilot-90-dney/)).

**Небольшая компания:** достаточно таблицы на 8 строк, заполненной из истории коммитов, тегов релизов и списка инцидентов в чате. Полдня работы технического директора. Главное – сделать это до старта, потом восстановить уже будет сложнее.

#### Пример: как выглядит снятый baseline

Банковская команда из 12 инженеров, сервис заявок на кредиты, данные за 3 месяца до пилота. Так выглядит таблица, которую нужно иметь до первого дня внедрения; числа условные, но типичные для корпоративного монолита.

| Метрика | Откуда берётся | Значение за квартал |
| --- | --- | --- |
| Частота деплоев | CI/CD, число выкаток на прод | 2 в неделю (26 за квартал) |
| Время от коммита до прода | Git + CI/CD, медиана | 9 рабочих дней |
| Доля сбойных изменений | инциденты, привязанные к выкатке / все выкатки | 3 из 26, то есть 11,5% |
| Стоимость единицы поставки | расходы на команду / число деплоев | 180 000 $ / 26 = около 6 900 $ |
| Дефектов на проде | баг-трекер, с пометкой «найдено на проде» | 14 |
| TTM: от постановки задачи до прода | трекер задач, медиана | 34 рабочих дня |
| Время ревью | Git, от открытия пул-реквеста до мержа, медиана | 2,1 дня |
| Онбординг | дни до первого смерженного пул-реквеста, по 2 новичкам за полгода | 41 и 37 дней |

Первые 5 строк – обязательный минимум, последние 3 – дополнительные метрики, для которых нашлись данные.

Что важно в этой таблице. Каждая строка берётся из системы, а не из опроса: если какую-то метрику неоткуда взять, это первая задача до пилота. Медиана вместо среднего везде, где есть выбросы: одна застрявшая на полгода задача не должна искажать TTM. Стоимость единицы поставки считается по деплоям, потому что их считает CI/CD, а не человек. И строка про онбординг показывает, что данных мало (2 человека), значит, выводы по ней через квартал будут слабыми, и это нужно сказать заранее.

Документ этого блока – такая же таблица с вашими числами. Через квартал добавьте к ней колонку «стало» и посчитайте изменение в процентах.

### Метрики DORA

Исследовательская программа [DORA](https://dora.dev/guides/dora-metrics/) (DevOps Research and Assessment) изучает эффективность поставки с 2014 года, а её метрики стали отраслевым стандартом. Сейчас метрик 5, набор менялся по годам ([история изменений](https://dora.dev/guides/dora-metrics/history/)). Скорость поставки описывают 3: частота деплоев (как часто вы выкатываете на прод), время от коммита до прода (lead time for changes) и время восстановления после сбойного деплоя. Нестабильность описывают 2: доля сбойных изменений (какой процент выкаток приводит к инциденту) и доля внеплановых выкаток – тех, что пришлось сделать из-за инцидента на проде (deployment rework rate). Пятую метрику DORA добавила в 2024 году.

Почему именно они? 3 метрики измеряют скорость, 2 – нестабильность, поэтому они уравновешивают друг друга. Благодаря этому в данных DORA видно то, чего по ощущениям не поймаешь: [в 2024 году](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) ИИ был связан с ростом нестабильности на 7,2%, а [в 2025-м](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) он был связан с ростом скорости при сохранении роста нестабильности. Если вы смотрите только на скорость, вы увидите успех там, где накапливается долг.

### TTM: время до рынка

TTM (time to market) означает время от идеи до момента, когда она стала доступна клиентам. Эту метрику, в отличие от частоты деплоев, понимает генеральный директор. Она шире, чем [метрики DORA](https://dora.dev/guides/dora-metrics/): включает согласования, аналитику, тестирование, релизный цикл.

Для внедрения ИИ метрика TTM важна тем, что показывает, где узкое место на самом деле. Если генерация кода ускорилась в 2 раза, а TTM осталось прежним, значит, время съедают согласования, ревью или регресс. Тогда внедрять дальше нужно там, где теряется время, вместо генерации.

### Стоимость единицы поставки

В [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/) я описал метрику Amazon [CTS-SW](https://www.amazon.science/blog/measuring-the-effectiveness-of-software-development-tools-and-practices): сколько стоит одна единица софта, доведённая до клиента. Amazon выбрал за единицу деплой, потому что он подходит их сервисной архитектуре. Я тоже советую деплой: «фичу» все считают по-разному, а деплой считается автоматически. Пул-реквест и коммит как единица не годятся: с ИИ их становится больше сами по себе, и стоимость единицы «падает» без всякого эффекта. Разделите все расходы на разработку (люди, инфраструктура, ИИ) на число таких единиц за период и смотрите динамику.

Это метрика для финансового директора. Если с ИИ стоимость единицы поставки снизилась, внедрение окупается. Если она выросла (расходы на токены добавились, а поставка не ускорилась), внедрение не окупается, что бы ни подсказывали ощущения.

Пример на числах из baseline выше. До пилота: 180 000 $ в квартал на команду и 26 деплоев, стоимость единицы около 6 900 $. После квартала пилота расходы выросли до 191 520 $. Добавились подписки (12 × 40 $ × 3 = 1 440 $), токены (12 × 200 $ × 3 = 7 200 $) и обучение (12 × 8 часов × 30 $ = 2 880 $) – ставки как в [блоке 04](/ai-cto/stoimost-tokenov-okupaemost/). Деплоев стало 31. Стоимость единицы 191 520 / 31 = около 6 180 $, то есть примерно минус 11%. Это и есть цифра для финансового директора, и она сильнее любого «инженеры говорят, что стало быстрее». А если бы деплоев осталось 26, стоимость единицы выросла бы до 7 366 $, и это тоже прямой ответ: за квартал внедрение не окупилось, смотрим, где узкое место.

Учтите шум. 26 деплоев за квартал – небольшое число: даже без всяких изменений оно колеблется от квартала к кварталу примерно на ±5, то есть на ±20%. Рост с 26 до 31 в этот разброс укладывается. Поэтому давайте финансовому директору цифру с интервалом, а вывод делайте по 2–3 кварталам или по нескольким командам сразу. Если релизы выходят по расписанию (релизные окна), число деплоев от ИИ почти не зависит. Тогда стоимость на деплой эффекта не покажет: смотрите время от коммита до прода и TTM по этапам.

### Метрики ИИ

Отдельная группа метрик описывает само использование. В неё входят доля активных пользователей (сколько инженеров реально используют инструмент, выданная лицензия ещё ничего не значит), доля принятых предложений (сколько сгенерированного кода остаётся без правок; для агентов точнее доля агентских пул-реквестов, смерженных без доработки), доля ИИ-кода в смерженных изменениях (по данным [DX](https://getdx.com/report/ai-assisted-engineering-q1-impact-report/), около 30% в начале 2026 года и около 50% по медиане [во втором квартале](https://getdx.com/blog/ai-authored-code-has-nearly-doubled/)), расход токенов на инженера и на единицу поставки.

Эти метрики нужны для диагностики, отчёт о внедрении на них строить нельзя. Низкая доля активных пользователей при купленных лицензиях говорит о сопротивлении ([блок 13](/ai-cto/komanda-roli-obuchenie/)), а высокий расход токенов при низкой доле принятого кода говорит о том, что агенты тратят деньги на переделки.

### Метрики качества

Скорость без качества превращается в долг. Снимайте число дефектов на проде на единицу поставки, долю сбойных изменений (из [DORA](https://dora.dev/guides/dora-metrics/)), время ревью, размер пул-реквестов, покрытие тестами (с оговоркой из [блока 07](/ai-cto/ii-v-programmirovanii/): процент покрытия сам по себе мало значит).

Данные показывают, куда смотреть: по данным [Faros AI](https://www.faros.ai/blog/ai-software-engineering) с ИИ размер пул-реквестов вырос на 154%, время ревью на 91%, число багов на 9%; по данным [DX](https://getdx.com/report/ai-assisted-engineering-q1-impact-report/) у части команд дефекты выросли на 50%. Если эти метрики у вас растут, вы повторяете типовой сценарий. Тогда нужно сдерживать размер изменений и усиливать автопроверки, радоваться скорости рано.

### Реальное использование и расход токенов

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

### Реальные данные вместо мнений

[Исследование METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) служит главным предостережением этого курса. 16 опытных разработчиков работали с ИИ на 19% медленнее, но при этом были уверены, что ускорились на 20%. Разрыв между ощущением и фактом составил около 40 процентных пунктов, причём у профессионалов, которые внимательно следили за экспериментом.

**Что изменилось к 2026 году.** В феврале 2026 METR [опубликовала обновление](https://metr.org/blog/2026-02-24-uplift-update/) по второму исследованию (с августа 2025): 57 разработчиков, 143 репозитория, больше 800 задач, медианный опыт 10 лет, среди инструментов – Claude Code и Codex. Сырые цифры развернулись: у 10 разработчиков из первого исследования время на задачу с ИИ меньше на 18% (доверительный интервал от −38% до +9%), у 47 новых – на 4% (от −15% до +9%). Оба интервала включают ноль, поэтому METR называет это «очень слабым свидетельством» ускорения и считает оценку заниженной.

Причина важнее цифр: исследование перестало работать. Разработчики, которые не хотят работать без ИИ, отказывались участвовать; 30–50% участников признались, что не подавали часть задач, потому что не хотели делать их вручную; 1 участник не выполнил ни одной задачи из условия «без ИИ».

Из этого 3 вывода для вашего пилота. Первый: эффект за год сместился от замедления к вероятному ускорению, но доказанной цифры всё ещё нет, и брать «+18%» в обоснование нельзя. Второй: чем шире ИИ внедрён, тем труднее его измерить, потому что контрольная группа разбегается; это главный аргумент снять baseline до старта, пока сравнивать ещё есть с чем. Третий: пилот из добровольцев измеряет не ИИ, а добровольцев; как собирать группу, разобрано в [блоке 13](/ai-cto/komanda-roli-obuchenie/).

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

### Отделение эффекта ИИ от других изменений

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

Есть несколько способов разделить эффект, от простого к сложному. Контрольная группа: часть команд внедряет ИИ, другая часть работает без него, остальные изменения одинаковы для всех. Это лучший способ. На той же идее построены эксперименты [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) и [Management Science](https://pubsonline.informs.org/doi/fpi/10.1287/mnsc.2025.00535), только там случайно делят не команды: в METR – задачи (с ИИ или без), в Management Science – разработчиков, которым дают доступ к ассистенту. Оговорка: 2 контрольные команды против 1–2 пилотных – это сравнение почти 1 с 1, и случайная разница между командами может оказаться больше эффекта. Поэтому сравнивают не значения, а изменения: насколько метрика сдвинулась у пилота минус насколько у контроля («разница разниц»). Разнесение по времени: сначала одно изменение, замер, потом другое. Декомпозиция: смотреть, на каком этапе сократилось время. Если ускорился регресс, а генерация кода осталась прежней, эффект дала автоматизация, ИИ здесь ни при чём.

#### Пример: как декомпозиция находит настоящую причину

Команда за квартал сократила время от постановки задачи до прода с 34 до 27 рабочих дней, на 20%. В тот же квартал она внедрила ИИ-ассистент и автоматизировала регрессионное тестирование. Вопрос финансового директора: сколько из этих 7 дней дал ИИ?

Декомпозиция – разложить 34 дня по этапам и посмотреть, какой из них сократился:

| Этап | Было, дней | Стало, дней | Что менялось на этапе |
| --- | --- | --- | --- |
| Анализ и постановка | 6 | 6 | ничего |
| Разработка | 10 | 9 | ИИ-ассистент |
| Ревью | 3 | 3,5 | ИИ-ассистент (пул-реквесты стали крупнее) |
| Регресс и приёмка | 10 | 4 | автоматизация регресса |
| Ожидание релизного окна | 5 | 4,5 | ничего (случайность) |
| Итого | 34 | 27 |  |

Из 7 сэкономленных дней 6 дала автоматизация регресса, а ИИ в сумме дал полдня: день на разработке минус полдня на ревью. Если бы команда отчиталась «ИИ ускорил поставку на 20%», это было бы неправдой, которая вскроется на следующем бюджете. Точный отчёт: «регресс дал 6 дней, ИИ пока нейтрален, потому что упёрся в ревью, и следующий квартал мы чиним ревью».

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

### Связка целей блока 02 с метриками

Замкнём круг: в [блоке 02](/ai-cto/zachem-vnedryat-ii/) было 8 причин внедрять, а ниже показано, какая метрика проверяет каждую.

| Причина из [блока 02](/ai-cto/zachem-vnedryat-ii/) | Что измерять |
| --- | --- |
| Снижение затрат | Стоимость единицы поставки, расход токенов на единицу |
| Скорость вывода функционала | [Метрики DORA](https://dora.dev/guides/dora-metrics/) (частота деплоев, lead time), TTM |
| Способность делать ИИ-функционал | Доля команд, работающих с агентами; число выпущенных ИИ-фич |
| Качество кода и документации | Дефекты на проде, доля сбойных изменений, актуальность документации |
| Работа с легаси | Число закрытых миграций и обновлений, доля принятых изменений |
| Онбординг | Время до первого смерженного изменения у нового сотрудника |
| Найм и удержание | Отток инженеров, доля офферов, принятых кандидатами |
| Контроль теневого использования | Доля использования через корпоративные инструменты (по данным инструмента) |

Если для какой-то из ваших целей метрики в таблице нет, значит, цель сформулирована так, что её нельзя проверить, поэтому её стоит переформулировать до старта.

### Источники

- [DORA, описание метрик](https://dora.dev/guides/dora-metrics/)
- [DORA 2024](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report)
- [DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [Amazon Science, метрика CTS-SW](https://www.amazon.science/blog/measuring-the-effectiveness-of-software-development-tools-and-practices)
- [METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [Cui, Demirer и др., Management Science, 2025](https://pubsonline.informs.org/doi/fpi/10.1287/mnsc.2025.00535)
- [Faros AI, AI Productivity Paradox, июль 2025](https://www.faros.ai/blog/ai-software-engineering)
- [DX, отчёт за 1 квартал 2026](https://getdx.com/report/ai-assisted-engineering-q1-impact-report/)
- [DX, доля ИИ-кода, 2 квартал 2026](https://getdx.com/blog/ai-authored-code-has-nearly-doubled/)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

### После варианта A

**Даниил:** Опрос у нас в банке сделают по умолчанию, потому что его ни с кем не нужно согласовывать. Метрики DORA лежат в 3 системах, доступ к журналу конвейера выдают по заявке, поэтому сбор займёт месяц. Но отчитываться опросом я бы не стал: такие отчёты у нас читает риск-менеджмент, который первым делом спросит «а где замер?». Опрос я бы оставил для другого: искать, кто сопротивляется, а эффект считать по замерам.

**Мария:** В первый год мы тоже жили на опросах, которые выглядели прекрасно. Потом финансовый директор посчитала стоимость деплоя и увидела, что она выросла. Самое неприятное в том, что команда не врала: людям правда стало легче. Просто «легче» и «быстрее» означают разное. Сейчас мы проводим опрос, но кладём его рядом с данными инструмента, а расхождение между ними считаем отдельной метрикой.

- **Даниил:** Мария, расхождение как метрика звучит красиво, но кто его считает? У меня даже сбор данных об использовании без ИБ не включить.
- **Мария:** Сейчас считает платформенная команда. В первый год я считала сама, в таблице, раз в месяц. Это работа на 2 часа, проект для неё заводить незачем.

### После варианта B

**Даниил:** Месяц задержки в банке превращается в 2: пока вы настраиваете сбор, соседнее подразделение придёт к генеральному и заберёт пилот и бюджет себе. Контрольная группа у нас вызовет вопрос: почему одним можно, а другим нельзя? Но сам ход правильный. Я бы только открыто сказал генеральному, что первый месяц уходит на сбор данных, а таблицу baseline показал бы ему как результат, чтобы месяц не выглядел задержкой.

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

- **Мария:** Даниил, а у тебя контрольная группа вообще возможна? Команды всё равно узнают, что соседям дали инструмент.
- **Даниил:** Узнают и начнут пользоваться личными аккаунтами. Поэтому вместо 2 групп у меня будет разнесение по времени.
- **Мария:** Тогда не запускай регресс и ИИ в один месяц, иначе разнесение превратится в угадывание.

### После варианта C

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

**Мария:** Расход токенов по людям полезнее всего в панели, но только если рядом лежит результат. У нас был ровно такой инженер, который тратил половину бюджета команды. Когда мы сопоставили расход с тем, что он смержил, оказалось, что его агенты крутились на переделках. Без этого сопоставления мы поставили бы его в пример. Панель показывает, сколько потрачено, но не говорит о том, на что.

- **Мария:** Даниил, а долю принятых предложений вы считаете? У нас она росла вместе с дефектами.
- **Даниил:** Нет, в первый год считать не буду. Высокая доля у нас скорее значит, что ревью стало формальным.
- **Мария:** Не согласна: без неё не видно, на что уходят токены. Просто смотри её рядом с дефектами, отдельно она мало что говорит.

## Промпт для документа: Baseline: что снять до старта

Список того, что вы измерите до пилота, чтобы через квартал было с чем сравнивать. Если каких-то данных нет, запишите, когда настроите сбор: пилот лучше отложить на месяц, чем потом сравнивать с ощущениями. Пример заполненной таблицы – выше, в разделе «Пример: как выглядит снятый baseline». Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.

```
Ты – технический директор, который умеет измерять эффект изменений в разработке. Помоги мне составить документ «Baseline: что снимаем до старта пилота».

Обязательные 5 метрик:
- Частота деплоев
- Время от коммита до прода
- Доля сбойных изменений
- Стоимость единицы поставки: все расходы на команду за квартал, включая ИИ, делённые на число деплоев
- Дефекты на проде

Дополнительные, если есть данные (не больше 3):
- Время восстановления после сбойного деплоя
- Доля внеплановых выкаток из-за инцидента на проде (deployment rework rate)
- Время от постановки задачи до выкатки (TTM)
- Время ревью
- Размер пул-реквестов
- Время онбординга нового сотрудника

Что нужно выяснить:
- Какие метрики мы уже можем снять, из каких систем и за сколько месяцев есть данные. Нужны данные за 3 месяца. Для метрик времени (от коммита до прода, ревью, восстановление, TTM, онбординг) бери медиану. Для счётных метрик (деплои, дефекты) – сумму за период, для доли сбойных изменений – отношение сбойных к числу деплоев, например «3 из 26».
- Расходы на команду за квартал – для стоимости единицы поставки.
- Как отделим эффект ИИ: контрольная группа, разнесение по времени или разбивка по этапам. Объясни плюсы и минусы для моей ситуации. Если ИИ у нас уже используется, не предлагай контрольную группу «без ИИ»: её не получится собрать. Вместо неё предложи разнесение по времени (другие изменения не запускаем в тот же месяц) или разбивку времени поставки по этапам. Если команды используют ИИ по-разному, предложи сравнить, насколько сдвинулись метрики у команд с активным и со слабым использованием.
- Какие доступы к данным нужно согласовать с ИБ (журнал конвейера, данные об использовании инструмента) и сколько это займёт.
- Что ещё меняется в этом квартале (реорганизация, новый процесс, найм), что может исказить результат.
- Каких данных нет, кто настроит сбор и к какой дате.

Единица поставки – деплой. Пул-реквест и коммит не предлагай: с ИИ их становится больше сами по себе. Не предлагай больше 8 метрик всего: панель с 40 графиками никто не смотрит.

Правила работы:
- Задавай по 1 вопросу за раз и жди моего ответа.
- Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше.
- Если ответ размытый, попроси цифру или конкретный пример.
- Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня.
- Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть.
- Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым.
- Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть.

Формат документа: заголовок с датой «[дата]»; таблица «Метрика | Откуда берётся | Значение за квартал», как в примере из курса; если данных меньше чем за квартал, укажи период в ячейке значения; затем: способ отделить эффект ИИ; что ещё меняется; что согласуем с ИБ для сбора данных; чего нет и когда настроим сбор.
```

## Итог блока

- **После варианта A:** Квартал прошёл не так, как хотелось, но для первой попытки это нормальный исход. Главное из блока: мнение команды об эффекте ИИ данными считать нельзя, а baseline снимают до пилота, после него уже поздно. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
- **После варианта B:** Вы сняли baseline и оставили контрольную группу. Это правильный ответ, хотя Даниил прав в том, что в банке контрольную группу часто заменяет разнесение по времени. Главное из блока: baseline снимают до пилота, а эффект ИИ отделяют от остальных изменений. Соберите документ по промпту и переходите дальше.
- **После варианта C:** Квартал прошёл не так, как хотелось, но для первой попытки это нормальный исход. Главное из блока: метрики использования нужны для диагностики, а эффект показывают DORA, стоимость единицы поставки и качество, причём всё это снимают до пилота. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.