Технический долгУправление~6 мин чтения

Как объяснить технический долг без технических слов

Бизнесу не нужен «красивый код». Ему нужны предсказуемая скорость, устойчивость и понятный риск.

TL;DR

debt-report.md

• Технический долг — не список некрасивых мест в коде
• Это снижение скорости и рост риска будущих изменений
• Долг нужно связывать с конкретными бизнес-сценариями
• Погашать всё не нужно: важны проценты, которые уже мешают

Почему разговор обычно не получается

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

Проблема не в том, что бизнес не ценит качество. Проблема в отсутствии связи между техническим состоянием и тем, что бизнес собирается делать дальше.

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

→Не «запутанные зависимости», а каждое изменение тарифа занимает пять дней вместо одного.

→Не «нет тестов», а после каждого релиза менеджеры два часа вручную проверяют ключевые заказы.

→Не «старая библиотека», а платформа перестанет получать исправления безопасности через три месяца.

У долга есть проценты

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

💡

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

Минимальная карточка долга

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

Например: «Модуль расчёта доставки. Изменение правил занимает 4–6 дней, два инцидента за квартал. Перед выходом в новый регион потребуется переработка на 8–10 дней». Это уже предмет выбора, а не спор о вкусе.

Не нужно переписывать всё

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

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

Провести технический разбор

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

Telegram@itempire23 Emailfounder@it-empire.ru