Про технический долг
Технический долг: оцифровать, поставить на контроль, не бояться
Проблема: ваш IT — это кредитка с 36% годовых
Представьте, что у вас есть кредитная карта. Вы платите только минимальный платёж — год, два, пять лет. Тело долга не уменьшается, проценты капают, но вы привыкли и не замечаете.
Примерно так выглядит технический долг в большинстве компаний.
Формально все знают, что он есть. Но никто не может назвать сумму: ни в деньгах, ни в потерянном времени, ни в упущенных возможностях. Просто «архитектура устарела», «код надо переписывать», «фреймворк не тянет».
Я слышу это на каждой второй встрече с техническими командами. И каждый раз задаю один вопрос:
— Сколько именно? В чём? Какой кусок критический, а какой потерпит?
В ответ — тишина. Потому что технический долг — это не когда программисты плохо написали код. Технический долг — это когда бизнес осознанно или нет откладывает инвестиции в качество продукта. Быстрее выйти на рынок. Сэкономить на разработке. Не трогать то, что и так работает.
И его можно гасить, рефинансировать или игнорировать, пока проценты не съедят всё.
Разница в том, что кредитор по техдолгу — не банк, а вы сами. В виде упущенной выручки, сорванных сроков и демотивированной команды.
Что такое техдолг на языке бизнеса
Технический долг = отложенные инвестиции в качество продукта.
Если бы вы строили завод и решили сэкономить на фундаменте, чтобы запуститься на полгода раньше — это было бы техническим долгом. Фундамент не развалится завтра. Но через два года трещины пойдут, и ремонт обойдётся втрое дороже, чем если бы сделали сразу.
С IT тоже самое.
Примеры техдолга, которые поймёт любой руководитель
Быстрый выход.
Стартап за 2 месяца собрал MVP на коленке, чтобы привлечь инвестиции.
Через год у продукта 10 000 клиентов. Каждая новая функция теперь требует недели вместо одного дня. Команда
выросла в 3 раза, но скорость упала. Техдолг = потерянная выручка от функций, которые могли бы быть сделаны, но
не сделаны из-за архитектурных ограничений.
Экономия на интеграциях.
Производственная компания автоматизировала склад на одной системе, закупки на другой, производство на третьей. На интеграции бюджет не закладывали — «потом решим». Через 3 года два штатных сотрудника на полную ставку перебивали данные через Excel. Их совокупный ФОТ за это время — около 3,6 млн руб. Плюс ежеквартальные ошибки ручного переноса: не те артикулы, задвоенные заказы, срыв отгрузок. Ущерб от одной такой ошибки — до 500 тыс. руб. Когда наконец поставили шину интеграции за 1,2 млн — окупилась за 3 месяца.
«Работает — не трогай».
Помню проект, где ERP-система работала 7 лет без обновлений. Никто не трогал ядро, не писал тесты, не менял конфигурации. Всё работало — пока не встала задача интеграции с крупным маркетплейсом. Система упала под нагрузкой на второй день пилота. Внеплановый апгрейд + миграция обошлись в 4,5 млн и съели полгода ресурса команд.
Я сам через это проходил. В одном из проектов мы накопили техдолга на десятки миллионов рублей — просто потому что год за годом говорили «допилим потом». Когда сели считать, оказалось: 60% времени команды уходит на поддержку легаси, 15% — на исправление костылей, и только 25% — на новый функционал, который приносит деньги. Мы не переписывали систему. Мы сделали матрицу приоритизации, закрыли три самых больных узла за 2 месяца и высвободили 20% ресурсов команды на развитие. С тех пор я не верю в «переписать всё с нуля». Я верю в рефинансирование.»
Почему «переписать всё с нуля» — самый дорогой сценарий
Когда техдолг становится невыносимым, первая реакция: «Давайте перепишем всё!». Это как сказать: «У меня накопились долги по кредитке — продам квартиру, погашу всё и куплю новую».
Почему это плохая затея
1. Вы платите дважды
Старая система продолжает работать (и требовать поддержки), пока
пишется новая. Двойной ФОТ, двойные простой, двойной стресс.
2. Новая система унаследует старые ошибки
Бизнес-процессы, которые вы «автоматизировали как
смогли» 5 лет назад, — это и есть текущие бизнес-процессы. Переписывая код, вы не измените процессы. А значит,
значительная часть архитектурных решений старой системы окажется верной — просто неочевидной.
3. Рынок не ждёт
Пока вы 2 года переписываете «идеальную систему», конкуренты выпускают по 10
фич. Вы выходите с новой версией, а она уже устарела.
Когда переписывать оправданно:
- Система написана на технологиях, которые больше не поддерживаются
- Исходный код утерян или не подлежит восстановлению
- Бизнес-модель кардинально изменилась, и старая архитектура физически не позволяет новые сценарии
Во всех остальных случаях — рефинансируйте, а не переписывайте.
Матрица приоритизации техдолга
Лучший инструмент для управления техдолгом — простая матрица из двух осей:
- Влияние на бизнес (насколько этот кусок долга мешает бизнесу прямо сейчас)
- Сложность исправления (сколько ресурсов потребуется)
Как работать с матрицей
- Выпишите все «узкие места» — то, что тормозит команду, падает, требует постоянных костылей.
- Оцените влияние на бизнес — не техническими, а бизнес-критериями:
- Сколько клиентов/заказов теряется из-за этой проблемы?
- Сколько времени команда тратит на её обход?
- Какие новые возможности блокированы?
- Оцените сложность — во сколько человеко-часов(дней,месяцев) обойдётся исправление.
- Разложите по квадрантам — получите дорожную карту на год.
Ключевое правило: не пытайтесь закрыть весь техдолг. Закрывайте то, что в верхнем левом квадранте — где влияние высокое, а сложность низкая. Это даст 80% результата при 20% усилий.
Чек-лист: как понять, что техдолг вышел из-под контроля
- Выход простой функции занимает больше недели?
- Любое обновление системы вызывает страх «а не сломается ли что-нибудь»?
- Вы не можете быстро подключиться к новому маркетплейсу или каналу продаж?
- Добавление нового разработчика в команду не ускоряет выход фич?
- Система падает при росте нагрузки, а не при ошибках?
- Вы не помните, когда в последний раз обновляли ключевые компоненты системы?
- Бизнес требует новую фичу, а IT говорит: «надо сначала переписать архитектуру»?
3+ ответа «да» — техдолг уже заметно тормозит бизнес. Пора считать и приоритизировать.
Как перестать бояться и начать управлять
Технический долг — это не катастрофа. Это инструмент управления. Если вы контролируете его объём, платите проценты осознанно и гасите основное тело там, где это выгодно — вы управляете техдолгом, а не он вами.
План действий на квартал:
- Инвентаризация — выпишите 10–15 узких мест, которые тормозят команду
- Приоритизация — разложите по матрице (влияние × сложность)
- Выберите 2–3 quick win — закройте их в ближайшие 4–6 недель
- Закрепите практику — выделите 10–20% спринта на снижение техдолга (как Google и Amazon делают)
Самый сложный шаг — первый. Дальше становится проще.