5 признаков технического долга: как распознать проблемы вовремя
«Мы переписываем это уже третий раз» — фраза, которая стоит компаниям миллионы. Технический долг — это не абстракция для программистов. Это реальные деньги: упущенная выручка, переработки команды, потерянные клиенты.
По данным McKinsey, технический долг составляет 20-40% стоимости IT-активов компании. Как понять, что пора бить тревогу? Разбираем 5 ключевых признаков.
Что такое технический долг
Метафора кредита
Технический долг — как кредит. Вы берёте «займ», чтобы выпустить продукт быстрее:
- Не пишем тесты → экономим 2 недели сейчас
- Копипастим код → делаем фичу за день вместо трёх
- Не документируем → запускаемся быстрее
Но потом платите «проценты»:
- Без тестов каждый релиз ломает что-то неожиданное
- Копипаст превращается в 10 мест, которые нужно править
- Новый разработчик месяц разбирается в коде
Когда долг становится проблемой
Немного долга — нормально. Проблема, когда «проценты» начинают съедать всё время команды:
| Уровень долга | Симптомы | Действия |
|---|---|---|
| Низкий (норма) | 10-20% времени на «чистку» | Регулярный рефакторинг |
| Средний | 30-40% времени, замедление delivery | Выделить спринт на погашение |
| Высокий | 50%+ времени, страх трогать код | Срочный аудит и план |
| Критический | Невозможно развивать продукт | Частичное или полное переписывание |
Признак 1: Каждая фича занимает всё больше времени
Как это выглядит
Год назад аналогичная фича делалась за 2 недели. Теперь — за 6 недель. При этом команда та же, процессы не менялись.
Типичные объяснения команды:
- «Нужно учесть много edge cases»
- «Код сложный, нужно разобраться»
- «Если менять здесь, ломается там»
- «Нет документации, приходится реверс-инжинирить»
Метрики для отслеживания
| Метрика | Здоровая система | Проблемная система |
|---|---|---|
| Lead time (идея→прод) | Стабильный или уменьшается | Растёт на 20%+ в год |
| Story points за спринт | Стабильный velocity | Падает при той же команде |
| Время на «разобраться» | 20-30% от задачи | 50%+ от задачи |
Что делать
- Измерьте lead time за последние 12 месяцев — есть ли тренд?
- Проведите ретроспективу: почему конкретные задачи заняли больше времени?
- Выявите «токсичные» модули — части кода, которые чаще всего упоминаются как причина задержек
Признак 2: Баги возвращаются после исправления
Как это выглядит
Исправили баг в понедельник. В среду он вернулся. Или появился похожий баг в другом месте. Команда играет в «ударь крота» — бьёшь одного, выскакивает другой.
Типичные причины:
- Дублирование кода — исправили в одном месте, забыли про копии
- Нет тестов — регрессия не отлавливается
- Связанность модулей — изменение A ломает B
- Непонимание кода — «лечим симптом, не болезнь»
Метрики для отслеживания
| Метрика | Здоровая система | Проблемная система |
|---|---|---|
| Reopen rate багов | <5% | >15% |
| Регрессии за релиз | 0-1 | 3+ |
| Время на один баг | Стабильное | Растёт |
Реальный пример
Компания: SaaS для e-commerce. Симптом: баг «товар не добавляется в корзину» возвращался 4 раза за 2 месяца.
Причина: Логика корзины была скопирована в 7 мест (веб, мобильное приложение, API, разные версии). Исправляли в одном месте — забывали про другие.
Решение: Выделили единый сервис корзины. Время на фикс подобных багов сократилось с 2 дней до 2 часов.
Признак 3: «Священные коровы» в коде
Как это выглядит
В кодовой базе есть модули, которые все боятся трогать:
- «Не лезь в billing_module — там драконы»
- «Этот файл написал Вася 5 лет назад, он уволился, никто не понимает»
- «Если это сломается — сайт ляжет»
- «Там 10 000 строк без комментариев»
Признаки «священной коровы»:
- Редкие коммиты (никто не хочет трогать)
- Много hotfix-ов (когда всё-таки приходится)
- Нет тестов или тесты не работают
- Один человек «владеет» модулем
Чем опасно
- Bus factor = 1: Уходит «владелец» — модуль становится чёрным ящиком
- Блокировка развития: Нельзя добавить фичу, потому что нужно менять «священную корову»
- Накопление долга: Все обходят модуль костылями, система усложняется
Что делать
- Составьте карту «опасных зон» — опросите команду
- Оцените bus factor по каждому модулю
- Запланируйте ротацию — каждый должен понимать критичные части
- Выделите время на документирование и покрытие тестами
Признак 4: Новые сотрудники долго входят в проект
Как это выглядит
Onboarding нового разработчика занимает 3-6 месяцев вместо 2-4 недель. Первые месяцы новичок «только разбирается».
Типичные жалобы новичков:
- «Документация устарела / отсутствует»
- «Непонятно, почему сделано именно так»
- «Код противоречит сам себе»
- «Нет примеров, как делать правильно»
- «Каждый пишет по-своему»
Метрики для отслеживания
| Метрика | Здоровая система | Проблемная система |
|---|---|---|
| Время до первого значимого PR | 1-2 недели | 1-2 месяца |
| Время до самостоятельной работы | 1-2 месяца | 4-6 месяцев |
| Вопросов к тимлиду в день | 2-5 | 10+ |
Стоимость проблемы
Расчёт для компании:
- Зарплата senior-разработчика: 300 000 ₽/мес
- Onboarding 2 недели vs 3 месяца = разница 2.5 месяца
- Потери: 2.5 × 300 000 = 750 000 ₽ на одного человека
- При найме 5 человек в год: 3 750 000 ₽/год
Плюс время тимлида/ментора на объяснения.
Признак 5: Страх перед релизами
Как это выглядит
Релиз — это стресс для всей команды. Типичные симптомы:
- «Деплоим только в пятницу после обеда, чтобы было время починить»
- «Нужен ручной чек-лист на 50 пунктов»
- «После релиза все дежурят, ждут падений»
- «Откатываемся чаще, чем раз в месяц»
- «Релиз-менеджер — самая нервная должность»
Метрики для отслеживания
| Метрика | Здоровая система | Проблемная система |
|---|---|---|
| Частота релизов | Ежедневно / несколько раз в день | Раз в неделю / месяц |
| Время деплоя | <15 минут | >1 часа |
| Откаты | <5% релизов | >20% релизов |
| Инциденты после релиза | Редко | Почти каждый релиз |
Связь с техническим долгом
Страх релизов — следствие накопленного долга:
- Нет тестов → не знаем, что сломается
- Запутанный код → изменения имеют непредсказуемые эффекты
- Ручной деплой → человеческие ошибки
- Нет мониторинга → узнаём о проблемах от пользователей
Как оценить технический долг в деньгах
Прямые затраты
| Категория | Формула | Пример |
|---|---|---|
| Замедление разработки | (Текущий lead time — Идеальный) × Количество фич × Стоимость | +2 недели × 20 фич/год × 500 000 ₽ = 20 млн ₽ |
| Регрессии | Часов на исправление × Ставка × Количество | 8 часов × 2 500 ₽ × 50/год = 1 млн ₽ |
| Onboarding | (Фактический — Нормальный) × Зарплата × Найм/год | 2 мес × 300 000 ₽ × 5 человек = 3 млн ₽ |
| Инциденты | MTTR × Потери/час × Количество | 2 часа × 500 000 ₽ × 12/год = 12 млн ₽ |
Скрытые затраты
- Упущенные возможности: Не успели запустить фичу — конкурент запустил первым
- Текучка: Разработчики уходят из-за «легаси-болота»
- Репутация: Баги и простои портят отношения с клиентами
Что делать: план действий
Шаг 1: Аудит (1-2 недели)
- Соберите метрики: lead time, reopen rate, время onboarding
- Опросите команду: где болит, чего боятся, что хотят исправить
- Проанализируйте код: покрытие тестами, сложность, дублирование
- Составьте карту «опасных зон»
Шаг 2: Приоритизация (2-3 дня)
Оцените каждую проблему по двум критериям:
- Влияние на бизнес (высокое / среднее / низкое)
- Стоимость исправления (большая / средняя / маленькая)
Начинайте с: высокое влияние + маленькая стоимость.
Шаг 3: Выделите бюджет
Рекомендация: 20-30% времени команды на работу с техническим долгом. Это не «отнимает время от фич» — это инвестиция в скорость.
Шаг 4: Регулярные проверки
Раз в квартал:
- Пересматривайте метрики
- Обновляйте приоритеты
- Оценивайте прогресс
Tech Audit: профессиональная оценка технического долга
Tech Audit от Virtuman поможет:
- Выявить: Полная карта технического долга с оценкой в рублях
- Приоритизировать: Что исправлять первым для максимального эффекта
- Спланировать: Roadmap погашения долга на 3-6-12 месяцев
- Помочь: Сопровождение при внедрении изменений
