Технический долг — накопленные упрощения в сайте, программах и настройках, которые когда-то ускорили запуск, а теперь удорожают каждое следующее изменение. Код написан наспех, цена товара ведётся в двух местах, обновления откладывались. Само по себе это не поломка, но любая правка поверх такой основы стоит дороже и делается дольше.
Долгом это называют из-за процентов. Тело долга — те несколько дней, что сэкономили на запуске. Проценты — надбавка к каждой задаче после: правка, которая год назад занимала 2 дня, теперь занимает неделю, и половина времени уходит на проверку, что ничего не отвалилось. Пока платежи мелкие, их не замечают. Заметными они становятся, когда доработка одного поля обходится в стоимость нового раздела.
Что считать техническим долгом, а что нет#
Долг — не любой беспорядок. Отличить его можно по одному признаку: мешает ли решение вносить изменения. Сайт с устаревшим дизайном работает и правится нормально, это вопрос вкуса. А вот сайт, где цена товара хранится в 3 местах и при каждой акции её правят вручную, — долг: каждая акция стоит лишних часов и одной ошибки.
Второе отличие — от ошибки. Ошибка ломает работу прямо сейчас: форма не отправляется, оплата не проходит. Долг сегодня не ломает ничего, он повышает цену завтрашних изменений. Поэтому ошибки чинят немедленно, а долг откладывают в план — и по той же причине про него забывают, пока он не начнёт мешать выручке.
Типовой набор у малого бизнеса выглядит одинаково: тестовой копии сайта нет, поэтому правки проверяют на живом; движок и плагины не обновлялись год; пароли и доступы держит один человек; настройки живут в голове подрядчика, а не в документах. Сегодня не мешает ничего из перечисленного.
Проверить себя можно за полчаса. Возьмите 3 последние доработки и спросите исполнителя, на что ушло больше всего времени. Если в ответах повторяется «пришлось разбираться, как тут сделано» или «поправили в одном месте, сломалось в другом» — вы уже платите проценты.
Откуда берётся долг и кто его создаёт#
Первый источник — срок. Запуск к сезону, выставка через месяц, обещание клиенту. Быстрый путь выбирают осознанно, и это нормально: часть решений и должна быть временной. Беда начинается там, где временное не записали и не назначили дату возврата, — тогда «пока так» превращается в «всегда так».
Второй — размытая постановка. Когда задача звучит как «сделайте, чтобы было удобно», исполнитель достраивает недостающее по-своему, а через месяц выясняется, что нужно иначе. Переделка ложится поверх уже написанного, слоёв становится больше. Как формулировать, чтобы не платить дважды, разобрано в материале про постановку задачи разработчику.
Третий — смена рук. Каждый новый исполнитель приносит свой стиль и свои инструменты, а разбираться в чужом ему дороже, чем написать рядом заново. После 2–3 подрядчиков в проекте сосуществуют несколько подходов, и работает только то, что никто не трогает.
Четвёртый — рост. Схема, собранная под 20 заказов в день, при 200 начинает подтормаживать, а при 2000 встаёт совсем. Долгом становится решение, верное для прежнего масштаба. Виноватых тут нет: у любой схемы есть срок годности, и лучше знать о нём заранее.
Почему цена долга растёт каждый месяц#
Первая причина — наслоение. Новая функция опирается на старую основу, и кривизна основания копируется наверх. Один обход правила рождает второй, третий делают уже по образцу. Через год исправление в фундаменте задевает не одно место, а десяток, и каждое надо отдельно проверить.
Вторая — память. Решения помнят люди, а люди уходят. Пока автор рядом, странный кусок объясняется за 5 минут. Когда автора нет, а документации не было изначально, каждая правка начинается с раскопок, и они оплачиваются по обычной ставке. Самая незаметная и самая стабильная статья роста цены.
Третья — окружение. Версии движка, библиотек и платёжных модулей выходят из поддержки, сервисы меняют свои интерфейсы. Пока обновления ставят регулярно, каждое из них мелкое и почти бесплатное. Когда их не ставили 2 года, обновление превращается в отдельный проект с переносом и перепроверкой всего.
Четвёртая — сужение выбора. У свежего долга есть дешёвые варианты: переписать один модуль, вынести настройку наружу, добавить проверку. У застарелого остаётся один путь — переделывать целиком, и уже не в спокойное время, а когда всё встало. Аварийный ремонт всегда дороже планового.
Как измерить долг и что чинить первым#
Считать долг строками кода бессмысленно, владельцу нужны часы и риски. Попросите исполнителя выписать список: что сделано временно, что мешает изменениям, что давно не обновлялось. Список почти всегда выходит длиннее, чем ожидает владелец: туда попадает и временная заглушка, поставленная перед запуском, и забытая настройка, и модуль, который держится на честном слове. Пугаться длины не стоит — заметная часть пунктов может годами ждать своей очереди и никому не мешать. Ценность списка не в размере, а в том, что долг перестаёт быть ощущением «там всё плохо» и превращается в перечень, который можно разобрать по порядку.
Дальше — приоритет по 3 признакам: как часто это место трогают, чем грозит поломка, сколько стоит починка. Наверх идёт то, к чему возвращаются каждую неделю и что стоит на пути денег: оформление заказа, оплата, выгрузка в учёт. Отдельной строкой — отсутствие резервных копий и версии без поддержки: тут риск не в скорости, а в остановке.
Ниже — то, что раздражает, но не мешает: неудобная админка, устаревшая вёрстка внутренней страницы. Такое чинят попутно. Правило работает простое: приводим в порядок то, к чему и так притронулись по текущей задаче, а не устраиваем ремонт всего сразу и на весь бюджет.
Бюджет задаётся заранее: фиксированная доля времени разработки каждый месяц, скажем 20 %, уходит на разбор списка. Если по расчёту выходит, что латать старое дороже переезда, сравните варианты честно — об этом материал про выбор между своей разработкой и готовым решением.
Вывод: как держать технический долг под контролем#
Полностью избавиться от долга нельзя, да и не нужно. Скорость иногда важнее чистоты, а решение, принятое под срок, окупается выручкой сезона. Разница между здоровым проектом и безнадёжным не в отсутствии упрощений, а в том, записаны ли они и назначен ли срок возврата.
Минимум, который стоит завести: список долга в общей таблице с владельцем и датой, регулярное обновление версий, тестовая копия для проверки правок, доступы и настройки в письменном виде, а не в чужой голове. Это не проект, а привычка: час в месяц на пересмотр списка и заранее оговорённая доля времени разработки на его разбор.
Признак, что откладывать больше нельзя, тоже понятный: одинаковые по смыслу задачи стали занимать в разы больше времени, каждая правка тянет за собой поломку в соседнем месте, а подрядчики берутся неохотно и с наценкой. На этой стадии платят уже не проценты, а тело долга — целиком и в самый неудобный момент.