Технический долг — это ипотека, а не стихийное бедствие
Плохая метафора называть технический долг «мусором». От мусора избавляются сразу, а долг — это инвестиция с условиями. Ты берешь ресурс сейчас, чтобы решить задачу быстро, а потом платишь за это сложностью поддержки и доработки.
Если его учитывать и «обслуживать», то всё нормально. Даже большие компании, например Google, Amazon, Atlassian, спокойно живут с техническим долгом: они его не избегают, они его планируют. У них в роадмапе прямо написано, например, здесь делаем фичу в обход, но через два спринта выделяем ресурс на рефакторинг. Всё прозрачно, риск под контролем.
Но если не платить по счетам, всё сыпется. Команда начинает чинить баги дольше, фичи катятся медленно, а в какой-то момент любое изменение уже становится игрой Jenga: тронешь — всё упадет.
Именно поэтому задача продакта, тимлида или архитектора — не только объяснить бизнесу важность «переписывания старого», но и перевести это на понятный язык управления рисками и темпов роста.
Как показать влияние технического долга на бизнес-скорость
Одна из ключевых проблем технического долга в том, что он не виден на первый взгляд. Продукт вроде работает, клиенты довольны, деньги идут. Но внутри команда буксует: баги не чинятся, фичи не лезут, сроки срываются. И пока бизнес не увидит прямую связь между этим и качеством кода, рефакторинг будет казаться «дорогой роскошью».
Как технический долг влияет на скорость
Технический долг напрямую замедляет:
- разработку — добавление новой фичи требует сначала разобраться, как работает старая архитектура (часто без документации);
- тестирование — багов больше, регрессия шире, на каждый релиз уходит больше часов QA;
- поддержку — багфиксы превращаются в рисковые мини-рефакторинги;
- время выхода на рынок — простая идея превращается в недельную доработку из-за неготовности кода к изменениям.
Это приводит к тому, что вместо «быстрее запускаем — быстрее тестируем гипотезу» команда живет в режиме «нельзя трогать, вдруг сломается».
Примеры замедления бизнес-операций
- Фичи внедряются дольше.
Вместо трех дней уходит две недели: нужно поднимать старую бизнес-логику, обходить кривые зависимости, писать костыли. - Исправление багов затягивается.
Баг один, а цепляет четыре модуля. В итоге фиксят его по кусочкам, каждый раз рискуя сломать другое. Тесты слабые или устаревшие. - Сложно адаптироваться к рынку.
Если завтра нужно быстро изменить бизнес-логику, то это невозможно. Продукт «запаян». Бизнес упускает окно возможности, потому что «ну, в этом месяце мы не успеем, всё очень хрупкое».
Какие метрики использовать
Технический долг, конечно, не абстракция. Его можно и нужно показать в цифрах:
- Lead Time for Change (LTC) — сколько времени проходит от идеи до реализации. Если фича тривиальная, а срок — неделя, это уже тревожный сигнал.
- Bug count per release (BCpR) — сколько багов в каждом релизе. Рост — это индикатор ухудшающегося состояния кода.
- Code churn — насколько часто переписываются одни и те же участки кода (признак «горячих точек» и костыльной логики).
- Скорость выката фич — сравнение числа новых фич в релизах за последние 3–6 месяцев.
Эти метрики можно собрать из Jira, Git, CI/CD и баг-трекеров.
Как перевести технический долг в бизнес-язык
Чтобы бизнес действительно понял масштаб проблемы, технический долг нужно оцифровывать и интерпретировать.
Пример:
«Из-за архитектурного ограничения фича Х заняла 10 рабочих дней вместо 3. Это замедлило запуск новой партнерской интеграции и отложило потенциальную выручку на две недели — это около 800 тыс. рублей недополученной прибыли».
Или:
«У нас 27 багов повторяются от релиза к релизу. Их фиксы в среднем отнимают 40 часов в месяц. Это одна полноценная ставка middle-разработчика, которая уходит на борьбу с последствиями, а не на развитие продукта».
Кейс: как команда отказалась от рефакторинга — и села в лужу
Команда разрабатывала маркетплейс для B2B-заказов. Быстрый рост, частые фичи, давление со стороны инвесторов, всё как обычно. Архитектура стартовала на монолите с быстрым MVP на Django, к которому через год приросло 200+ моделей, 90% без автотестов. Кодовая база держалась на авось и паре старших разработчиков, которые «просто знали, где что лежит».
На первом ревью архитекторы предложили заложить месяц под вынос критичных модулей в микросервисы и разнести бизнес-логику по слоям. Ответ продакта был предсказуем:
«Мы не можем тормозить фичи ради абстрактного „качества кода“. Всё работает, давайте не мешать прогрессу».
Через полгода в приоритете появилась новая функция: быстрый заказ через Excel. И тут началось.
Как выглядела «лужа»
Чтобы добавить загрузку Excel-файлов:
- пришлось лезть в ветку заказов, где была куча бизнес-правил, добавленных прямо в контроллеры;
- часть заказов работала через отдельные таблицы с кастомной логикой (написанной уже уволенным разработчиком);
- при попытке внедрить новую логику стали падать старые интеграции;
- потребовалось 13 рабочих дней, 4 hotfix в прод и приостановка релизов других фич.
А потом баг. Excel-файл с заказом одного клиента привел к падению сервиса расчета доставки, потому что при чтении файла вызывался старый блок кода, ожидавший другие поля. Баг отловили спустя три дня, когда один из крупных клиентов начал писать в поддержку каждый час.
Что могло быть иначе
На ретроспективе команда пришла к очевидному: мы знали о проблеме, мы планировали рефакторинг, но отказались от него из-за бизнес-давления.
Если бы в свое время:
- выделили хотя бы один спринт на вынос логики заказов в отдельный сервис;
- внедрили хотя бы базовые автотесты на критичный функционал;
- начали постепенно закрывать устаревшие участки кода флагами и refactor-маркерами.
то:
- внедрение Excel-заказов заняло бы 3–4 дня без блокировок;
- баг в логике доставки бы не всплыл или был бы отловлен раньше;
- релизы других фич не замедлились бы на две недели.
Вывод
Отказ от рефакторинга — это не экономия, это кредит под высокий процент. Он не виден сразу, но однажды начинается дефолт. И тогда платить приходится уже не временем, а репутацией, клиентами и потерянным доходом.
Как убедить бизнес в необходимости рефакторинга и контроля технического долга
Убедить бизнес потратить время и деньги на рефакторинг — задача не из легких, особенно если «всё работает» и «пользователи довольны». Но если IT-команда хочет развивать продукт стабильно, без постоянного тушения пожаров, технический долг нужно объяснять на языке бизнеса, то есть в деньгах, рисках и скорости реакции на рынок.
Стратегии для убеждения руководства
Привязывайте долг к бизнес-целям
Вместо «нам нужно переписать модуль заказов» — «без рефакторинга мы не сможем за две недели добавить фичу, которая увеличит средний чек».
Показывайте долг как риск
Не надо пугать CTO или CEO словами «грязный код». Вместо этого: «У нас нет разработчиков, которые понимают модуль X. Любое изменение в нем — потенциальная остановка всего сервиса. Это риск уровня „падает основная выручка“».
Создайте карту технического долга
Покажите, где и как он влияет на скорость разработки: какие модули сложнее всего менять, где чаще всего баги, где дольше всего правятся фичи. Привяжите это к потерям: в скорости, деньгах, пользовательском опыте.
Как подготовить бизнес-кейс на рефакторинг
Чтобы продать идею рефакторинга, нужен не технический, а продуктовый аргумент. Важно показать, как вложения в техническое улучшение помогут:
- быстрее запускать фичи (time-to-market);
- сокращать издержки на поддержку;
- снижать риски сбоев и инцидентов;
- масштабироваться без хаоса.
Пример бизнес-кейса
Мы инвестируем три спринта в рефакторинг блока оплаты. Это позволит в будущем:
- сократить время внедрения новых способов оплаты с 10 до 3 дней;
- уменьшить баги в релизах (в среднем шесть багов на релиз → целевой показатель 1–2);
- снизить нагрузку на поддержку (минус 20% обращений по оплате).
Роль тестирования и автоматизации
Если у вас нет автоматизации, то каждое улучшение может превратиться в потенциальный регресс.
Именно поэтому:
- автотесты = свобода для рефакторинга без страха;
- CI/CD = раннее выявление ошибок;
- code review с фокусом на долг = постоянный контроль качества кода.
Важно встроить контроль техдолга в процесс, а не устраивать «рефакторинг-фест» раз в год. Например, по 10–20% времени в спринте отдавать под «обслуживание системы», как техобслуживание автомобиля.
Как делать понятные для бизнеса отчеты
Бизнес не читает ваш код, да даже если бы и читал, и не волнуется из-за code smell. Зато он реагирует на графики и прогнозы.
Создайте простую метрику:
- Долг/фича — сколько часов уходит на старую архитектуру на каждую новую фичу.
- Частота критичных багов в зоне N.
- Технический риск по зонам: зеленая/желтая/красная зона.
Добавьте прогноз:
«Если не вложиться в переработку модуля доставки, в течение трех месяцев мы не сможем безболезненно интегрировать новых партнеров, а это потеря до 15% потенциальной выручки».
Заключение
Технический долг не зло. Он неизбежен в любой живой системе. Проблема не в его наличии, а в отсутствии управления.
- Техдолг — это инвестиция, которую нужно обслуживать.
- Рефакторинг — это бизнес-инструмент для скорости, стабильности и роста.
- Показывайте влияние долга на деньги, сроки и возможности.
- Делайте техническое понятным, тогда оно перестанет восприниматься как абстракция.
Продукты, в которых техдолг под контролем, развиваются быстрее, падают реже и приносят больше денег. А это уже язык, который бизнес точно понимает.
