[Как мы сделали эффективность вложений в ИИ видимым для инженеров и клиентов]

Три года назад я сидел напротив CFO, который только что утвердил значительный бюджет на AI-инструменты и хотел знать, что мы получили взамен. Я подготовил слайды с инженерными метриками: улучшение скорости, частота деплоев, сокращение времени выполнения. Я тщательно прошелся по ним, он вежливо выслушал, а потом спросил: "Но мы зарабатываем больше? Мы быстрее закрываем проекты для клиентов?"

Хорошего ответа у меня не было.

Тот разговор изменил мое понимание измерения эффективности вложений в ИИ (AI ROI). Проблема была не в том, что AI не приносил ценности — он приносил. Проблема была в том, что я измерял ее на языке, который ничего не значил для людей, утвердивших инвестиции. Стейкхолдеры работают в совершенно другой системе координат. Их интересует: сдадим ли проект в срок, уложимся ли в бюджет и можно ли доверять команде, что она поднимет проблему раньше, чем та станет их проблемой. Увеличение скорости и частоты деплоев не дают понимание ни по одному из этих вопросов.

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

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

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

Когда AI вошел в наш рабочий процесс, показатели скорости выросли. Инженеры генерировали код быстрее, ревью двигались оперативнее, стендапы стали короче, потому что разбирать было меньше. Руководство было довольно. Клиенты — нет. Они по-прежнему получали те же сюрпризы, те же разговоры про объем работ в конце проекта и те же письма "нам нужно ещё немного времени".

Метрики, которые у меня были, измеряли, как работает двигатель. Но никто не создал инструментов для измерения того, как работает вся машина, внутри которой этот двигатель находится.

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

Команды на одном проекте могут обойтись метриками уровня проекта. Организации с несколькими проектами — агентства, консалтинговые компании и внутренние команды, ведущие несколько продуктов параллельно, — нуждаются в портфельном уровне для корректного отслеживания результатов. Именно здесь большинство AI ROI-фреймворков рассыпаются.

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

Если агрегировать эти эффекты в единое общекорпоративное число AI ROI, получается вводящее в заблуждение среднее. Метрики, работающие на портфельном уровне — это соотношения, а не абсолютные значения: дисперсия маржинальности по проектам, распределение предсказуемости по портфелю, плотность призрачных FTE по типу проекта и зрелости стека. Они показывают, где AI создает ценность, а где нет.

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

Решение потребовало создания иного измерительного слоя — такого, который отслеживал бы то, что реально важно клиентам и руководству. На протяжении нескольких проектов я пришёл к трём метрикам, которые вместе отвечают на вопросы, которые стейкхолдеры на самом деле задают: рентабелен ли проект, идёт ли он по плану и делает ли AI команду по-настоящему более мощной?

Маржинальность проекта — это соотношение доставленной ценности к понесенным затратам, отслеживаемое в реальном времени на протяжении жизненного цикла проекта.

• "Понесенные затраты" — сумма всех залогированных инженерных часов, конвертированных в денежную стоимость по загруженным ставкам труда, плюс прямые расходы по проекту.
• "Доставленная ценность" — согласованная стоимость контракта, умноженная на процент выполненного объема работ на текущую дату. Здесь важно уточнить, что под "выполненным объемом работ" понимается именно освоенный объем, а не выставленная выручка).

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

Что это нам показало. До AI-инструментов наша маржинальность была непрозрачна до момента выставления счета. После подключения к функции "Маржинальность проектов" в Enji у нас появилась живая видимость затрат относительно ценности по каждому активному проекту. Фичи, которые раньше стоили 40 часов, укладывались в 28. Этот разрыв появлялся в данных по марже на той же неделе, когда происходил, а не в квартальной ретроспективе.

Когда клиент спрашивал о статусе бюджета, я мог открыть реальное время маржи, а не лезть в таблицу, и дать четкий ответ: "Мы на 62% бюджета при 70% выполненного объема работ". Это совсем другой разговор, чем "все идет по плану". Первое — конкретные данные; второе — просто слова.

Где эта метрика может ввести в заблуждение. Маржинальность проекта может улучшаться по причинам, не связанным с AI. Самая распространенная: сокращение объема работ. Когда AI ускоряет доставку, команды иногда неосознанно убирают edge-кейсы и работу по укреплению системы, чтобы уложиться в сроки. Прежде чем приписывать рост маржинальности AI, проверьте, не изменился ли в тот же период уровень дефектов и количество часов на постлаунч-поддержку.

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

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

(Майлстоуны, сданные в рамках порога отклонения / Все взятые на себя майлстоуны) × 100%

Я использую скользящее окно в 90 дней и порог отклонения ±5% от заявленного срока. Майлстоун, сданный на три дня позже при 60-дневном обязательстве, укладывается в порог; сданный на две недели позже — нет.

Что это нам показало. До AI-инструментов наша предсказуемость поставки составляла около 67%. Мы стабильно выполняли цели спринтов, но квартальные обязательства по доставке были ненадежными. Через шесть месяцев после внедрения AI и сопутствующих процессных изменений предсказуемость выросла до 89%, затем до 92%. Последний год мы держим ее выше 90%.

Вот почему 92% лучше 100%: команда, заявляющая 100% предсказуемость, либо занижает оценки, либо нечестно фиксирует сбои. Команда, выдающая 92% и способная объяснить 8% конкретными, неповторяющимися причинами, — это команда, которая понимает собственную производительность. Клиенты доверяют второй команде больше, потому что данные достоверны. Это доверие напрямую конвертируется в продление контрактов и расширение scope.

Примечание об атрибуции. Два изменения произошли одновременно. AI-инструменты сократили дисперсию цикла по отдельным тикетам, а мы изменили процесс оценки, используя исторические данные из PM агента для флага оптимистичных оценок до их фиксации. Мой честный вывод: процессное изменение обеспечило примерно половину прироста; AI-инструменты — остальную половину, в основном через более стабильное выполнение на уровне тикетов.

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

Маржинальность показывает, рентабельна ли работа. Предсказуемость — укладывается ли она в сроки. Ни то, ни другое не говорит, делает ли AI вашу команду реально более мощной, или вы просто выполняете тот же объём работы с лучшими инструментами. На этот вопрос отвечает третья метрика — и именно она наконец сделала AI ROI понятным для нашего финансового отдела.

Призрачный FTE / Ghost FTE — это эквивалент производительности полноценного штатного сотрудника, который создали AI-инструменты без найма:

1. Установите базовый результат на инженера за определенный период до внедрения AI, измеренный в часах доставочной работы в неделю с поправкой на сложность тикетов на основе исторических данных о времени цикла по типу и размеру.
2. Измерьте тот же показатель за эквивалентный период после внедрения AI, используя ту же поправку на сложность.
3. Выразите разницу как эквивалент штатных единиц: если десять инженеров доставляют то, что раньше доставляли двенадцать, призрачный FTE = 2.
4. Конвертируйте в экономическую ценность по загруженной стоимости труда для эквивалентных ролей: зарплата, льготы, рекрутинг и онбординг старшего инженера на вашем рынке.

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

Что это нам показало. Расчет призрачного FTE перевел AI ROI в термины, которые финансовый отдел мог оценивать напрямую: эквивалент найма двух старших инженеров без рекрутингового цикла, периода онбординга и дополнительных управленческих накладных расходов. Зеленые ворклоги Enji сделали этот расчет возможным, предоставив данные по времени на уровне задач до и после.

Где эта метрика может ввести в заблуждение. Расчеты призрачного FTE ломаются, когда AI-инструменты генерируют низкокачественный результат, требующий значительной ручной правки. Сырые цифры результатов растут, но rework поглощает выигрыш. В legacy-кодовых базах, где AI-предложения часто конфликтуют с устоявшимися паттернами, мы видели завышение призрачного FTE на 40% и более, когда переработки не отслеживался отдельно. Всегда измеряйте уровень переработок параллельно с призрачным FTE и пересчитывайте при его росте.

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

• График 1: Тендеция маржинальности проекта. Линейный график с текущей маржинальностью относительно целевой на протяжении жизненного цикла проекта, обновляемый еженедельно. Одна линия, одна цель, одно направление тренда.
• График 2: Предсказуемость поставки. Простой индикатор или процент со скользящим окном в 90 дней. Выше 88% — зеленый. 80-88% — желтый. Ниже 80% — разговор другого рода.
• График 3: Соблюдение договоренностей по майлстоунам. Таймлайн с заявленными и фактическими датами доставки для трех последних крупных майлстоунов. Не спринтов, именно майлстоунов. Вещей, которые клиенты воспринимают как значимые маркеры прогресса.

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

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

Фреймворк измерения работает только при структурированном внедрении. Вот последовательность, которая дает стабильные результаты:

До внедрения AI-инструментов:

• Установите базовые метрики по трем ключевым показателям: текущий показатель маржинальности по типам проектов, текущая предсказуемость поставки за последние 90 дней, текущий результат на одного инженера по роли и стеку.
• Подключенте инфраструктуу данных доставки. Если данные по ворклогам не связаны с финансами проекта до прихода AI, призрачный FTE рассчитать после не получится.
• Определите как выглядит успех, — в бизнес-терминах, не в инженерных. Далее установите цели и разбейте их на конкретные задачи по улучшению маржинальности, предсказуемости и FTE до внедрения.

В процессе внедрения:

• Запускайте в параллельном режиме как минимум один проектный цикл, прежде чем делать выводы. Кривые освоения AI реальны.
• Отслеживайте уровень адаптации отдельно от метрик результативности. Инженер с доступом к AI-инструментам, но не использующий их, выглядит как отрицательная точка данных по AI ROI.
• Следите за сигналами ускорения технического долга. Если AI генерирует код быстрее, чем ревью-процессы успевают его поглощать, выигрыш по марже будет временным.
• Отслеживайте часы по переработкам с самого начала.

После внедрения:

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

Разговор с CFO, с которого начинается эта статья, повторился в прошлом квартале. На этот раз у меня было три графика и данные, которые были сразу ему понятны: маржинальность выросла на 18%, предсказуемость поставки составила 91%, FTE-эквивалент — 2,4 старших инженера. После чего был задан только один вопрос: "Можем ли мы сделать это в других бизнес-юнитах?"

Именно такой разговор измерение AI ROI и должно производить.