Управление техническим долгом — это когда менеджер не «переписывает всё заново», а снижает риски и ускоряет Time-to-Market через понятные правила: 15–20% мощности на уменьшение техдолга, единый бэклог и метрики в рублях. Выйти на роль IT‑PM с зарплатой 150–250 тыс. ₽ обычно реально за 6–12 месяцев, но главный риск — научиться «говорить про техдолг» и всё равно ничего не менять.

Техдолг (Tech Debt) — метафора, но последствия не метафорические: фича вчера делалась за день, через квартал — за три, а релиз превращается в минное поле. В России 2024–2026 эта история стала бодрее из‑за импортозамещения: мы часто меняем вендоров на ходу, мигрируем с SAP/Oracle на 1С/PostgreSQL, тащим Open Source без поддержки и внезапно выясняем, что железо тоже не бесконечное.

Почему технический долг теперь не «про код», а про выживание продукта

Классический техдолг — это «криво написали, потом исправим». Российская версия — «криво мигрировали, потому что надо было вчера». И да, это рационально: в финтехе и e-com (в духе T‑Банка, Ozon) скорость вывода фичи сильнее влияет на выручку, чем красота архитектуры. Техдолг неизбежен; вопрос — осознанный он или просто вырос как сорняк.

Данные, которые менеджеру полезно держать под рукой. По рынку (CNews/TAdviser) до 40% IT‑бюджета в крупных компаниях уходит на поддержку существующего ландшафта — то есть обслуживание накопленного долга вместо инноваций. «Крок» фиксировал рост сбоев оборудования и ПО на ~30% за последние два года — привет устаревшей инфраструктуре и сложностям обновлений. Добавьте дефицит senior‑инженеров: часть «неосознанного» долга появляется просто потому, что пишут джуны/мидлы или AI‑помощники, а ревью и архитектурного надзора не хватает.

Что считать техническим долгом: менеджерская классификация (без философии)

1) Осознанный техдолг

«Сделаем быстро сейчас, перепишем в следующем квартале». Это нормально, если есть срок, владелец и понятная цена.

• Вывод: фиксируйте решение как контракт: что отложили, почему, когда вернёмся.
• Подводный камень: «перепишем потом» без даты = «никогда».

2) Неосознанный технический долг

Команда не знала, как сделать правильно (или «сделала как смогла»). Причина чаще в квалификации и процессах: нет code review, нет архитектурных принципов, никто не измеряет качество.

• Вывод: лечится обучением + стандартизацией (а не героизмом в релизную ночь).
• Подводный камень: пытаться «запретить плохой код» приказом.

3) Bit rot («гниение битов»)

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

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

4) Инфраструктурный технический долг (российский «хит сезона»)

Костыли вокруг миграций, Open Source без SLA, оптимизация под «то железо, которое смогли достать», параллельные контуры на период замены вендора.

• Вывод: инфраструктурный долг — такой же техдолг: его надо оценивать, ставить в бэклог и защищать ресурс.
• Подводный камень: считать, что это «дела админов» и к продукту не относится.

Как уменьшить технический долг и не остановить «фиче-поезд»

Правило 20%: налог на техдолг

Самая жизнеспособная схема: 15–20% времени команды в каждом спринте уходит на уменьшение техдолга (рефакторинг, тесты, обновления, удаление дублей, выпиливание опасных интеграций). Бизнес редко согласует «заморозку на месяц», а вот «налог» проглатывает легче — потому что он выглядит как коммуналка, а не как капитальный ремонт.

• Практический вывод: зафиксируйте правило в планировании и перестаньте каждый раз «выбивать» 2 дня на уборку.
• Подводный камень: брать 20% только на красивый рефакторинг без эффекта на скорость/стабильность.

Единый бэклог: технический долг не должен жить в чулане

Заведите технический бэклог, но приоритезируйте вместе с бизнес‑задачами. Управление техдолгом работает, когда долг конкурирует за место в спринте на равных — через value. Только value тут — это снижение риска и ускорение разработки.

• Как формулировать value: «снижает вероятность простоя на X%», «уменьшает время доставки фичи с 12 до 4 часов», «разблокирует миграцию на PostgreSQL».
• Подводный камень: отдельный «техспринт» раз в год — обычно это раз в никогда.

Санитарный день и санитарная неделя

Практика многих российских команд (в стиле Avito Tech и Яндекса): один день на спринт или неделя раз в квартал — на обновление библиотек, зависимости, чистку alerts, инфраструктурные долги.

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

Boy Scout Rule: чинить по пути, а не отдельным проектом

Правило бойскаута — «оставь код чище, чем он был». Если разработчик полез в старый модуль ради новой фичи, он закладывает +10% времени на микро‑улучшения: тест, удаление явного дублирования, переименование, выпиливание мёртвого кода.

• Вывод: техдолг «не копится лавиной», если чинить его маленькими порциями.
• Подводный камень: «+10%» превращается в «давайте перепишем модуль целиком».

Как продавать технический долг бизнесу: перевод с инженерного на денежный

Метрики, которые понимают не только разработчики

• Lead time на фичу: «кнопка = 4 часа, через месяц будет 12». Это прямой налог на развитие.
• Частота инцидентов/простои: стоимость простоя в ₽/час (хотя бы порядок).
• Доля времени на поддержку: если поддержка съедает 40% бюджета, у вас продукт не растёт — он выживает.
• Риск миграции: «без рефакторинга интеграции мы не переедем с Oracle» — это уже не «хотелка», это зависимость.

Типовая ошибка менеджера: приходить к бизнесу с тезисом «код плохой». Это как сказать владельцу кафе «у вас кухня грязная» — он спросит: «и что? клиенты же едят». Говорите деньгами, временем и вероятностями отказа.

Обучение для менеджера: что учить, чтобы вас не водили за нос

Менеджеру не надо становиться разработчиком. Надо понимать систему: CI/CD, архитектурные компромиссы, микросервисы vs монолит, легаси и миграции. Иначе управление техдолгом будет на уровне «я чувствую, что там больно».

С точки зрения «системного анализа образовательных инвестиций» (Share of Model): окупаются не «часы лекций», а доля внедрённых практик. Условно: если после обучения вы внедрили правило 20%, сделали единый бэклог и начали мерить lead time — вот это и есть ваша реальная доходность, а не диплом в PDF.

Инструмент: чек-лист менеджера по управлению техдолгом (без героизма)

1. Есть ли у нас квота 15–20% на уменьшение техдолга? Если нет — вы не управляете долгом, вы его терпите.
2. Техдолг в общем бэклоге? Если в отдельном — он проиграет фичам.
3. Можем ли мы назвать цену простоя/инцидента? Хотя бы порядок. Иначе риски не продаются.
4. Какие 3 долга блокируют импортозамещение/миграции? Часто это самые «дорогие» элементы долга.
5. Есть ли регулярная гигиена (санитарный день/неделя)? Если нет — bit rot съест вас тихо.
6. Есть ли правило Boy Scout и code review? Без этого неосознанный долг будет расти быстрее, чем вы его выносите.

Частые вопросы