Забудьте на минуту про «спагетти-код» и «костыли». Говорите так:
«Технический долг - это осознанный или неосознанный компромисс. Мы выбираем быстрое решение сейчас (чтобы успеть к запуску, угодить клиенту и т.д.), зная, что позже придется потратить значительно больше времени и денег, чтобы это исправить и развивать продукт дальше.»
Это инвестиция в скорость сегодня ценой процентов завтра. И, как с любым долгом, если его не обслуживать, наступает техническое банкротство.

Используйте эти сравнения, как правило, они работают безотказно.
1. Аналогия со зданием (самая мощная)
Представьте, что ваш продукт - это жилое здание.

• «Быстрая кнопка» - это не просто повесить вывеску на фасад. Это - требование достроить еще три этажа к зданию, фундамент которого был рассчитан только на пять.
• Технический долг — это трещины в несущих стенах, кривые перекрытия и старая проводка, которую залицевали гипсокартоном. Чем выше мы строим, тем опаснее становятся эти трещины.
• Рефакторинг (улучшение кода) - это не «ничегонеделание». Это плановый капитальный ремонт и усиление фундамента, без которого новую пристройку (фичу) не сделать, а старое здание может рухнуть в любой момент.

2. Аналогия с автомобилем
Ваш продукт - это автомобиль, который едет в гонке (на рынке).

• Технический долг - это когда вы месяцами или годами пропускаете плановое ТО: не меняете масло, изнашиваете шины, игнорируйте стук в подвеске.
• «Просто кнопка» - это требование увеличить максимальную скорость на 20%.
• Что будет? Вы либо сядете менять масло и ремонтировать двигатель прямо посреди гонки (сняв машину с трассы), либо на полном ходу у вас откажут тормоза. Быстро и дешево - не получится. Нужно сначала привести машину в порядок.

3. Аналогия с долговой ямой (финансовая)

• Каждое быстрое и грязное решение - это микрокредит под грабительские проценты.
• Если вы продолжаете брать такие кредиты, не возвращая старые, вы попадаете в долговую яму, где все ресурсы команды уходят на выплату процентов (исправление багов, обходы костылей), а не на создание новой ценности для клиентов.

Не говорите: «У нас плохой код». Говорите о бизнес-рисках и потерях денег.
Скорость разработки падает (время выхода на рынок увеличивается).

• Что сказать: «Помните, раньше новая фича появлялась за 2 недели? Сейчас на аналогичную уходит 6. Не потому что команда плохая, а потому что каждый раз мы «прочищаем завалы» старого кода. Долг съедает нашу скорость. Если мы его не вернем, через полгода любое изменение будет занимать месяцы».
• Для кого подходит: для команд, выпускающих продукт, который непосредственно генерируют продажи, например, сайты электронных магазинов.

Растут операционные расходы (OPEX).

• Что сказать: «Система стала нестабильной. Количество инцидентов и багов выросло на 40%. Это значит, что наши лучшие инженеры вместо разработки новых функций, за которую нам платят клиенты, постоянно тушат пожары. Мы платим им премию за инновации, а они работают аварийной службой».
• Для кого подходит: для in house команд, которые заинтересованы в уменьшении затрат головной компании.

Риск потери репутации и клиентов.

• Что сказать: «При высоком долге любой, даже маленький, апдейт может сломать критически важную функцию. Представьте, что из-за нашей «простой кнопки» у тысячи клиентов перестанет работать оплата. Мы потеряем не только деньги, но и доверие».
• Для кого подходит: для всех (можно адаптировать под любую схему работы с бизнесом).

Невозможность масштабирования и инноваций.

• Что сказать: «У нас есть возможность запустить крутую AI-фичу, которая даст нам преимущество на рынке. Но наша текущая архитектура ее не выдержит. Чтобы даже начать, нам нужно 3 месяца на ее переделку. Пока конкуренты уже запустят свое решение».
• Для кого подходит: для команд, выпускающих продукт, который непосредственно генерируют продажи, например, сайты электронных магазинов.

1. Говорите на языке цифр и дорожных карт.

• Нельзя: «Нам надо месяц чистить код».
• Надо: «Вот диаграмма, как падает наша скорость (velocity). Вот статистика инцидентов. Чтобы выйти на плановые показатели по новому квартальному OKR (например, запустить 5 крупных фич), нам необходимо выделить 20% времени каждого спринта на сокращение долга. Иначе мы рискуем выполнить только 3».

2. Легализуйте «платежи по долгу».
Предложите простые механизмы:

• Правило 80/20: 80% времени спринта - на новые фичи, 20% - на обслуживание долга.
• «Долговые» спринты: Раз в квартал проводить спринт, полностью посвященный техническому здоровью продукта. Презентуйте его не как затраты, а как инвестицию в будущую скорость.
• Привязка к каждой фиче: При планировании любой новой функции оценивать и включать в сроки «стоимость входа» - рефакторинг связанного модуля.

3. Предлагайте выбор, а не ультиматум.
Сформулируйте вопрос как бизнес-решение:

• «У нас есть три пути:

1. Быстро добавить кнопку за 3 дня, но это увеличит общий долг. Мы предполагаем, что это замедлит следующие 5 фич на 2 недели в сумме и увеличит риск сбоя на 15%.
2. Сделать качественно за 10 дней, заодно улучшив платформу. Следующие фичи пойдут быстрее. Это - инвестиция.
3. Не делать кнопку сейчас, а сделать ее частью крупного обновления через месяц, сэкономив ресурсы.

Давайте вместе выберем вариант, который лучше соответствует нашим стратегическим целям.»

Объяснение технического долга - это не оправдание, а профессиональная ответственность руководителя.
Ваша задача - перевести проблему «плохого кода» в плоскость бизнес-рисков, финансовых потерь и упущенных возможностей. Когда бизнес понимает, что технический долг - это не «лень программистов», а взятый ранее кредит на скорость, по которому пришел срок платить, диалог становится конструктивным.
Превратите технический долг из таинственного оправдания в управляемый метрикой бизнес-инструмент. И тогда фраза «это просто кнопка» перестанет быть кошмаром, а станет началом взрослого разговора о качественной разработке, где скорость сегодня не убивает возможность расти завтра.