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

Привет, Хабр! Меня зовут Александр Смирнов, я продуктовый аналитик, помогаю находить точки роста, оптимизировать процессы и принимать решения на основе данных, а не интуиции. Сейчас многие компании проходят этап масштабного внедрения ИИ-инструментов для разработки, пока одни только экспериментируют, другие уже выстроили централизованный процесс. Но рано или поздно перед всеми встает закономерная задача — измерить эффект от этого мероприятия. Не «понравилось ли разработчикам», а сколько времени и денег это экономит, где теряется ценность и стоит ли вкладываться дальше.

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

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

Чтобы не перегружать читателя, я лишь кратко обозначу периферийные темы — такие как causal inference, governance, интеграции и визуализация, а основной упор сделаю на продуктовой логике

Главная мысль: метрики — это не просто отчётность, а система управления ценностью

Достаточно грубое заблуждение — замерять активность вместо ценности. «У нас X десятков активных пользователей и Y миллионов использованных токенов в месяц» — это не показатель успешности процедуры в нашем случае. Другое дело — сэкономленные часы разработки, ускоренные релизы и оптимизированные затраты. Таким образом, я не согласен с достаточно популярным сейчас мнением, что «уважающий себя специалист должен сжигать как минимум две свои месячные зарплаты токенами».

В своём подходе я выделил четыре основные группы, которые формируют продуктовую воронку:

1. Интеграция — верх воронки. По охвату понимаем масштабы всего мероприятия, набираем статистическую значимость.

2. Вовлеченность — глубина и удержание. Охват без удержания — выброшенные деньги на лицензии.

3. Эффективность и качество. Здесь появляются метрики ценности, такие как сэкономленное время и скорость поставки. Тут же проверяем, что наша «одержимость» новыми инструментами не сыграла в худшую сторону. Делаем быстро, но г… — не та цель, к которой стоит стремиться.

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

   

Метрика во главе стола

У всего дерева должна быть одна (пара) направляющая Царь-метрика (по-научному «North Star»), которая и будет верхнеуровнево показывать успешность (провальность) всего нашего процесса. Так или иначе мы придём к отношению времени и денег, поэтому предлагаю:

North Star = (часы, сэкономленные за месяц) / (затраты на ИИ за месяц)

По сути, мы узнаём, сколько часов разработки сэкономили, заплатив при этом один доллар (медяк). Все остальные метрики — саппортящие показатели, объясняющие поведение основной. Небольшая деталь, чтобы не было путаницы: North Star — наш операционный компас для контроля динамики в моменте. Итоговый же финрезультат подсвечивает ROI из группы «Экономика». Они не конкурируют, а дополняют друг друга.

Группа 1. Интеграция.

Метрики охвата в первую очередь показывают, сколько людей и отделов воспользовались новыми инструментами. Проще говоря, смотрим заинтересованность и востребованность со стороны наших сотрудников. Как показывает практика (и статьи на том же Хабре), не все команды одинаково относятся к внедрению ИИ-инструментов: есть как бегущие в первых рядах энтузиасты, так и консерваторы. От этих настроений зависят наши дальнейшие шаги и подход к онбордингу.

Метрика: Новые пользователи ИИ (New users)

• Определение: число сотрудников, впервые запустивших ИИ-инструмент за период (день/неделя/месяц). По сути — скорость наполнения воронки.

• Формула: New users = число сотрудников, впервые запустивших ИИ за период

• Ценность: показывает темп онбординга и эффективность конкретных мероприятий по привлечению сотрудников к новым инструментам в рамках компании.

Метрика: Активные пользователи ИИ (DAU / WAU / MAU)

• Определение: число уникальных сотрудников, запустивших то или иное ИИ-решение за конкретный период. Новых и активных пользователей также можно считать по когортам при необходимости.

• Формула: DAU = число уникальных сотрудников, использовавших ИИ за день (аналогично WAU — за неделю, MAU — за месяц)

• Ценность: это пульс внедрения. Растущий DAU/WAU = ИИ проникает глубже в рабочие процессы. Стагнация при доступных лицензиях — прямой сигнал к действию: онбординг, внутренние митапы, шаблоны промптов. Полезная прокся — stickiness («липкость») отношение DAU к MAU. Значения больше 0,5 говорят о том, что инструментом пользуются регулярно.

Метрика: Доля команд / отделов / сотрудников в рамках подразделения, использующих ИИ

• Определение: процент команд/пользователей разработки и аналитики, использующих хотя бы один ИИ-инструмент.

• Формула: Доля команд с ИИ = (команды хотя бы с одним пользователем ИИ) / (всего команд) × 100%

• Ценность: метрика позволяет увидеть, насколько успешно проходит интеграция. А сегментация помогает понять подробности: например, frontend-команда увидела пользу и использует ИИ в работе, а в mobile — лишь единицы. Дальнейший поиск причин и решений даёт возможности для роста других метрик.

Группа 2. Вовлечённость.

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

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

Метрика: Количество сессий на пользователя

• Определение: среднее число сессий ИИ на пользователя в день/неделю.

• Формула: Сессий на пользователя = (сумма сессий всех пользователей) / (количество пользователей)

• Ценность: показывает, стал ли ИИ привычкой. Низкое значение при высокой активности показывает, что пользователи заходят, но не находят применения.

Метрика: Retention или удержание пользователей

• Определение: доля пользователей, продолжающих пользоваться ИИ через заданный период. Метрику можно смотреть как накопительно (rolling retention), так и на конкретный день.

• Формула: Retention(D) = (пользователи, активные на день D) / (пользователи в когорте) × 100%

• Ценность: один из самых «честных» индикаторов реальной пользы. Мы не будем раз за разом возвращаться к инструментам, которые не несут пользу. Если кривая удержания «заваливается», то необходимо провести дебаг, прежде чем продолжать инвестировать, за пороговое значение можно взять 50%.

Метрика: Среднее время сессии

• Определение: средняя длительность активной сессии (сек, мин).

• Формула: Среднее время сессии = (суммарное активное время) / (число сессий)

• Ценность: отражает время непрерывного взаимодействия сотрудника с ИИ-интерфейсом (ввод промптов, чтение ответов, генерация кода/текста, редактирование) в рамках одной рабочей сессии. Метрика неоднозначная: не всегда длинные сессии говорят о сложности задачи и продуктивной работе. Правильнее анализировать её в связке с другими метриками, например с долей принятия подсказок.

Метрики ниже оставлю в данном разделе, но они уже находятся на рубеже между вовлечённостью и эффективностью.

Метрика: Команды и токены на сессию

• Определение: среднее число промптов и потреблённых токенов на сессию.

• Формула: Промптов на сессию = (всего промптов) / (число сессий); Токенов на сессию = (всего токенов) / (число сессий)

• Ценность: рост промптов на сессию может означать как усложнение задач, так и неэффективный подход к их решению со стороны пользователя, что может влиять на экономику. Чтобы точнее выявить причины, также необходимо анализировать данные с учётом других показателей.

Метрика: Доля принятия подсказок / исправлений (Acceptance Rate)

• Определение: отношение принятых рекомендаций инструмента к общему числу предложений.

• Формула: Acceptance Rate = (принятые предложения) / (принятые + отклонённые) × 100%

• Ценность: прямой и самый дешёвый в сборе сигнал качества предложений. Низкие значения могут говорить о качестве или релевантности модели — настройка правил и инструкций может дать значительный аплифт метрики. Слишком высокое принятие исправлений при росте багов говорит о слепом аппруве, то есть нужен «human-in-the-loop».

  

Группа 3. Эффективность и качество.

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

Метрика: Экономия времени разработчиков (Saved Time)

• Определение: разница во времени выполнения задач с ИИ и без него. Можно агрегировать по задачам/неделям/командам. Для расчёта пользуемся методами Causal Inference. Отлично, если есть возможность запустить A/B, но, вангую, что большинству останется Diff-in-Diff и его альтернативы.

• Формула: Saved Time = (время на задачу без ИИ) − (время на задачу с ИИ)

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

Метрика: Пропускная способность PR (Throughput)

• Определение: число PR/фич, выпущенных за период. Тут делаем поправку на разнородность, поэтому нужно нормировать с учётом сложности и/или размера, также можно просто агрегировать по этим признакам.

• Формула: Throughput = (число PR за период) / (длительность периода)

• Ценность: прирост throughput при стабильном качестве — прямое доказательство роста производительности. Но для большего контекста нужно смотреть в связке с другими метриками (прежде всего DORA).

Дальше — четыре метрики DORA

DORA — сбалансированная пара пар: две метрики про скорость (Deployment Frequency, Lead Time) и две про стабильность (Change Failure Rate, Time to Restore). Их ценность именно в совместном чтении. Рост скорости, не подкреплённый стабильностью, — повод насторожиться.

Метрика: Частота развёртываний (Deployment Frequency)

• Определение (DORA): количество изменений, доехавших до прода, за период.

• Формула: DF = (число релизов в прод) / (период)

• Ценность: показывает, доходит ли ускорение за счет новых инструментов на уровне кода до прода. Полезно смотреть в связке с пропускной способностью. Высокий Throughput при низком DF — команда работает быстро и закрывает много задач, но изменения копятся в релизной ветке: высокий риск что-то сломать при выкате, пользователи долго ждут обновлений. Обратная ситуация (низкий Throughput при высоком DF) — CI/CD настроен хорошо, но производительность самой команды хромает.

Метрика: Цикл разработки (Lead Time for Changes)

• Определение (DORA): время от первого коммита PR до деплоя в прод. Приводим медиану и 95-й перцентиль.

• Формула: Lead Time = (время деплоя) − (время первого коммита)

• Ценность: хороший индикатор скорости поставки ценности клиенту.

Метрика: Доля неудачных изменений (Change Failure Rate)

• Определение (DORA): доля релизов, приведших к сбою, откату или хотфиксу.

• Формула: CFR = (релизы с ошибками) / (всего релизов) × 100%

• Ценность: назовём это защитой от скрытого техдолга. С ней мы уверены, что рост скорости не обернётся ростом инцидентов и работой на откаты. Растущий CFR при растущем acceptance rate — красный флаг: код принимают не глядя, пора звать human’a

Метрика: Время восстановления сервиса (Time to Restore / MTTR)

• Определение (DORA): показывает, сколько времени требуется команде, чтобы полностью ликвидировать инцидент и вернуть систему в рабочий режим после сбоя на проде. Держим в уме, что инциденты могут отличаться по тяжести.

• Формула: MTTR = (суммарное время восстановления) / (число инцидентов)

• Ценность: показывает устойчивость к ошибкам, которые неизбежно будут. Вместе с CFR переводит абстрактный «риск ИИ-кода» в управляемые числа, на которые можно навесить алерты.

Группа 4. Экономика.

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

Метрика: Потребление токенов

• Определение: суммарные токены за период.

• Ценность: ранний индикатор затрат и косвенный — нагрузки. Аномальный рост токенов без роста пользы говорит о неэффективном подходе к использованию инструментов. Наиболее наглядный пример метрики, которую надо использовать в связке с другими.

Метрика: Стоимость ИИ (Cost)

• Определение: суммарные затраты на использование ИИ в денежном выражении.

• Формула: Cost = сумма всех затрат на ИИ за период (лицензии, оплата API, инфраструктура и сопровождение)

• Ценность: знаменатель ROI и основа бюджетирования. Каждая компания определяет, какие конкретно косты включить в метрику: будет ли это только оплата лицензий или же все затраты на поддержание стабильной работы инструментов.

Метрика: Стоимость за токен / сессию

• Определение: средняя стоимость одного токена или одной сессии.

• Формулы: Cost per token = (затраты) / (число токенов); Cost per session = (затраты) / (число сессий)

• Ценность: метрика операционной эффективности расходов. Рост Cost per session без роста пользы — прямой сигнал к оптимизации микса моделей, проверке условий вендора, замене инструмента и т. п.

Метрика: Сбережения (Savings)

• Определение: денежный эквивалент сэкономленного времени — по сути, основной «выхлоп» от внедрения ИИ.

• Формула: Savings = (сэкономленные часы) × (ставка инженера)

• Ценность: переводит сэкономленное время в деньги, понятные стейкхолдерам; это числитель ROI.

Метрика: LTV (пожизненная ценность)

• Определение: совокупная ценность, которую приносит один пользователь (или команда) за весь срок активного использования инструмента.

• Формула: LTV = (сбережения за месяц) × (срок активного использования в месяцах)

• Ценность: позволяет увидеть накопительный эффект, дает возможность для долгосрочного планирования. Даже умеренная месячная экономия за горизонт «жизни» пользователя превращается в существенную сумму.

Метрика: ROI и срок окупаемости

• Определение: рентабельность вложений в ИИ — во сколько раз эффект превышает затраты. Итоговый финансовый вердикт по внедрению.

• Формула: ROI = (сбережения − затраты) / затраты × 100%; Срок окупаемости (мес.) = (затраты) / (сбережения за месяц)

• Ценность: главный аргумент в пользу (или против) нового подхода и инструментов. По важности и «влиянию» не уступает нашей North Star метрике.

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

• Интеграция: доля команд с ИИ в арсенале выросла с 45% до 70%, WAU — с 18 до 41 человека.

• Эффективность (Saved Time): сравнение с контрольной группой показало, что задачи закрываются быстрее на 3,5 часа в неделю на активного пользователя, следовательно, 3,5 × 41 × 4,3 ≈ 617 часов.

• Savings: экономия в деньгах - 617 ч × 3500 руб. ≈ 2,16 млн руб.

• Cost: сумма, потраченная на лицензии + API + сопровождение составила 0,5 млн руб. за месяц.

• тогда ROI = (2,16 − 0,5) / 0,5 ≈ 3,3 (то есть, 330%), а срок окупаемости ≈ 0,5 / 2,16 ≈ 0,23 месяца, или 7 дней.

• North Star = 617 ч / 0,5 млн руб. ≈ 1,2 часа экономии на каждую 1000 руб. затрат. Таким образом, один сэкономленный час обходится в 810 рублей ИИ-затрат против средней ставки разработчика 3500 руб./ч.

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

Дополнительно: продуктовые и опросные метрики (DevEx, CSAT, DXI)

Описанное дерево метрик можно дополнить репутационными метриками:

• CSAT — удовлетворённость разработчиков инструментом.

• DevEx / DXI — индекс developer experience.

• DevSat — регулярный пульс-опрос восприятия ИИ

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

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

Заключение

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

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

Также отмечу, что и сами метрики — не серебряная пуля. Помним про закон Гудхарта: «когда метрика становится целью, она перестаёт быть хорошей метрикой». Как только показатели начнут фигурировать в KPI и OKR, их начнут подгонять. Поэтому смотрите метрики в связке, не привязывайте мотивацию к одиночному показателю и периодически пересматривайте сам набор.

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