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