Технический долг: как объяснить бизнесу, зачем тратить на него время
У нас сейчас многие компании проходят через один и тот же этап. Быстро собрали MVP, вышли на рынок, начали расти, привлекли инвестиции, наняли ещё людей. И вот команда выросла с пяти до тридцати человек, а кодовая база осталась той, что писали на скорость два года назад. Каждая новая фича занимает всё больше времени, баги множатся, а разговор с фаундером про «технический долг» натыкается на «мы сейчас растём, давайте потом».
Это не чья-то ошибка. Скорость на ранних этапах - осознанный выбор, и часто правильный. Но наступает момент, когда проценты по этому долгу начинают съедать способность расти дальше. И задача инженерной команды - объяснить это на языке, который бизнес понимает.
Перевести на язык денег и скорости
Одна продуктовая команда в казахстанском финтехе столкнулась с типичной проблемой. Их платёжный модуль был написан за три месяца как прототип и с тех пор «оброс» десятками интеграций. Каждая новая интеграция требовала всё больше ручной работы, а тесты проходили по два часа. Когда команда пришла к CEO с просьбой «переписать платёжный модуль», ответ был ожидаемым: зачем тратить квартал на то, что и так работает?
Подход изменился, когда ребята собрали конкретные цифры. Время подключения нового платёжного провайдера выросло с двух недель до полутора месяцев. За последний квартал было семь инцидентов в этом модуле, каждый стоил команде в среднем шесть часов. А два из них привели к кратковременным простоям для пользователей. Когда CEO увидел тренд и посчитал, сколько это стоит в часах команды и в потерянных транзакциях, разговор пошёл совсем иначе.
Какие метрики работают
Для растущих компаний, где рост в абсолютном приоритете, аргументы вроде «чистый код» или «правильная архитектура» просто не находят отклика. Нужны метрики, привязанные к скорости и стоимости.
Замедление delivery. Сколько времени уходило на типовую задачу полгода назад и сколько сейчас? Если тренд восходящий, это прямое влияние долга на способность компании расти.
Доля времени на поддержку. Какой процент ёмкости команды уходит на баги, инциденты и ручную работу? У нас в быстрорастущих компаниях бывает, что половина спринта уходит на «тушение пожаров», а бизнес при этом ждёт новых фич.
Онбординг новых людей. Когда команда растёт, скорость вхождения новичков становится критичной. Если новый разработчик два месяца разбирается в коде, прежде чем может что-то сделать, это конкретная цена долга, измеримая в зарплатах.
Количество и стоимость инцидентов. Каждый сбой - это потерянные пользователи, время дежурных инженеров и репутационные риски. Особенно чувствительно для финтеха и e-commerce, где у нас конкуренция за доверие пользователей растёт.
Когда долг - это нормально
Важно не впасть в крайность. Технический долг бывает стратегическим. Если компания проверяет гипотезу на новом рынке, осознанное упрощение - разумный выбор. Проблема возникает, когда долг накапливается неосознанно и его влияние никто не замеряет.
Полезное правило: если область кода активно развивается и долг в ней замедляет команду, его стоит сокращать. Если модуль стабилен и меняется раз в полгода, можно жить с некрасивым кодом без последствий.
Встроить в ритм работы
Многие наши команды приходят к модели, когда небольшой процент ёмкости каждого спринта выделяется на работу с долгом. Это работает лучше, чем отдельные «технические спринты», потому что позволяет чинить именно то, что мешает прямо сейчас. А для бизнеса такой подход прозрачнее - видно, что команда одновременно и развивает продукт, и поддерживает его здоровье.
Самое ценное, что может сделать техническая команда, - сделать долг видимым. Завести реестр, привязать к бизнес-метрикам, регулярно показывать тренды. Когда решение о долге становится экономическим, договариваться с бизнесом значительно проще.
Если хотите глубже разобраться в метриках потока и прогнозировании, посмотрите программу Agile Project Management. Для системного погружения в agile-практики подойдёт Certified Agile Professional.