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

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

Проблема в том, что техдолг — это не эмоция команды. Это вполне реальная цена прошлых решений.

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

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

Вот это и есть техдолг.

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

И вот тут важно не просто говорить бизнесу, что "у нас техдолг, надо чинить", а нормально объяснять стоимость решения.

Я обычно строю такой разговор в 4 шага.

1. Не с "архитектуры", а с последствий для бизнеса Не "у нас легаси и плохая связность модулей", а "сейчас любая правка в этом блоке занимает в 2–3 раза больше времени и повышает риск поломок".

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

3. Не продавать "идеальный мир" Не "давайте всё перепишем", а 2–3 сценария: — ничего не делаем и живём с последствиями; — точечно чиним самый болезненный узел; — системно инвестируем в стабилизацию.

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

Для меня главный маркер простой. Если из-за старых решений каждая новая задача становится дороже, медленнее и страшнее — это уже не "внутренние жалобы команды". Это управленческая проблема и экономический вопрос.

Потому что техдолг — это не про красоту кода. Это про то, сколько будет стоить следующее решение.

#техдолг #technicaldebt #разработка #программирование #it #инженерия #архитектура #легаси