Технический долг: как объяснить бизнесу, зачем его платить
Разговор о техническом долге между разработкой и бизнесом часто заходит в тупик. Инженеры говорят «нам нужно отрефакторить», менеджеры слышат «мы хотим потратить время непонятно на что». Результат предсказуем: долг растёт, пока однажды всё не начинает ломаться.
Метафора долга, которую придумал Ward Cunningham, на самом деле очень удачная для разговора с бизнесом. Любой руководитель понимает, что такое кредит и проценты. Проблема в том, что технические команды редко переводят свои проблемы в эти термины.
Почему «нужен рефакторинг» не работает
В одном крупном российском банке команда платформы два года просила время на переработку легаси-модуля процессинга. Каждый квартал на стратегическом планировании они показывали слайд с архитектурной схемой и объясняли, почему текущая структура «неправильная». Бизнес каждый раз отвечал одинаково: «Работает же, давайте лучше новые фичи».
Ситуация изменилась, когда tech lead начал собирать другие данные. Он показал, что время добавления новой платёжной интеграции выросло с двух недель до шести за последний год. Что количество инцидентов в этом модуле растёт на 15% в квартал. Что каждый инцидент обходится в среднем в четыре часа работы дежурной команды. Вместо абстрактного «нужен рефакторинг» появилась конкретная история про деньги и скорость.
Метрики, которые слышит бизнес
Бизнесу неинтересна «чистота кода». Бизнесу интересна скорость доставки, стоимость поддержки и частота сбоев. Вот несколько метрик, которые помогают вести разговор на понятном языке.
Lead time для новых фич. Если типовая задача, которая раньше занимала три дня, теперь занимает десять - это осязаемый эффект долга. Полезно отслеживать тренд по кварталам.
Время на поддержку vs. развитие. Какой процент спринта уходит на баги и инциденты, а какой на новую функциональность? Когда бизнес видит, что 40% мощности команды тратится на «тушение пожаров», вопрос о рефакторинге звучит иначе.
Стоимость инцидентов. Каждый инцидент - это время инженеров, простой для пользователей, иногда прямые финансовые потери. Перевод в рубли делает проблему вещественной.
Скорость онбординга. Сколько времени нужно новому разработчику, чтобы начать вносить изменения в модуль? Если ответ «два месяца», это тоже форма процентов по долгу.
Когда платить, а когда жить с долгом
Важно понимать, что технический долг бывает стратегическим. Иногда осознанное решение «сделать попроще сейчас» - правильное, если это позволяет проверить гипотезу или успеть к сроку. Проблемы начинаются, когда долг накапливается неосознанно и никто не отслеживает его влияние.
Есть простой ориентир. Если долг замедляет команду в конкретной области, которая активно развивается, его стоит платить. Если модуль стабилен и изменения в нём редки, с долгом можно жить годами, даже если код выглядит некрасиво.
Полезная практика - завести «реестр долга» с оценкой влияния на бизнес-метрики. Это снимает эмоции из дискуссии и превращает её в обычное экономическое решение.
Как встроить в процесс
Некоторые команды резервируют фиксированный процент ёмкости спринта на работу с долгом. Другие выделяют отдельные «технические спринты». Оба подхода работают, если бизнес понимает, зачем это нужно. Постоянный небольшой поток обычно предпочтительнее, потому что позволяет работать с долгом в контексте текущих задач, а значит, снижать его именно там, где это принесёт наибольший эффект.
Главное - сделать долг видимым. Пока он существует только в головах разработчиков, бизнес будет воспринимать просьбы о рефакторинге как каприз.
Если хотите разобраться в метриках потока и научиться строить прозрачность для бизнеса, посмотрите программу Agile Project Management. А для комплексного погружения в agile-практики есть Certified Agile Professional.