Есть разговор, который повторяется в самых разных компаниях с удивительным постоянством, инженерная команда настаивает на необходимости выделить время на устранение накопленных технических компромиссов, а руководство компании, слыша абстрактный термин технический долг, вежливо кивает, но раз за разом отдает приоритет более понятной, более осязаемой новой функциональности. Разберемся, почему этот разговор так часто заканчивается ничем, и как реально изменить его исход. Фундаментальная причина подобного затянувшегося непонимания кроется в том, что сам термин технический долг звучит для нетехнической аудитории слишком абстрактно, слишком далеко от понятных бизнесу категорий выручки, роста и конкурентного преимущества. Руководитель, отвечающий за коммерческий успех компании, вполне резонно предпочитает инвестировать ограниченные ресурсы в нечто, что он способен содержательно понять и оценить, а абстрактная формулировка вроде накопленной сложности кода или устаревшей архитектуры этому пониманию попросту не способствует. Первый и, пожалуй, самый действенный шаг к изменению этой ситуации состоит в полном отказе от абстрактной технической терминологии в пользу конкретных, измеримых последствий, понятных на языке самого бизнеса. Вместо разговора об абстрактном техническом долге стоит говорить о конкретном, реально измеренном увеличении времени, необходимого команде для реализации типичной новой функциональности, по сравнению с тем, сколько времени эта же самая команда тратила на аналогичные задачи год или два назад. Подобное конкретное, измеримое замедление значительно убедительнее абстрактного упоминания накопленной технической сложности, потому что напрямую связано с той самой скоростью вывода новых продуктов на рынок, которая волнует руководство компании куда сильнее абстрактных технических категорий. Перевод накопленного технического долга на язык конкретного, вероятностного риска серьезного производственного инцидента представляет собой второй важный элемент подобного перевода. Компания, наглядно видящая, что определенный участок унаследованной инфраструктуры регулярно становится источником повторяющихся, дорогостоящих инцидентов, значительно охотнее выделяет ресурсы на его пересмотр, чем компания, слышащая лишь абстрактное утверждение, что данный участок кода недостаточно чист архитектурно. Демонстрация конкретных, уже реализованных примеров того, как устранение определенной, конкретной части технического долга реально ускорило последующую разработку или реально предотвратило конкретный класс инцидентов, представляет собой третий мощный элемент убеждения, значительно превосходящий по силе воздействия любые теоретические, абстрактные аргументы о важности хорошей архитектуры. Руководство компании, однажды увидевшее реальную, измеримую пользу от подобной инвестиции, значительно охотнее соглашается на аналогичные будущие инвестиции, чем руководство, вынужденное каждый раз верить в исключительно теоретическое обещание будущей пользы. Явная привязка накопленного технического долга к конкретным, уже запланированным бизнес-инициативам представляет собой четвертый практический прием, значительно облегчающий подобный разговор. Вместо абстрактного, оторванного от конкретного контекста запроса на устранение технического долга вообще значительно эффективнее содержательно продемонстрировать, что конкретная, уже запланированная бизнес инициатива объективно потребует значительно больше времени и будет нести значительно больший риск именно из за конкретного, накопленного технического долга в той части системы, которую эта инициатива затрагивает, что делает абстрактный вопрос немедленно конкретным и срочным именно в контексте уже согласованного бизнес приоритета. Регулярность подобной коммуникации, а не разовое обращение исключительно в момент, когда команда уже отчаянно нуждается в подобной инвестиции, тоже заслуживает отдельного внимания.