Технический долг: когда сайт пора лечить и сколько это стоит
Технический долг редко объявляет о себе заранее. Сначала подрядчик просит неделю на правку, которая раньше занимала день. Потом после каждого релиза что-то отваливается: то формы, то выгрузка в 1С. Потом выясняется, что обновить PHP «нельзя, всё сломается», а разобраться в коде может только один человек. Для владельца это выглядит как дорожающая и всё менее предсказуемая разработка. На деле это проценты по долгу, который копился годами.
В этой статье разберём технический долг с позиции владельца, а не программиста: по каким симптомам его заметить, какие бывают виды, как измерить без технического бэкграунда, как перевести долг в рубли и какую стратегию выбрать: гасить понемногу, выделять часы, делать большой рефакторинг или переписывать.
Что такое технический долг простыми словами
Технический долг — это сумма всех отложенных «сделаем нормально потом» в коде, архитектуре и инфраструктуре сайта. Каждое быстрое решение вместо правильного экономит время сейчас, но делает дороже каждую следующую задачу в этом месте. Разница между тем, сколько задача стоила бы на чистом коде, и тем, сколько она стоит на самом деле, — это и есть проценты.
Технический долг программистов — не синоним плохой работы. Запустить акцию к пятнице на временном решении бывает правильным бизнес-решением: как кредит на оборотку. Проблема начинается, когда долг не учитывают и не гасят. Историю термина и то, как долг гасят рефакторингом, мы разобрали в статье что такое рефакторинг кода. Здесь сосредоточимся на управленческой стороне.
Откуда берётся технический долг: основные причины
В ИТ технический долг возникает не только из-за слабых разработчиков. Чаще причины управленческие:
- Спешка к запуску. Жёсткий срок без права сдвинуть объём: команда вынужденно режет тесты, документацию и продуманную структуру.
- Смена подрядчиков. Каждая новая команда пишет по-своему и не понимает решений предыдущей, поэтому обходит их вместо того, чтобы исправить. Через три смены сайт превращается в слоёный пирог стилей.
- Временные решения, ставшие постоянными. «Пока захардкодим цену доставки» живёт пять лет.
- Экономия на поддержке. Обновления CMS и модулей не входят в договор, их откладывают, пока разрыв версий не становится пропастью.
- Нет владельца продукта. Задачи ставят разные отделы напрямую разработчику, никто не видит систему целиком.
- Бизнес изменился, а код нет. Сайт проектировали под 200 товаров и одну доставку, а сейчас 20 000 товаров, три склада и маркетплейсы.
Симптомы технического долга на уровне бизнеса
Читать код не нужно. Техдолг проявляется в деньгах, сроках и поведении команды:
- Каждая правка дорожает. Похожие задачи год назад оценивали в 4 часа, сейчас в 12, и оценки продолжают расти.
- Сроки стали непредсказуемыми. План и факт расходятся в полтора-два раза, в оценках появилась фраза «надо сначала разобраться».
- Страх обновлять. Команда отговаривает от обновления CMS, PHP или модулей: «может всё упасть».
- «Только Вася знает». Один разработчик держит в голове устройство сайта. Если он уйдёт или заболеет, работа встанет, а новые специалисты либо отказываются от проекта, либо просят недели на вход.
- Падения после релизов. Новая функция ломает старую, и об ошибке сообщают клиенты, а не команда.
- Отказы в фичах. «Это на нашей платформе не сделать» звучит всё чаще, хотя у конкурентов то же самое работает.
- Бюджет разработки растёт, а видимых изменений на сайте почти нет. Часы уходят на обслуживание, а не на развитие.
Виды технического долга и риски для бизнеса
Долг неоднороден: одни его виды просто замедляют работу, другие грозят взломом или остановкой продаж. Приоритеты зависят от вида.
| Вид долга | Как выглядит | Симптом для владельца | Риск для бизнеса |
|---|---|---|---|
| Код | Дублирование логики, костыли, «магические» значения прямо в коде | Одну правку вносят в нескольких местах, мелочи делаются долго | Переплата за каждую задачу, ошибки в ценах и расчётах |
| Архитектура | Всё связано со всем, модули нельзя поменять по отдельности | Правка корзины ломает личный кабинет, новые фичи «не влезают» | Невозможно масштабироваться, подключить новый канал продаж или склад |
| Инфраструктура и версии | Устаревший PHP, старое ядро CMS, неподдерживаемые модули, ручной деплой | Страх обновлений, хостинг предупреждает о снятии старой версии PHP | Внезапная остановка сайта при переезде хостинга, несовместимость с новыми сервисами |
| Безопасность | Уязвимые модули, пароли в коде, нет обновлений безопасности | Обычно никакого — до инцидента | Взлом, утечка персональных данных, штрафы за утечку персональных данных, попадание в чёрные списки |
| Документация и знания | Нет описания интеграций, доступов, схемы работы | Зависимость от одного человека, долгий вход новых людей | Потеря управляемости при уходе разработчика или смене подрядчика |
| Тесты | Нет автотестов, проверка — «прокликать главную» | Падения после релизов, релизы по ночам и с опаской | Потерянные заказы в часы простоя, репутационные потери |
| Данные | Дубли, мусорные поля, несогласованные справочники | Кривые отчёты, ошибки в выгрузках в 1С и CRM | Неверные управленческие решения, ручная работа менеджеров |
Отдельно про версии. На сентябрь 2026 года ветки PHP 7.x, 8.0 и 8.1 уже не получают даже исправлений безопасности, а поддержка PHP 8.2 заканчивается 31 декабря 2026 года. Даты — по графику поддержки на php.net. Если сайт работает на одной из этих версий, долг по инфраструктуре у вас точно есть, и счёт по нему идёт на месяцы.
Как измерить технический долг без технического бэкграунда
Владельцу не нужны метрики сложности кода. Достаточно пяти-шести показателей, которые можно вести в таблице и смотреть раз в квартал. Важен не абсолютный уровень, а динамика.
| Показатель | Где взять | Тревожный сигнал |
|---|---|---|
| Время на типовую задачу (новая форма, поле в карточке, баннер-блок) | Трекер задач, акты подрядчика | Рост на 30% и больше за год при той же команде |
| Доля часов на исправления против новых функций | Отчёт по часам с разметкой «ошибка / развитие» | Больше трети часов уходит на исправления |
| Инциденты после релизов | Журнал инцидентов, обращения клиентов | Больше одного заметного сбоя в месяц |
| Возраст версий PHP, CMS и модулей | Панель хостинга, раздел обновлений в админке CMS | Версия снята с поддержки или отстаёт на два мажорных релиза |
| Точность оценок | Сравнение плана и факта по задачам | Факт стабильно превышает план в 1,5 раза и больше |
| Время входа нового разработчика | Опыт последней замены или подключения специалиста | Больше двух недель до первой самостоятельной задачи |
Начните с простого: попросите подрядчика размечать каждую задачу в отчёте как «развитие», «исправление» или «обслуживание». Через два-три месяца у вас будет картина, на что реально уходит бюджет, и основа для разговора о долге на языке цифр, а не «код плохой».
Сколько стоит технический долг: считаем проценты в деньгах
Долг удобно считать как кредит: есть «тело» (сколько стоит привести проблемные места в порядок) и «проценты» (сколько вы переплачиваете каждый месяц, пока не погасили). Разберём условный пример интернет-магазина. Цифры ориентировочные, при ставке 2 500 ₽ в час.
Исходные данные. На развитие сайта уходит 60 часов в месяц. Разметка задач показала, что примерно 40% времени — это обход костылей и повторные исправления. Плюс в среднем два сбоя в месяц после релизов: сайт или корзина не работают около трёх часов, в час магазин теряет порядка 15 000 ₽ выручки, на исправление каждого сбоя уходит 4 часа.
Проценты в месяц:
- лишние часы разработки: 60 × 40% = 24 часа × 2 500 ₽ = 60 000 ₽;
- потерянная выручка: 2 сбоя × 3 часа × 15 000 ₽ = 90 000 ₽;
- исправление сбоев: 2 × 4 часа × 2 500 ₽ = 20 000 ₽.
Итого около 170 000 ₽ в месяц, или порядка 2 млн ₽ в год, и это без учёта упущенных фич, которые «не сделать на нашей платформе».
Тело долга. Аудит показал, что основная часть проблем сосредоточена в трёх модулях: корзина, импорт из 1С и расчёт доставки. Приведение их в порядок с покрытием тестами — около 240 часов, то есть 600 000 ₽.
После погашения лишние часы снижаются до 8 в месяц (20 000 ₽), сбои — до одного раза в два месяца (22 500 ₽ потерь и 5 000 ₽ на исправление в среднем за месяц). Проценты падают со 170 000 до 47 500 ₽, экономия — 122 500 ₽ в месяц. Вложение окупается примерно за пять месяцев.
Отношение процентов к телу долга в этом примере — 170 000 к 600 000, то есть около 28% в месяц. Ни один банк не даёт кредит под такую ставку, а на сайтах с запущенным долгом это обычная ситуация, просто её никто не считает.
Ваши цифры будут другими: они зависят от ставки подрядчика, выручки в час и состояния кода. Но сама методика — разметка часов, учёт сбоев и оценка тела долга — работает для любого проекта.
Управление техническим долгом: четыре стратегии
Полностью погасить долг невозможно и не нужно: у любого живого проекта он есть. Задача — держать его на уровне, когда проценты не мешают развитию. Выбор стратегии зависит от масштаба долга и от того, насколько платформа ещё жизнеспособна.
| Стратегия | Когда подходит | Цена | Главный риск |
|---|---|---|---|
| Гасить попутно | Долг умеренный, сосредоточен в отдельных местах | +10–20% к задачам, которые затрагивают проблемный участок | Участки, куда не приходят задачи, так и остаются в долгах |
| Выделять долю часов | Долг заметный, но платформа жизнеспособна | Постоянная доля ежемесячных часов, процент зависит от состояния проекта | Долю первой урезают при срочных задачах, крупные проблемы в таком режиме не решаются |
| Целевой рефакторинг модуля | Один-два модуля генерируют большую часть проблем | Десятки-сотни часов на модуль, отдельный бюджет | Затягивание без промежуточных результатов |
| Переписать | Платформа мертва, архитектура не соответствует бизнесу | Сопоставимо с новым проектом, плюс поддержка старого на время переезда | Срыв сроков, потеря SEO-трафика и функций, о которых все забыли |
Когда гасить постепенно
Попутное погашение и фиксированная доля часов — стратегия по умолчанию для большинства сайтов. Правило простое: трогаешь модуль под задачу — оставь его чище, чем был. Долю часов фиксируйте в договоре поддержки, иначе при первом аврале она исчезнет. Этот режим обычно оформляют как доработку сайта с прицелом на то, чтобы следующая правка стоила дешевле.
Когда нужен большой рефакторинг
Если разметка задач показывает, что основная часть переплаты приходится на один модуль, его выгоднее привести в порядок целиком отдельным проектом. Привязывайте такой проект к бизнес-результату: «подключить второй склад за неделю, а не за месяц», «обновление 1С без ручных правок». Как проводить рефакторинг без остановки бизнеса, подробно описано в отдельной статье.
Когда переписывать с нуля
Переписывание оправдано, если выполняется хотя бы два условия из трёх: платформа снята с поддержки и не обновляется без полной переделки; каждая заметная правка стоит как небольшой проект; бизнес-модель ушла далеко от того, под что проектировался сайт. Закладывайте время на параллельную жизнь двух систем, перенос SEO-структуры и редиректов, а срок оценок умножайте хотя бы на 1,5.
Как не накопить технический долг заново
После погашения долга важно не вернуться к той же точке через два года. Работают простые управленческие правила:
- Делайте долг видимым. Попросите вести реестр техдолга: список известных компромиссов, где они находятся и сколько добавляют к задачам. Осознанный долг управляем, неосознанный — нет.
- Разрешайте брать долг, но со сроком. Если временное решение нужно к запуску акции, сразу ставьте задачу на его замену с датой.
- Закладывайте обновления в поддержку. Обновление CMS, модулей и PHP — регулярная работа, а не проект раз в пять лет. Это стоит прописать в договоре поддержки сайта.
- Требуйте тесты на критичные сценарии. Корзина, оплата, формы заявок, выгрузки — минимальный набор автопроверок перед каждым релизом.
- Документируйте интеграции и доступы. Схема обмена с 1С, CRM, платёжкой и список доступов должны принадлежать вам, а не одному разработчику. Подробнее — в статье кому принадлежит сайт.
- Не принимайте работу без код-ревью. Хотя бы выборочная проверка кода вторым специалистом отсекает значительную часть костылей на входе.
Когда нужен внешний аудит кода
Команда, которая сама накопила долг, редко объективно оценивает его масштаб: одни преуменьшают, чтобы не признавать ошибки, другие преувеличивают, чтобы получить бюджет на переписывание. Независимый взгляд нужен в ситуациях, когда решение стоит дорого:
- смена подрядчика или приём проекта после ушедшего разработчика;
- перед крупными вложениями: редизайном, новым функционалом, выходом в новые каналы продаж;
- когда подрядчик предлагает переписать сайт с нуля, а вы не можете проверить обоснованность;
- после взлома, утечки или серии серьёзных сбоев;
- перед покупкой бизнеса или сайта, чтобы понять, что вы получаете вместе с кодом.
Результат нормального технического аудита кода (экспресс-формат — от 30 000 ₽) — не общий вывод «код плохой», а реестр проблем по видам с оценкой в часах, приоритетом по риску и планом: что гасить сразу, что постепенно, что можно не трогать. Такой документ позволяет сравнить предложения разных подрядчиков и принять решение о стратегии на цифрах. Если среди находок есть уязвимости, их стоит закрывать в первую очередь, до любых работ по развитию.
Чек-лист владельца: есть ли у сайта опасный технический долг
- Известны версии PHP, CMS и ключевых модулей, и все они поддерживаются
- Стоимость типовой задачи не выросла за последний год при той же команде
- В отчёте по часам видно, сколько уходит на исправления, а сколько на развитие
- Сбои после релизов — редкость, и о них узнаёт команда, а не клиенты
- Устройство сайта понимают как минимум два человека, есть документация по интеграциям
- Критичные сценарии (корзина, оплата, формы, выгрузки) проверяются автоматически перед релизом
- Обновления CMS и модулей входят в договор поддержки и проводятся регулярно
- Есть реестр техдолга с оценками, и на его погашение выделяется доля часов
- Посчитаны проценты по долгу в рублях в месяц хотя бы приблизительно
- Решение о переписывании, если оно обсуждается, подтверждено независимой оценкой
Если больше трёх пунктов не выполняются, долг уже влияет на деньги. Начните с разметки часов и проверки версий: это бесплатно и за месяц даст первую картину.
Итог
Технический долг — нормальная часть жизни любого сайта, как кредит у бизнеса. Опасен не сам долг, а долг, который никто не видит и не считает. Переведите его в понятные показатели: время на типовую задачу, долю часов на исправления, число сбоев, возраст версий. Посчитайте проценты в рублях. После этого выбор между постепенным погашением, целевым рефакторингом и переписыванием становится обычным инвестиционным решением, а не спором «программисты хотят переделать».