Спринт, не давший ни новой кнопки, ни новой страницы, ничего, что клиент когда-либо увидит, — один из самых трудных пунктов для владельца бизнеса, чтобы его утвердить: выглядит как плата ни за что. Почти никогда это не так. Обычно это счёт, пришедший к оплате за срезанный угол, сделанный месяцы назад ради дедлайна, который тогда значил больше, чем код под ним.
Аналогия с кредитом, сделанная конкретной
Технический долг — это ровно то, чем звучит: кредит против будущей скорости разработки, взятый ради ускорения сегодня. Функция, построенная быстрым способом вместо надёжного, выходит раньше, что часто правильное решение под реальным дедлайном — но, как любой кредит, он начисляет проценты. Каждая будущая функция, затрагивающая ту же часть системы, строится дольше, потому что разработчику сначала приходится обходить срезанный угол, а не строить чисто на твёрдой земле.
Почему это не отражается на дорожной карте так, как функции
У новой функции есть демо. У исправления бага есть «до и после». У погашения технического долга нет ни того ни другого — видимый результат хорошо сделанной работы в том, что всё построенное после идёт быстрее и реже ломается, что по определению невидимо, потому что альтернатива (всё остаётся медленным и ломающимся) ни для кого не случилась, чтобы сравнить. Именно эта невидимость делает его самым лёгким пунктом для вырезания из дорожной карты под давлением — и именно поэтому повторное вырезание превращает управляемый кредит в кредит, реально угрожающий бизнесу.
Процентная ставка не одинакова везде
Не весь технический долг стоит одинаково в обслуживании. Срезанный угол в стабильном, редко затрагиваемом уголке системы может тихо лежать годами, ничего значимого не стоя, а такой же срезанный угол в части системы, через которую должна проходить каждая новая функция, накапливается быстро — из-за него замедляется каждая несвязанная работа. Полезный вопрос — не «сколько у нас технического долга» в абстракции, а «какой конкретный долг лежит на пути того, что мы строим следующим», потому что именно его действительно стоит погашать сейчас.
Как конкретно выглядит «погашение»
Это переписывание куска кода, который работает, но хрупок, чтобы следующие три функции, построенные рядом с ним, не унаследовали эту хрупкость. Это замена ручного обходного решения, которое команда тихо повторяла каждую неделю, чем-то автоматизированным. Это распутывание зависимости, из-за которой конкретный вид изменения занимал втрое больше времени, чем должен был, каждый раз. Ничто из этого не эффектно, и всё это позже проявляется в виде функций, выходящих быстрее, чем вышли бы иначе.
Как понять, стоит ли это делать прямо сейчас
Честный тест прост: замедляет ли этот конкретный долг реальную, запланированную работу прямо сейчас, или это теоретическая уборка без ближайшей стоимости. Первое стоит приоритезировать, даже без видимого результата для демонстрации; второе обычно может подождать, потому что не весь долг требует немедленного погашения — только тот, что активно облагает налогом следующую вещь, которую вы строите.
Это часть того же разговора, что и купить, построить или настроить — долгосрочная стоимость системы это не только то, что стоило её построить, а то, что стоит продолжать строить поверх неё.
Наша команда разработки отмечает технический долг в момент его создания и явно оценивает стоимость его погашения, чтобы это было видимым, запланированным решением, а не тихим налогом, на который никто не соглашался.
