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