К содержанию
Михаил Кадочников
  • Направления
  • Разработка
  • Telegram-боты
  • Экспертиза
  • Кейсы
  • Блог
Написать
Главная / Блог / Технический долг

Технический долг: как измерить, объяснить инвестору и системно устранить

Михаил Кадочников 21 июля 2026 14 мин
01

Что такое технический долг и почему его игнорировать опасно

Т

Технический долг (Technical Debt) — это подобно финансовому долгу: сейчас вы торопитесь и берете "в долг" время на архитектуру, качество кода или процессы. Позже вам нужно будет вернуть этот долг, потратив время на рефакторинг, переписывание, обновление. Если долг не возвращать, он накапливается и становится невыносимым.

Концепция технического долга была введена Вардом Каннингемом в 1992 году. Он сравнил плохой код с финансовым долгом: если вы получили деньги в долг, вы можете сделать больше сейчас, но позже платить проценты. То же самое с кодом.

Проблема в том, что многие разработчики и руководители не видят технический долг до критического момента. До того момента, когда новые фичи разрабатываются неделями вместо дней. До того момента, когда половина времени уходит на баг-фиксинг. До того момента, когда разработчики выгорают и уходят.

В этой статье мы разберемся, как измерить техдолг, как объяснить его инвесторам и как систематически его снижать.

02

Таксономия технического долга

Не весь технический долг одинаков. Мартин Фаулер разделил техдолг на два измерения: намеренный vs ненамеренный, осмотрительный vs безрассудный.

Матрица технического долга

1. Намеренный + Осмотрительный (квадрант 1)

Разработчик понимает, что берет на себя долг, и осмотрително это делает. Пример: для MVP выпустили MVP за 6 недель вместо 12, зная, что позже рефакторим. Это хорошее решение, потому что вы знаете, что нужно рефакторить и когда.

2. Намеренный + Безрассудный (квадрант 2)

Разработчик торопится, берет долг и не думает о последствиях. Пример: "Давай напишем без тестов, это ускорит разработку". Это плохое решение, потому что потом болезненно.

3. Ненамеренный + Осмотрительный (квадрант 3)

Разработчик не знает, что берет долг, но понимает общие принципы хорошего кода. Пример: новый junior написал функцию длинной в 500 строк, не зная, что нужна рефакторить. Это приемлемо, если есть процесс обучения.

4. Ненамеренный + Безрассудный (квадрант 4)

Разработчик не понимает, что берет долг, и не следует лучшим практикам. Пример: новый разработчик пишет одну большую функцию на всё, копирует код, нет тестов. Это самое опасное, потому что вы не видите долг до тех пор, пока система не развалится.

Вывод: Лучше всего намеренный осмотрительный долг (квадрант 1). Наихудший — ненамеренный безрассудный (квадрант 4). Ваша задача как CTO/lead разработчика — минимизировать квадранты 2 и 4.

03

Методы измерения технического долга

Вы не можете управлять тем, что не можете измерить. Вот несколько способов измерить техдолг:

Метод 1: SonarQube / Code Climate

Инструменты автоматического анализа кода. Они смотрят на код и определяют:

  • Сложность (cyclomatic complexity): функции должны быть простыми
  • Дублирование: какой процент кода дублируется
  • Покрытие тестами: какой процент кода покрыт тестами
  • Уязвимости безопасности: найденные потенциальные баги
  • Долг в человеко-днях: сколько дней нужно, чтобы рефакторить

Пример: SonarQube говорит "техдолг 45 дней разработки". Это означает, что нужно 45 дней full-time разработчика, чтобы избавиться от всех проблем.

Метод 2: Velocity decay (снижение скорости разработки)

Отслеживайте, сколько story points / часов работы в спринте тратится на новые фичи vs bug-фиксинг. Если раньше было 80% на фичи и 20% на баги, а теперь 50% на фичи и 50% на баги, это признак растущего техдолга.

Формула: (Часов на new features) / (Общее время в спринте) = Velocity.

Если velocity падает из месяца в месяц, это красный флаг.

Метод 3: Bug rate (уровень ошибок)

Сколько багов в продакшене на 1000 строк кода? Тренд растет или падает? Если растет, это признак, что код становится менее надежным.

Здоровое приложение: 1-2 бага на 10000 строк кода в месяц.

Приложение с техдолгом: 10+ багов на 10000 строк в месяц.

Метод 4: Deployment frequency (частота развертывания)

Как часто вы деплоите? Один раз в неделю, день, час? Если раньше деплоили каждый день, а теперь раз в неделю, это может указывать на растущую сложность и техдолг.

Здоровое приложение деплоится несколько раз в день.

Метод 5: Lead time (время выпуска фичи)

Сколько времени от момента, когда разработчик начинает писать код, до того, как это попадает в продакшен? Если раньше это было 3 дня, а теперь 10 дней, код замедлился.

Рекомендуемая комбинация: Используйте SonarQube или Code Climate для измерения качества кода + Velocity decay для измерения бизнес-влияния.

Компании, которые отслеживают техдолг, в 3 раза быстрее доставляют новые фичи, чем те, которые игнорируют долг

04

Как объяснить технический долг инвесторам и CFO

Это самый сложный разговор. Инвесторы видят только новые фичи, а не долг. Вот как говорить с ними:

Аналогия с финансовым долгом

"Наше приложение, как компания, взяло в долг ₽10 млн на быстрое развитие (фичи). Теперь мы платим проценты по долгу каждый месяц (медленная разработка, баги, выгорание разработчиков). Если не вернуть долг, проценты будут расти, и скоро мы вообще не сможем разрабатывать новые фичи."

Показывайте метрики

"6 месяцев назад мы разрабатывали 100 story points в спринт. Сейчас только 50. За это время команда выросла на 20%. Причина: половина времени уходит на баг-фиксинг вместо новых фич. Исправив техдолг, мы вернемся к 100 story points."

Связывайте с бизнесом

"Скорость разработки прямо влияет на нашу способность конкурировать. Если мы медленнее конкурентов на 2x, мы теряем рынок. Инвестиция ₽3M на снижение техдолга даст нам +100% скорость разработки, что стоит гораздо больше."

Напугайте (слегка)

"Если мы не начнем снижать долг, мы рискуем потерять 30% технической команды в течение года из-за выгорания. Стоимость замены одного разработчика: ₽2M (найм, обучение, потеря продуктивности). Лучше инвестировать в улучшение code base, чем искать новых людей."

05

Рамка приоритизации: Cost of Delay

Когда есть список проблем техдолга, какие исправлять в первую очередь? Используйте рамку Cost of Delay (стоимость задержки).

Cost of Delay = (Бизнес-влияние) x (Время) / (Стоимость фиксинга)

Пример 1: Устаревшие зависимости (низкий CoD)

  • Бизнес-влияние: Низкое (один раз привызумается уязвимость)
  • Время: Месяцы/годы
  • Стоимость: ₽100K (2-3 дня работы)
  • CoD = низкий
  • Рекомендация: Фиксить в фоне, не срочно

Пример 2: Медленный поиск в БД (высокий CoD)

  • Бизнес-влияние: Высокое (пользователи уходят, теряем деньги)
  • Время: Каждый день теряем ₽50K выручки
  • Стоимость: ₽500K (неделя работы senior разработчика)
  • CoD = 50000 x 365 / 500000 = 36.5 (очень высокий)
  • Рекомендация: Срочно фиксить

Пример 3: Нет unit-тестов (средний CoD)

  • Бизнес-влияние: Среднее (медленная разработка, баги)
  • Время: Каждый спринт теряем 2 дня на баги
  • Стоимость: ₽3M (3-4 месяца на написание тестов)
  • CoD = 80000 (дневная зарплата 10 разработчиков) x 30 спринтов в год / 3000000 = 0.8
  • Рекомендация: Планомерно внедрять, 10-20% времени

Эта рамка помогает определить, какой техдолг действительно критичен, а какой можно отложить.

06

План систематического снижения техдолга

Как исправить техдолг систематически, без разрушения текущей разработки:

Шаг 1: Оценить текущий долг (1-2 недели)

  • Запустить SonarQube или Code Climate
  • Провести аудит архитектуры
  • Провести интервью с разработчиками (что их раздражает в коде?)
  • Составить список всех проблем и их severity

Шаг 2: Приоритизировать (1 неделя)

  • Классифицировать проблемы по Cost of Delay
  • Выделить критичные (надо чинить АСАП), важные (в течение месяца) и nice-to-have (когда-нибудь)
  • Составить roadmap на 6-12 месяцев

Шаг 3: Выделить ресурсы

  • Если долг критичен (30+ дней): выделить 2-3 спринта (40% команды) исключительно на рефакторинг
  • Если долг средний: 10-20% времени в каждом спринте
  • Если долг низкий: 5-10% времени

Шаг 4: Организовать работу

  • Crear tech debt epic в Jira/GitHub
  • Разбить на story (каждое должно быть 3-5 дней работы)
  • Назначить ответственных
  • Регулярно отслеживать прогресс

Шаг 5: Регулярно переоценивать

  • Каждый месяц запускать SonarQube и смотреть тренд
  • Каждый квартал пересчитывать CoD и перепrioritize
  • Праздновать wins: "Мы сегодня удалили 5000 строк мертвого кода!"
07

Кейс: SaaS платформа снизила техдолг на 60% в 6 месяцев

Компания DataDrive разрабатывала SaaS платформу для аналитики. После 3 лет разработки они столкнулись с критическим техдолгом.

Исходная ситуация (начало)

  • Техдолг по SonarQube: 90 дней работы
  • Velocity: только 40% time на новые фичи, 60% на баги
  • Deployment frequency: один раз в неделю (вместо раньше раз в день)
  • Team: 20 разработчиков, текучка 40% в год (плохой знак)
  • Инвесторы требуют новые фичи, но разработчики выгорают

План действий

  1. Месяцы 1-2: Полная оценка техдолга. Определили, что 70% долга в старом legacy коде, 30% в неправильной архитектуре.
  2. Месяц 2-3: Выделили 2 спринта (40% команды) на критичный долг. Остальные 60% развивали новые фичи.
  3. Месяц 4-6: Продолжили 20% времени на техдолг, постепенно поднимая качество.

Результаты через 6 месяцев

  • Техдолг снижен с 90 дней до 35 дней (61% снижение)
  • Velocity восстановилась до 75% на новые фичи, 25% на баги (было 40% vs 60%)
  • Deployment frequency: каждый день (вместо раза в неделю)
  • Текучка: упала до 10% в год
  • Развертывание новых фич: вместо 3-4 недели, теперь 3-4 дня

Вывод: Инвестиция 2-3 месяца на снижение техдолга дала компании:

  • +35% скорость разработки
  • -30% дневные ошибки в продакшене
  • -30% текучка технической команды
  • Возможность нанять 10 новых разработчиков (они захотели присоединиться к чистому коду)
FAQ

Часто задаваемые вопросы

Технический долг — это отказ разработчика писать хороший код?

Нет. Хороший разработчик может осознанно взять небольшой долг, чтобы доставить MVP быстро. Плохой разработчик пишет грязный код и не понимает, что это долг. CTO должен управлять долгом, а не позволять ему расти бесконтрольно.

Может ли стартап позволить себе пренебречь качеством кода ради скорости?

Да, но только на очень ранних этапах (MVP). На Growth/Scale это рано или поздно наказывается. Лучше просто заложить качество в начало. Это не так дорого, как кажется.

Что делать, если техдолг уже критичен и разработчики выгорают?

Это чрезвычайная ситуация. Нужно выделить 6-8 недель исключительно на рефакторинг (остановить новые фичи). Это больно в краткосроке, но необходимо. Альтернатива: потеря всей технической команды.

Нужно ли полностью избавляться от техдолга?

Нет. Нулевой техдолг невозможен и не нужен. Здоровый уровень: 2-3 недели работы на большой проект. Это означает, что вы не игнорируете долг, но и не зацикливаетесь на нём.

Как предотвратить накопление техдолга в будущем?

1) Введите code review обязательным. 2) Напишите style guide для команды. 3) Используйте статический анализ кода (линтеры, SonarQube). 4) Требуйте unit-тесты для критичного кода. 5) Регулярно проводите архитектурные обзоры.

Готов обсудить вашу задачу

Отвечу в течение 2 часов. Бесплатная оценка проекта за 24 часа.

Написать в Telegram WhatsApp
mk@cybergroup.su +7 (963) 275-29-83

Читайте также

Оценка технического долга SaaS-платформы: методология и инструменты Технологический Due Diligence перед покупкой IT-компании: полный гайд для инвестора IT-аудит компании: чек-лист из 50 пунктов для руководителя
Навигация
  • Главная
  • Разработка
  • Telegram-боты
  • Экспертиза
  • Кейсы
  • Блог
Контакты
@mkadochnikov
+7 (963) 275-29-83
mk@cybergroup.su
+7 (963) 275-29-83
Соцсети

© 2005–2026 ИП Кадочников Михаил Юрьевич

ИНН: 665207006323