Технический долг как управленческое понятие
Как думать о техническом долге не как о жалобе инженеров, а как о реальном активе с процентами - и что с этим делать.
"Технический долг" - это термин, который инженеры используют в разговорах с менеджментом и часто не получают ожидаемой реакции. Менеджер слышит что-то абстрактное про качество кода. Инженер имеет в виду накопившиеся решения, которые замедляют всё новое - и этот паттерн проявляется в data-пайплайнах не менее остро, чем в коде приложений.
Метафора долга здесь точнее, чем кажется. И если понять её правильно, это меняет разговор.
Что это такое на самом деле
Технический долг - это совокупность технических решений, которые были сделаны быстро или дёшево в прошлом, но которые теперь требуют дополнительных усилий при каждом изменении системы.
Примеры выглядят обыденно: код написан так, что добавление одной функции требует изменений в десяти местах; данные хранятся без структуры, и каждый аналитик выгружает их по-своему; интеграции сделаны точечными соединениями, и ни одно изменение нельзя сделать, не сломав что-то рядом.
Это не абстракция. Это конкретные вещи, которые можно перечислить, приоритизировать и измерить в единицах замедления - насколько дольше занимает разработка из-за каждого из них.
Почему метафора долга работает
Долг имеет тело и проценты. Технический долг устроен так же.
Тело - это работа, которую нужно сделать, чтобы "выплатить" долг: переписать компонент, унифицировать интеграцию, навести порядок в данных.
Проценты - это дополнительные затраты, которые компания несёт каждый раз, работая с этой частью системы. Каждый новый релиз стоит дороже, каждый инцидент длится дольше, каждый новый разработчик дольше входит в контекст.
Некоторый долг берётся намеренно. "Нам нужно выпустить к дедлайну - разберёмся потом" - это явное решение взять в долг. Проблема возникает тогда, когда "потом" никогда не наступает, а проценты продолжают накапливаться.
Как это влияет на решения
Руководители часто удивляются, почему разработка замедляется, хотя команда та же или даже выросла. Накопленный технический долг - одна из главных причин.
Когда долг значительный, каждая новая функция реализуется медленнее, чем предыдущая. Исправление одной ошибки создаёт две новых. Оценки не выполняются не потому, что команда плохо работает, а потому что реальная сложность задач выше, чем видно снаружи.
Игнорировать это - значит принимать решения о скорости разработки, не имея полной картины.
Что делать практически
Первый шаг - визуализировать долг. Попросить команду перечислить конкретные элементы технического долга с оценкой их влияния. Это не жалоба - это инвентаризация рисков.
Второй шаг - понять стоимость. Сколько времени ежемесячно тратится на работу вокруг каждой проблемы? Умножьте на ставку разработчика - вот ориентировочная стоимость в деньгах.
Третий шаг - принять явное решение. Полностью игнорировать долг или погашать его весь сразу - обе крайности неверны. Нормальная практика - выделять на работу с долгом часть производительности команды на постоянной основе. Обычно называют 10-20% времени спринта.
Четвёртый шаг - связать решения о долге с деловыми приоритетами. Не "давайте перепишем вот этот модуль потому что он некрасивый", а "этот компонент находится на пути у трёх ключевых инициатив следующего квартала - его стоит починить до того, как мы начнём".
Технический долг - это управленческое решение, даже когда менеджер о нём не знает. Что технический долг означает конкретно для нетехнических руководителей - и как выстроить продуктивный разговор об этом с советом директоров - это отдельная задача, которая начинается с правильного фрейминга.