Инженерные возможности после внедрения AI: что измерять

Почему число тикетов скрывает проблемы с поставкой

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

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

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

Представьте стартап, который внедрил AI и отчитался о росте числа закрытых тикетов на 40%. Звучит хорошо, пока основатель не проверяет релизы. Команда поставила столько же клиентских запросов, число дефектов в продакшене выросло, а старшие инженеры теперь тратят часть каждого дня на ревью больших групп сгенерированных изменений. Число тикетов показало активность, но не поставку.

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

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

Используйте число тикетов как дополнительный сигнал вместе с метриками, которые отслеживают путь работы до реального результата:

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

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

Пять метрик, которые показывают реальную поставку

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

Измеряйте путь до рабочего релиза

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

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

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

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

Измеряйте пользу релизов для клиентов

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

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

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

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

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

Как построить базовую линию за пять шагов

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

1. Определите период сравнения

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

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

2. Один раз определите каждую метрику

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

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

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

3. Фиксируйте середину и разброс

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

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

4. Не скрывайте категории работы

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

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

5. Проверяйте базовую линию каждую неделю

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

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

Читайте метрики вместе

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

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

Сравнивайте время написания кода со временем ожидания. Если AI сократил реализацию с четырех дней до одного, но pull request три дня лежат на ревью, общее время цикла почти не изменилось. То же относится к релизу: код может быстро пройти ревью, а затем ждать ручного тестирования или еженедельного окна развертывания. Клиент ощущает всю задержку целиком.

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

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

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

Например, стартап из шести человек тратит $72,000 в месяц на разработку, подрядчиков и AI-подписки. До внедрения AI он выпускал четыре клиентские функции в месяц. После внедрения выпускает шесть, но число инцидентов в продакшене выросло с одного до пяти, а два инженера тратят большую часть пятницы на их устранение. На первый взгляд стоимость функции снизилась с $18,000 до $12,000, но до объявления об успехе команде нужно проверить качество.

Используйте метрики вместе:

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

Простой пример команды стартапа

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

Первое число ввело основателя в заблуждение. Дополнительные тикеты создали более длинную очередь на ревью. Pull request ждали примерно на два дня дольше, потому что каждый разработчик открывал больше запросов, а ответственный за ревью не был определен. Код был готов, но не объединен, поэтому клиенты не получили обновление раньше.

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

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

Для этого результата команда отслеживала пять показателей:

• время цикла от первого изменения кода до выхода в продакшен;
• возраст очереди на ревью от открытия pull request до первого ревью;
• ошибки в счетах, о которых сообщили клиенты после релиза;
• доступность биллингового сервиса во время изменения;
• общие расходы на разработку и поддержку для завершенного обновления.

Узкое место стало очевидным. AI помогал разработчикам быстрее писать и исправлять код, но работу ограничивало ревью. Команда назначила одного дежурного ревьюера на каждый день и обязала ревьюеров обрабатывать открытые pull request до начала новых тикетов. Перед каждым релизом она также проверяла несколько реальных случаев со счетами.

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

Ошибки, которые искажают цифры

AI может сделать команду более занятой раньше, чем более быстрой. Самая очевидная ошибка, считать строки сгенерированного кода, pull request или закрытые тикеты. Эти числа описывают активность, а не то, получил ли клиент работающее улучшение.

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

Сравнивайте сопоставимые периоды

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

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

Держите измерения простыми:

• разделяйте функции, дефекты, техническое обслуживание и срочные инциденты;
• записывайте медианное время цикла и возраст самых старых незавершенных задач;
• сравнивайте периоды с похожим составом работы и размером команды;
• отмечайте необычные события, например запуск, отсутствие сотрудника или крупный сбой.

Считайте влияние, а не количество дефектов

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

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

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

Аудит инженерных возможностей после внедрения AI должен отвечать на вопрос: получают ли клиенты надежные результаты быстрее и при меньших общих расходах? Если очереди на ревью растут, дефекты доходят до клиентов или релизы замедляются, объем тикетов не объяснит проблему. Ее покажет путь поставки.

Короткая еженедельная проверка поставки

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

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

Используйте короткий список:

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

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

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

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

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

Следующие шаги для вашей команды

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

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

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

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

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

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

Если данные показывают проблемы, но команда не может согласовать их причину, Team & AI Audit Олега Сотникова за пять рабочих дней проверит расходы на разработку, процессы поставки и использование AI. Вы получите понятный план экономии до изменения структуры команды или покупки новых AI-инструментов.