Как ты объясняешь техдолг менеджеру или продакту?
Что проверяют
Умеете ли вы переводить инженерные проблемы на язык бизнеса и договариваться, а не жаловаться. «Код некрасивый, надо переписать» — не аргумент; «следующие три фичи займут вдвое дольше и вот почему» — аргумент.
Скелет ответа
- Язык последствий: техдолг = скорость фич, количество багов, риск инцидента, время онбординга. Никакой терминологии вроде «retain cycle» — только эффект.
- Цифры: сколько времени уходит на обход проблемы сейчас, сколько — на исправление, сколько багов из этой зоны за квартал.
- Стоимость бездействия vs стоимость исправления — и когда они пересекутся.
- План без остановки разработки: рефакторинг долями внутри фич, Boy Scout rule, 10–20% спринта, feature flag для безопасного переключения.
- Согласованные критерии: что считаем «сделано», как измерим.
Пример ответа
S: Сетевой слой на колбэках с ручным парсингом JSON; каждая новая фича с API требовала 2–3 дня на обвязку и давала баги с потоками.
T: Убедить продакта выделить время на переход на async/await + Codable при плотном роадмапе.
A: Собрал данные за квартал: 6 багов из сетевого слоя, 11 дней на обвязку новых эндпоинтов. Пришёл не с «надо переписать», а с предложением: три ближайшие фичи уже затрагивают 70% эндпоинтов — делаем их на новом слое, старый сносим по мере миграции, без отдельного «спринта рефакторинга». Риски обозначил: первая фича выйдет на 2 дня позже.
R: Продакт согласился, потому что видел цифры и план без остановки. Через два месяца обвязка эндпоинта занимала полдня, багов из этой зоны за следующий квартал — один.