Технический долг в деньгах: как я объясняю рефакторинг без слова «архитектура»
Первые три раза я объяснял рефакторинг через «архитектуру» — и получал вежливое «окей, но давайте сначала сделаем фичи». Потом я поменял одну вещь: вместо «архитектурного долга» сказал «вот эта часть системы сейчас стоит нам дополнительных 6 часов на каждый новый тип доставки. За квартал это 60 часов, которые мы теряем». Клиент ответил: «ладно, выдели неделю».
Слово «архитектура» я с тех пор не использую в разговорах с клиентами. Не потому что оно плохое. Просто оно работает против нас.
Почему слово «архитектура» работает против нас
Когда разработчик говорит «архитектура», клиент слышит примерно следующее: «вам нужно заплатить за что-то непонятное, что сломалось по непонятной причине, и после починки вы не увидите никаких изменений».
Не предположение — наблюдение. «Архитектура» — термин технический, обслуживающий, непродуктовый. У него нет очевидного финансового следствия. Тот, кто оплачивает работу, автоматически переводит его в категорию «внутренние дела разработчика».
Даже если клиент технически грамотный — CTO, product owner, самостоятельный владелец e-commerce — разговор про «архитектуру» всё равно ставит его в позицию наблюдателя. Он должен верить вам на слово. А это неудобная позиция для человека, который несёт ответственность за бюджет.
Разработчик с owner mindset переводит технический долг иначе: не «это плохо устроено», а «это дорого обходится». И не абстрактно дорого, а в конкретных часах, неделях, или потенциальных инцидентах.
Три числа, которые клиент слышит
Не все метрики одинаково убеждают. После нескольких итераций я остановился на трёх:
Время на следующую фичу. Самое прямое. «Сейчас добавление нового типа доставки занимает 6 часов из-за hardcoded логики. Если мы вынесем это в конфиг — станет 40 минут». Клиент считает: у нас три типа доставки в год, значит сейчас мы платим 18 часов сверху. За три года — 54 часа.
Частота инцидентов. Сложнее продать, но работает если в истории есть конкретный случай. «В прошлом квартале этот модуль ломался дважды. Каждый раз — 4 часа на восстановление плюс поддержка клиентов». Это уже не абстрактный «долг», это наблюдаемые потери.
Стоимость восстановления при критическом сбое. Самое жёсткое, но иногда единственное, что работает для давно накопленного долга. «Если этот компонент упадёт в сезон, нам нужно минимум 3 дня, чтобы его поднять. Это X рублей потерянных продаж».
Не нужно использовать все три сразу. Одного достаточно — если цифра реальная и поддаётся проверке.
Как посчитать долг в часах
Перед разговором с клиентом я делаю одно упражнение: беру любую задачу из последних двух спринтов, в которой была задержка или неожиданная сложность, и разбираю, где именно потеряли время.
Обычно выясняется одно из трёх:
- часть логики hardcoded там, где должен быть конфиг или параметр;
- нет тестов на граничные случаи, поэтому каждое изменение требует ручной проверки;
- два модуля знают друг о друге напрямую, и изменение в одном ломает второй неочевидным образом.
Для каждого из этих случаев можно дать оценку: «сколько часов мы потратили на это в этот раз» и «сколько будем тратить на это каждый раз в будущем, если не исправить».
Пример: в одном из Bitrix-проектов был компонент управления доставкой — список типов доставки был захардкожен прямо в PHP-шаблоне. Добавление нового типа требовало правок в четырёх местах вместо одного, без ни одного теста. Каждое добавление занимало ~6 часов с проверкой. Переписали компонент за 2 дня — последующие добавления стали занимать меньше часа.
Когда я принёс эту цифру клиенту, разговор занял 10 минут.
Фреймворк разговора: симптом → цифра → предложение
Структура, которая у меня работает, простая:
Первое: называю симптом, который клиент уже замечал. Не «у нас архитектурный долг», а «помните, мы три раза переделывали форму доставки?» или «вы спрашивали, почему последний релиз занял неделю вместо двух дней?»
Второе: даю цифру. Одну, конкретную, с единицами. «Вот эта часть системы добавляет примерно 6 часов к каждому подобному изменению».
Третье: предлагаю конкретное вложение. Не «нам нужно отрефакторить архитектуру», а «за 16 часов работы мы это убираем, и следующие три задачи этого типа суммарно займут на 12 часов меньше — то есть окупится при третьей задаче».
Это не манипуляция. Это честный язык. Клиент и так несёт эти потери, просто не видит, откуда они берутся. Ваша работа — сделать это видимым.
Ещё один момент: ссылайтесь на реальные задачи, а не на гипотетические. «Последний раз такая задача стоила нам 6 часов» работает лучше, чем «обычно такие задачи занимают около 6 часов».
Когда рефакторинг не надо продавать
Иногда разговор не нужен. Если изменение небольшое и можно сделать его в рамках текущей задачи — просто делайте. Это то, что называют Boy Scout Rule: оставь код чуть лучше, чем нашёл, не ставя каждую правку в бэклог.
Продавать рефакторинг имеет смысл когда: работа занимает больше половины спринта, нужно останавливать другие задачи, или затрагивается критический путь. Всё остальное — часть нормальной инженерной работы.
Кроме того: если каждый разговор про технический долг превращается в переговоры, это сигнал не про долг, а про доверие. В долгосрочных проектах часть решений должна приниматься инженером без объяснений — это и есть ответственность. Как я писал в прошлой статье про риски: задача не в том, чтобы закрыть тикет, а в том, чтобы закрыть риск — иногда это одно и то же, иногда нет.
Формулировки, которые сработали
Несколько реальных конструкций из переписок:
«Этот компонент прибавляет к любой связанной задаче около Х часов. Если в следующем квартале у нас 3 таких задачи, мы платим примерно [3×X]. Я могу убрать это за [Y] часов сейчас.»
«В прошлом месяце этот модуль стоил нам [Z] часов на инциденте. Если хотите — могу описать, что нужно сделать, чтобы такого не повторилось.»
«Мы можем выпустить это сейчас, но тогда следующие две задачи в этой области займут в два раза дольше. Ваш выбор.»
Последнее работает особенно хорошо: оно не ставит клиента в позицию «ты виноват», а даёт выбор. И часто клиент сам спрашивает: «а сколько займёт нормально сделать?»
Замените «архитектуру» на деньги и время — и половина возражений исчезнет сама.