[Технический долг — это бизнес-проблема: как измерить, визуализировать и донести ее до руководства]

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

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

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

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

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

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

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

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

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

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

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

Метрики технического долга, которые я теперь смотрю первыми:

• Точность оценок в динамике. Не по спринту, а по кварталам в виде тренда. Когда команда стабильно занижает оценки, это редко означает плохое умение оценивать. Это означает, что кодовая база сопротивляется сильнее, чем предполагают тикеты.
• Частота переработок. Какой процент закрытых задач возвращается? Тикет, переоткрытый через два спринта, часто указывает на фикс, который нельзя было сделать нормально из-за окружающего кода. Переработки, концентрирующиеся вокруг конкретных модулей, — диагностический сигнал: именно там сосредоточен долг.
• Разброс времени выполнения по областям. Среднее время выполнения почти бесполезно. Разброс — особенно то, в каких областях кодовой базы он стабильно высок — показывает, где живет трение. Предсказуемое время выполнения означает чистый код. Хаотичный разброс означает структурную проблему.
• Соотношение багов к фичам. Когда работа по поддержке начинает вытеснять разработку, это проявляется здесь первым. Порог зависит от контекста: для молодого продукта или активно растущей кодовой базы соотношение выше 20% — уже сигнал для эскалации. Для зрелых систем немного больше запаса, но все, что стабильно превышает 30-35%, должно инициировать разговор с руководством, а не ретроспективу спринта.
• Сигналы глубины ревью. Сколько комментариев на пул реквест — и главное, архитектурные они или поверхностные? Высокий объем комментариев по поверхностным вопросам означает, что ревьюеры тратят энергию на проблемы оформления, потому что структурные слишком дороги для обычного цикла ревью.

DORA говорит, как быстро течет вода. А обозначенные выше метрики — сколько осадка накапливается в трубе.

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

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

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

Агентный ИИ берет на себя этот синтез. Я могу спросить: "Каков текущий статус рефакторинга модуля аутентификации и какие блокеры?" — и получить ответ, собирающий данные из тикетов, последних коммитов, комментариев к пул реквестам и логов стендапов за секунды, на простом языке.

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

Чего агентный ИИ не заменяет — это суждений. Я по-прежнему решаю, что означает информация, что приоритизировать и что сообщать руководству. Агент дает мне сырой материал. Управление разработкой по-прежнему остается за мной.

"Инструментальный хаос" — точное описание того, как большинство инженерных организаций работает на самом деле. У нас был Jira для отслеживания проектов, GitHub для кода, Slack для коммуникации, Google Календарь для встреч и кладбище таблиц с трекерами бюджета, которым никто не доверял полностью.

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

Enji подключился сначала к Jira и GitHub — это был критический путь. Настройка оказалась простой. Уже в первую неделю функция ворклогов показывала фактические данные о времени в сопоставлении с плановыми оценками с нужной детализацией, чего предыдущий инструментарий не давал. Было видно — по фиче, по разработчику, по спринту — куда уходит время в сравнении с прогнозом.

Представление маржинальности проекта четко показывало перерасход. Связать его с накопленным техническим долгом по-прежнему требовало собственного анализа кодовой базы, но впервые у меня появились цифры, с которых можно начать этот разговор. Появилось представление, связывающее активность поставки со стоимостью — не в бухгалтерском смысле, а в смысле "эта фича оценивалась в 40 часов, заняла 90, и вот паттерн за последний квартал". Это не показатель скорости. Это бизнес-показатель — тот, с которым можно идти к финансовому директору.

PM Агент изменил мой утренний распорядок: вместо того чтобы открывать пять вкладок и тратить тридцать минут на восстановление картины произошедшего вчера, я задаю вопрос и получаю сводку. Когда он впервые самостоятельно определил, что две разные проблемы, вероятно, связаны с одной и той же проблемой в базовом модуле раньше, чем я сама пришла к этому выводу — я поняла, почему Enji позиционирует себя вокруг "аналитики поставки", а не "метрик разработки". Это не просто маркетинговый ход, это отражает реальное различие в том, какую информацию предоставляет инструмент. Та же логика применима к панели мониторинга активности на базе ИИ, которая работает на уровне команды: она выявляет признаки снижения уровня взаимодействия и вовлеченности еще до того, как они приведут к проблемам с выполнением задач.

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

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

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

Чему я научилась с осторожностью относиться:

Конфликтующие данные между инструментами
Когда Jira говорит, что тикет закрыт, а GitHub показывает, что ветка не смержена — перед вами конфликт данных, а не аналитика. Это случается чаще, чем показывают демо. Синтез между инструментами надёжен в направлении, но я научилась проверять детали перед тем, как что-то попадает в отчет для стейкхолдеров.

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

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

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

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

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

Я бы начала с инфраструктуры измерений, а не с инструментов генерации.

Мы сделали всё наоборот: сначала дали инженерам ИИ-ассистенты, увидели рост скорости, отчитались наверх — и только потом столкнулись с долгом, который эти показатели скрывали. Если бы я делала это снова, я бы создала платформу аналитики поставки, что-то вроде Enji, до или одновременно с инструментами генерации. Нужно видеть, что происходит с кодовой базой в то же время, когда начинаешь ускорять то, что в нее попадает.

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

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

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