Классический кейс на собесе тимлида: «бизнес хочет фичи, а команда тонет в техдолге». Слабый ответ: «объясню бизнесу, что рефакторинг важен». Сильный: «покажу цену долга в деньгах и сроках и договорюсь о системном бюджете».
Что такое техдолг
Уорд Каннингем придумал метафору: быстрое решение сегодня это заём, а «проценты» платятся каждый раз, когда приходится работать с этим кодом медленнее. Долг не всегда плох: осознанный долг ради выхода на рынок бывает правильным решением.
Квадрант Мартина Фаулера помогает классифицировать:
- Осознанный и разумный: «выпускаем сейчас, перепишем после проверки гипотезы».
- Осознанный и безрассудный: «на тесты нет времени».
- Неосознанный и безрассудный: команда не знала, как правильно.
- Неосознанный и разумный: «теперь мы понимаем, как надо было», знание пришло с опытом.
Виды долга: код и архитектура, устаревшие зависимости, отсутствие тестов, ручные процессы (релизы, окружения), отсутствие мониторинга, документация.
Как измерить и показать
Бизнесу не важна «чистота кода», ему важны деньги, сроки, риски. Переводите на этот язык:
- Скорость: фичи в модуле X занимают в 3 раза дольше, чем в других. Lead time растёт квартал к кварталу.
- Качество: 40% инцидентов приходят из одного сервиса. Сколько часов в месяц уходит на ручные починки.
- Риски: библиотека без поддержки с известными уязвимостями, версия базы снимается с поддержки, один человек знает модуль.
- Люди: разработчики не хотят трогать модуль, онбординг дольше.
Каждый пункт долга полезно описать как обычную задачу бэклога: проблема, цена бездействия, стоимость исправления, ожидаемый эффект.
Как договориться
- Постоянный бюджет: 15-25% ёмкости каждого спринта на техдолг и устойчивость. Без защиты бюджет съедят фичи.
- Правило бойскаута: оставлять код чуть лучше, чем нашли, в рамках задач.
- Долг рядом с фичей: рефакторинг модуля включается в оценку фичи, которая его трогает.
- Крупный долг как проект с бизнес-обоснованием и вехами, а не «перепишем всё за полгода».
- Регистр долга: список с оценкой цены и стоимости, пересматривается раз в квартал.
Плохие стратегии: тайный рефакторинг под видом фич (подрывает доверие), «спринт техдолга» раз в год (долг копится быстрее), переписать с нуля без веских причин.
Приоритизация
Когда задач больше, чем ёмкости, нужна общая шкала, по которой спорят о цифрах, а не о вкусах.
- RICE:
Reach × Impact × Confidence / Effort. Охват (сколько пользователей за период), влияние (например 0,25-3), уверенность (50-100%), трудозатраты (человеко-месяцы). Пример: 2000 × 2 × 0,8 / 4 = 800. - WSJF (из SAFe):
Cost of Delay / Job Size, где стоимость задержки складывается из ценности для бизнеса, срочности и снижения риска. Выигрывают задачи, которые дорого откладывать и дёшево сделать. - Стоимость задержки: сколько теряем за каждую неделю, пока задача не сделана. Помогает сравнивать фичи и долг в одних единицах.
- MoSCoW: must, should, could, won't. Грубо, но быстро для скоупа релиза.
Оценки в формулах субъективны, но заставляют проговорить допущения. Это главное их достоинство.
Частые ошибки
- Говорить с бизнесом на языке «код плохой».
- Требовать «квартал на рефакторинг» без вех и измеримого результата.
- Держать долг в голове, а не в бэклоге.
- Приоритизировать по громкости заказчика.
Что спросят на собесе
- Бизнес хочет фичи, команда тонет в техдолге. Что вы сделаете.
- Как вы объясните бизнесу, зачем тратить время на техдолг.
- Сколько ёмкости вы закладываете на долг и почему.
- Как вы приоритизируете бэклог: какие инструменты.
- Когда переписывать систему с нуля оправдано.