Привет! Мы команда SimpleOne SDLC — продукта, который помогает командам выстраивать процессы разработки. За несколько лет мы насмотрелись на одну и ту же сцену: техлид объясняет, почему простая фича делается три недели — и проигрывает этот разговор. Но почему?
Бизнес не понимает «легаси-слой авторизации», зато он очень хорошо понимает, когда теряет деньги. В этой статье — как перевести техдолг в язык цифр, которые слышит финдир и техдир: с конкретными метриками, инструментами и аргументами для защиты бюджета.
Сцена, которую видели все
Планерка. Менеджер продукта смотрит в роадмап. Техлид смотрит в пол.
— Почему эта фича делается три недели? Там же ничего сложного.
— Там техдолг, нам нужно сначала переписать слой авторизации.
— Подождите, вы же это делали в прошлом квартале?
— Это другое.
— …
Проблема не в людях, просто бизнес и инженер смотрят на одно и то же и видят разное: один видит задержку, приносящую убытки, другой же видит реальное препятствие. Пока разговор идет про «что такое техдолг» вместо «сколько он стоит» — он будет заканчиваться одинаково. А стоит всего-то сменить формулировки: не «грязный код», и не «технический долг» — а налог, который команда платит при каждом изменении системы. Чем больше долг — тем дороже каждая следующая фича.
Бизнес уже платит этот налог, просто пока не знает об этом. И ваша задача — не объяснять архитектуру, а просто выставить счет.
— Мы хотим 20% спринта на техдолг.
— Зачем? Фичи же работают.
— Работают. Но фича, которая год назад делалась за 3 дня, сейчас делается за 3 недели. Вот данные из трекера. Если ничего не менять, через год — 6 недель. При средней стоимости спринта в 2 млн рублей это дополнительные 4 млн на каждую фичу.
— ...Сколько стоит починить?
— Три модуля, 6 недель, ожидаемый эффект — возврат к 5-дневному циклу.
Не весь долг одинаков: почему это важно для разговора с финдиром
Для разговора с бизнесом важно различать: намеренный долг («выпустим быстро, потом почистим» — управляемое решение с известной ценой) и архитектурный — неправильные границы сервисов, монолит, каскадные зависимости. Именно архитектурный долг стоит за сценой из начала статьи и стоит на порядок дороже. Первый можно показать бизнесу как осознанный trade-off, второй — как системный риск, который растёт без вмешательства.
По данным ShiftMag (2024), 69% разработчиков теряют 8+ часов в неделю на неэффективности, и техдолг — главная причина. Для команды в 100 человек это 800 потерянных часов каждую неделю.
Некоторые компании вынесли это на уровень руководства: ввели индекс здоровья кодовой базы рядом с NPS и revenue. Один задокументированный кейс — снижение «налога техдолга» с 75% до 25%, что позволило компании наконец масштабироваться.
Что именно измерять
Хорошая метрика здоровья складывается из нескольких компонентов:
Цикломатическая сложность — насколько разветвлен код, сложно ли его тестировать.
Покрытие тестами — сколько процентов кода защищено автотестами.
Coupling — степень связанности модулей: насколько изменение в одном ломает другие. Чем выше coupling, тем выше риск каскадных инцидентов в production.
Среднее время на исправление дефекта — косвенный показатель того, насколько код понятен новому человеку.
Инструменты считают это автоматически, но у каждого своя специализация: SonarQube — self-hosted, хорошо подходит для enterprise и команд с требованиями к безопасности данных, интегрируется в CI/CD pipeline как quality gate; CodeScene — поведенческий анализ, сильнее в team health и выявлении «горячих» файлов, которые чаще всего меняются и ломаются; CodeClimate — облачный, проще всего для старта.
Вывод одной агрегированной цифры из этих данных на дашборд руководителя — уже достаточно для разговора. Но следите за неоднородностью: общий индекс 7/10 при одном модуле с coupling 0.9 — это не «всё нормально», это бомба замедленного действия. Агрегат скрывает точки концентрации риска.
Техдолг и инциденты: связь, которую редко считают
Один из самых весомых аргументов для бизнеса — не скорость разработки, а стабильность системы, и здесь техдолг бьёт особенно больно.
Высокий coupling означает, что при инциденте невозможно быстро локализовать проблему: изменение в одном сервисе незаметно ломает три других. MTTR (среднее время восстановления) растёт — и это уже не абстрактная инженерная метрика, а прямые потери revenue в момент падения.
Если в вашей компании есть SLA или SLO — посчитайте, сколько стоит каждая минута недоступности. Теперь посмотрите на последние три инцидента: сколько времени ушло на поиск причины? В legacy-системах с высоким техдолгом это часы, а не минуты. Вот ваш аргумент для финдира — без слайдов про архитектуру.
SLA вашего сервиса — 99.9%, это 8.7 часа допустимого даунтайма в год. Последний инцидент в legacy-модуле занял 4 часа на локализацию. Если сервис приносит 10 млн ₽ в день, 4 часа простоя — это 1.7 млн. Один инцидент = стоимость месяца работы над погашением долга в этом модуле.
Migration tax: когда переходы стоят дороже фич
Инженер Stripe Will Larson описал на QCon (2018) концепцию «migration tax»: когда инфраструктурные миграции накапливаются без управления, продуктовые команды начинают тратить основное время на переходы вместо создания ценности. Бизнес буквально заморожен, но счёт продолжает идти. Ключевой принцип: стоимость каждой миграции считается как прямые потери и показывается в финансовых отчетах — не как техническая метрика, а как деньги. Отчёт Stripe «Developer Coefficient» (2018) зафиксировал: 42% профессионального времени разработчиков уходит на работу с техдолгом.
Три цифры для финдира: как считать и где брать данные
В российских компаниях бюджетная защита строится не вокруг красивых презентаций, а вокруг конкретных цифр на квартальном отчёте у финдира или техдира. Вот три, которые работают.
Метрика | Как считать | Где брать данные |
Стоимость фичи тогда и сейчас | Человеко-часы на похожую задачу 2 года назад vs. сегодня | Трекер задач (Jira, YouTrack, SimpleOne SDLC) |
Соотношение поддержка / развитие | % времени команды на баги и поддержку vs. новые задачи | Отчеты по типам задач в спринте |
Динамика time-to-market | Среднее время от создания задачи до релиза за последние 8 кварталов | Цикл доставки в трекере |
По данным McKinsey (2023, через vFunction), 20–40% технологического ландшафта типичной компании поглощается техдолгом. Если ваши цифры в таблице выше дают похожую картину — они говорят сами за себя без слайдов про архитектуру.
Как долг превращается в «никто не трогает этот модуль»
Техдолг работает как сложный процент — только в минус. «Выпустим продукт, потом почистим» превращается в «у нас теперь пять команд, которые боятся трогать этот модуль».
Вот механика из практики одной из команд, с которыми мы работали. Студенты без code review и coding guidelines — каждый пишет как умеет, никто не смотрит что внутри: главное, что «кнопка нажимается». Через два года другой разработчик открывает компонент: 1100 строк на одну форму, сложность — через крышу, покрытие тестами — нулевое. В модуле, написанном с нормальными процессами, — 40 строк. 6 тестов против 300. Бизнес-аналитик этого не видит, а вот разработчик, которому это сопровождать, видит очень хорошо.
И самое дорогое следствие — страх трогать систему. Команда начинает работать вокруг проблемы, а не с ней: добавляет новые слои поверх старых, копирует код вместо того чтобы переиспользовать, избегает рефакторинга, потому что «а вдруг сломается». Это уже не технический долг — это культурный долг, и он гораздо тяжелее погашается.
Распознать его можно по косвенным признакам: на ревью никто не комментирует «этот модуль», новые разработчики получают устный инструктаж «туда не ходи», задачи в проблемной области стабильно оцениваются с большим запасом. Технически система работает — но только потому что никто её не трогает.
Работать с культурным долгом организационно — значит сделать работу с проблемными модулями безопасной: ввести парное ревью при изменениях в «горячих» зонах, зафиксировать ownership (кто отвечает за модуль и его здоровье), и главное — снять стигму с «я сломал что-то в этом месте». Если инцидент после касания страшного модуля становится поводом для разбора полётов, а не для обвинений — команда постепенно перестаёт его бояться.
Стоимость изменений растет нелинейно с накоплением долга. Анализ TechDebt.guru (2026) показывает: команда, тратящая 10% времени на техдолг в первый год, к третьему году тратит уже 20–25%, а к пятому — 40–55%.
Долг не прибавляется, он умножается: каждый новый «быстрый» шорткат взаимодействует с предыдущими и создает мультипликативную, а не аддитивную сложность.
Как выбрать, что гасить первым
Это вопрос, который статьи про техдолг обычно игнорируют — а именно он самый болезненный на практике.
Простой фреймворк из трёх шагов:
Hotspot analysis
Найдите файлы и модули, которые меняются чаще всего и при этом имеют высокую сложность — это ваши «горячие точки». CodeScene делает это автоматически. Именно здесь долг стоит дороже всего: каждое изменение болезненно, а изменений много.
Impact scoring
Соотнесите горячие точки с roadmap. Простой способ — таблица из двух столбцов: какие модули попадают в путь фич следующего квартала, и насколько высок их hotspot-score. Если модуль с высоким долгом стоит на пути трёх фич — это приоритет №1. Если он никому не нужен ещё год — можно подождать. Дополнительный фильтр: оцените усилие на погашение (грубо, в человеко-неделях). Модули с высоким impact и низким effort гасятся первыми — классическая матрица Impact×Effort, только с инженерным содержанием внутри.
Dependency от инцидентов
Если модуль регулярно фигурирует в post-mortem — это отдельный приоритет, независимо от roadmap. Производственная нестабильность — не технический аргумент, это бизнес-риск.
Результат — не «дайте нам квартал на рефакторинг», а конкретный список: «вот три модуля, вот их связь с roadmap и инцидентами, вот оценка времени и ожидаемый эффект».
Anti-patterns: как не надо управлять техдолгом
Несколько сценариев, которые выглядят как решение, но на практике делают хуже:
«Рефакторинг-спринт»
Выделить отдельный спринт на погашение долга — звучит разумно. На практике: команда выгорает от переключения режима, бизнес нервничает из-за паузы в фичах, а через месяц всё возвращается на круги своя. Долг гасится не спринтами, а непрерывно — небольшими вложениями в каждую итерацию.
«Долг как фича»
Когда технический долг регистрируется в бэклоге наравне с продуктовыми задачами — он почти всегда проигрывает в приоритизации. Бизнес выбирает новую функциональность. Долг накапливается.
«Заморозка фич до погашения долга»
Выглядит как радикальное, но честное решение. В реальности убивает мотивацию команды, создаёт панику у бизнеса и редко заканчивается тем, чем задумывалось — давление на «разморозку» нарастает быстрее, чем гасится долг.
Работающая модель — это не один из трёх сценариев выше, а системное выделение фиксированной доли мощности команды на каждый спринт.
Что конкретно предлагать на защите бюджета
Избегайте формулировки «дайте нам квартал на рефакторинг» — она звучит как заморозка полезной работы и, по сути, ею является. Бизнес слышит: «мы хотим три месяца делать то, что вы даже никак не увидите». Вместо этого — дайте им конкретные инструменты.
Фиксированный процент спринта на погашение долга
Практика команд, которые нашли баланс между скоростью доставки и управляемостью долга, показывает стартовую цифру около 20% — её рекомендует Scrum.org и подтверждает SAFe-практика.
Но это не универсальное правило: для систем с 10–15 годами легаси или с высоким CFR по DORA-метрикам цифра может быть выше — 30–40%, пока долг не стабилизируется; исследование Edmonds Commerce фиксирует, что 23–42% IT-бюджета типичной компании уже уходит на работу с долгом — а значит, для зрелого легаси 20% могут быть заниженной оценкой.
Правильный способ определить свою цифру — посмотреть на текущее соотношение «поддержка / развитие» в трекере и сделать его явным для бизнеса. Формулируйте именно так: это плановые выплаты, чтобы налог не рос.
Метрика здоровья в роадмапе
Рядом с продуктовыми показателями, не в отдельном техническом документе. Если она падает — это блокер для новых фич так же, как падение конверсии.
Техдолг как отдельная строка бюджета
Не спрятанная внутри «разработки». Когда бизнес видит, что 30% бюджета команды уходит на работу с последствиями прошлых решений — это становится его проблемой, а не только вашей. Важный организационный момент: у этой строки должен быть владелец — конкретный человек, который отвечает за динамику долга и регулярно отчитывается. Без владельца бюджетная строка превращается в формальность.
Резюме
Техдолг не исчезает от того, что его не называют. Он продолжает дорожать — тихо, каждый спринт, пока однажды «простая фича» не начинает делаться три недели.
Первый шаг: откройте трекер, возьмите три последние фичи и посчитайте, сколько времени ушло на саму разработку, а сколько — на обход существующих проблем. Покажите эту цифру финдиру. Без слайдов, без архитектурных схем — только часы и рубли.
***
У вас был момент, когда бизнес наконец услышал аргумент про техдолг? Что это было?
