Продайте технический долг генеральному директору, не говоря о коде

Почему этот разговор часто терпит неудачу

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

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

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

Абстрактный язык тоже вредит. «Technical debt» слишком широкий термин. «Каждое изменение биллинга добавляет два дополнительных дня QA» — это конкретно. Как и «тикеты в поддержку скачут при каждом изменении чекаута» или «эта проблема задержала запуск на неделю». Это — бизнес-проблемы. У них есть стоимость, владелец и дедлайн.

Разговор меняется, когда вы называете риск простым языком. «Эта часть системы замедляет релизы, увеличивает расходы на поддержку и повышает вероятность простоя для клиента» — это то, на что CEO может отреагировать. Теперь вы просите не о доверии, а о решении.

Что в первую очередь волнует CEO

Большинство CEO сортируют проблемы по ущербу для бизнеса, а не по тому, насколько некрасиво выглядит код. Если выручка в порядке, поддержка тиха, а релизы всё ещё выходят вовремя, они потратят деньги в другом месте.

Именно поэтому слова вроде «refactor» и «cleanup» часто не проходят. Начинайте с эффекта.

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

Стоимость поддержки рядом, потому что её легко увидеть. Если из‑за одного бага появляется 40 тикетов в месяц, это зарплата, более медленные ответы и рассерженные клиенты. Это уже не только продуктовая проблема.

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

Есть и более тихая потеря: внутреннее время. Инженеры тратят часы на поиск старых багов, перезапуск упавших задач, ручные правки данных и переделку работы после хрупких деплоев. Это время не появляется в счётах, но компания всё равно платит за него.

Обычно CEO прислушается, когда вы оформите проблему числами, которые они уже отслеживают:

• потерянные или отложенные деньги
• часы поддержки в неделю
• сдвиги дат релизов
• время инженеров, потраченное на повторные исправления

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

Выберите долг, который вредит бизнесу сейчас

Не приходите в комнату с 40 задачами по очистке. Выберите одну проблему, максимум две, которые уже вредят компании так, что это понятно всем.

Начните с области, которая стоит денег, создаёт заметную нагрузку поддержки или задерживает релизы. Остальное оставьте на потом. Широкая презентация кажется расплывчатой. Узкая проблема с недавним счётом выглядит реальной.

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

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

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

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

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

Превратите инженерную боль в деньги и время

CEO не нужно разделять фрустрацию команды. Им нужно видеть стоимость.

Начните с потраченного инженерного времени. Задайте узкий вопрос: сколько часов эта проблема «съедает» еженедельно? Учтите погоню за багами, ручные исправления, упавшие деплои, ретесты и отвлечения от саппорта. Если четыре инженера теряют по два–четыре часа в неделю, это 8–16 часов. При полной ставке $70–$120 в час бизнес «сжигает» примерно $560–$1,920 еженедельно.

Добавьте часы поддержки и переделки. Если та же проблема создаёт 15 дополнительных тикетов в месяц, и каждый тикет требует 20 минут поддержки плюс 30 минут инженерной работы, расходы быстро накапливаются. Вам не нужны точные данные из финансов — грубый диапазон подойдёт, если вы можете объяснить, откуда он взят.

Пользуйтесь простой арифметикой, которую можно озвучить в одно предложение:

• еженедельные инженерные часы × стоимость часа
• ежемесячные часы поддержки и переделок × стоимость часа
• задержка релиза × вероятная ценность сделки, продления или кампании
• текущая месячная стоимость по сравнению со стоимостью исправления

Задержки релизов часто — самая сильная часть кейса. Если старый сервис отодвигает нужную фичу на четыре недели, привяжите к этой задержке бизнес‑число. Возможно, продажи не смогут закрыть контракт на $12,000–$25,000 в этом месяце. Возможно, на продление подписки будет риск, пока производительность не улучшится. Суть не в идеальной точности, а в демонстрации цены ожидания.

Используйте диапазоны, когда данные неточные. «Эта проблема, вероятно, стоит нам $3,000–$7,000 в месяц» звучит честнее, чем притворяться, что это $4,386.

Держите рассказ коротким. «Мы теряем около 12 инженерных часов в неделю, поддержка тратит ещё 10 часов в месяц на ту же проблему, и один релиз сдвинулся на две недели в прошлом квартале. Исправление займёт шесть недель и, вероятно, окупится в течение квартала–двух». Это бизнес‑кейс, а не спор о коде.

Составьте одностраничный кейс

Большинство CEO прочтут страницу, которая помогает им принять решение. Они не будут читать три страницы про архитектуру.

Откройте одной фразой, которая называет проблему в бизнес‑терминах. Пропустите ярлыки вроде «legacy», если вы не объясняете эффект. Лучше начать так: «Сбои в чекауте стоят оплат, создают дополнительную нагрузку поддержки и замедляют каждый релиз, связанный с биллингом». Эта фраза даёт проблеме цену вместо технической метки.

Далее покажите текущие потери тремя числами. Трёх достаточно. Выберите числа, которые руководство уже ценит: потерянная выручка, часы поддержки и сдвиг релиза. Если цифры — оценки, скажите об этом и держите их консервативными.

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

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

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

Если нужен простой шаблон для страницы, используйте этот:

• бизнес‑проблема в одном предложении
• три числа, которые показывают текущую стоимость
• небольшой фиксированный объём, на который вы просите средства
• два–три ожидаемых результата после исправления
• одна строка о том, что остаётся вне объёма

Обычно этого достаточно, потому что такой документ читается как операционное решение, а не как инженерная жалоба.

Как проводить встречу

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

Используйте одну историю, а не груду старых жалоб. Расскажите, что случилось, кто это почувствовал и во что это вылилось. Например: «В прошлом месяце баг в биллинге создал 37 тикетов в поддержку, отложил запуск новой цены на неделю и отвлёк двух инженеров от роадмапа». Это придаёт встрече вес, не переходя в разговор о качестве кода.

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

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

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

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

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

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

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

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

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

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

Такое обоснование меняет ход встречи. Руководство перестаёт слышать «инженерия хочет уборку» и начинает слышать «мы уже платим за это каждую неделю».

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

Тогда одобрение становится проще. Работа перестаёт быть про чистоту кода и становится про защиту выручки и возвращение команды к поставкам.

Ошибки, которые ослабляют ваш кейс

Слабые презентации обычно терпят неудачу по одним и тем же причинам.

Первая — начало с инженерного языка. Если вы говорите CEO, что код некрасивый, непоследовательный или с ним трудно работать, это звучит как вкус. Большинство руководителей не профинансируют «чистый код». Они профинансируют снижение риска выручки, меньше тикетов и более быстрые релизы.

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

Плохие числа могут навредить больше, чем их отсутствие. Команды иногда завышают оценки, потому что боль очевидна для них. Руководство быстро проверит утверждение. Если вы говорите, что система «съедает 40% инженерного времени», будьте готовы показать методику измерения. Простые доказательства достаточны: повторяющиеся инциденты, сдвинутые релизы, часы поддержки по одной повторяющейся проблеме, возвраты после простоев или дополнительное время на обычную фичу.

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

Многие команды также забывают показать стоимость бездействия. Это оставляет CEO сравнивать реальный счёт сегодня с расплывчатой проблемой завтра. Сделайте обмен конкретным: «Если мы ничего не сделаем, поддержка продолжит тратить 15 часов в неделю на ручные исправления, а следующая смена цен займет три недели вместо четырёх дней» — с этим трудно спорить.

Быстрая проверка перед просьбой

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

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

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

Что делать дальше

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

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

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

Небольшой пример обычно работает лучше. Если проблемы с логином создали 18 тикетов в прошлом месяце, отвлекли двух инженеров на срочные исправления и задержали плановую фичу на четыре дня, скажите это прямо. Большинство CEO лучше реагируют на «это задержало запуск и увеличило расходы поддержки», чем на «наш auth‑слой нужно рефакторить».

Если вашей команде нужна помощь в переводе технического риска в бизнес‑кейс, опытный Fractional CTO может помочь перевести проблему на понятный язык и отсеять слабые утверждения. Oleg Sotnikov на oleg.is делает такую консультационную работу для стартапов и компаний малого и среднего размера, особенно когда проблема касается архитектуры продукта, скорости доставки, инфраструктуры или перехода к разработке на базе ИИ.

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