Сколько стоит ваш техдолг: методики, цифры, российская специфика

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

Примерно так выглядит разговор про техдолг с бизнесом. Пока это «у нас легаси» – руководство кивает и говорит «разберитесь», а стоит принести конкретные рубли вообще тему закрывают. Парадокс в том, что цифра без плана погашения – это не аргумент, а счёт, и на счёт без понятного ROI у CFO всегда один ответ: списать и забыть. 

Мы потратили какое-то время на то, чтобы разобраться, почему так происходит. В процессе нашли три методики, которыми на западе считают техдолг в деньгах – у каждой свои допущения, слепые пятна и сценарии, в которых она врёт. И отдельно поняли, что сама по себе цифра это только половина задачи. Вторая половина упаковка, без которой CFO скажет «спишем» при любой методике.

Об этом и поговорим.

Почему техдолг невидим для бизнеса?

Техдолг не стоит в балансе. Его нет в P&L, нет в отчёте для акционеров, нет ни в одной строке, которую CFO открывает по утрам. С финансовой точки это впрям похоже на протечку в трубах – она есть, деньги уходят, но пока никто не залил соседей снизу, официально всё в порядке.

В 2018 году Stripe опросил больше 300 команд и выяснил, что средний разработчик тратит 13,5 часов в неделю на техдолг – это примерно треть рабочего времени. Умножьте на численность команды и зарплату, получите число с несколькими нулями. Stripe посчитал глобально: $3 триллиона потерь мирового ВВП в год.
Это примерно экономика Великобритании, испаряющаяся в легаси-коде.

Но вот в чём штука: ~70% бизнес-лидеров в отдельном исследовании Protiviti признали, что техдолг тормозит их цифровую трансформацию. Признали…и ничего не сделали. Потому что признать на словах и увидеть в цифрах два разных уровня неудобства.

Техдолг – внебалансовое обязательство. Как кредитная карта, которую никто не вносит в семейный бюджет, потому что платежи как-то проходят каждый месяц сами.

Пока долг невидим, у него нет владельца. Разработчики знают, что он есть. Продакт-менеджеры чувствуют его в скорости команды. CFO не видит вообще, а значит с его точки зрения, проблемы нет.

И первый шаг сделать долг видимым, но для этого нужны данные.

Откуда их брать?

Прежде чем считать техдолг в рублях, нужно ответить на более простой вопрос: а сколько времени команда реально на него тратит? Есть три способа это выяснить, и они сильно отличаются по точности и трудоёмкости.

Опрос команды.
Самый быстрый старт – спросить разработчиков напрямую.
Google в своих инженерных практиках использует один вопрос: «По шкале от 1 до 5, насколько уверенно ты вносишь изменения в модуль X?» Агрегируешь ответы по модулям – получаешь тепловую карту долга по кодовой базе. Полезно ещё и тем, что находит то, что статический анализатор не увидит никогда: документационный долг, экспертные силосы и даже архитектурную сложность.

Минус один, но существенный: команды себя недооценивают. Когда то же самое измеряют объективными методами (трекинг времени или анализ кода) –реальная цифра окажется куда выше самооценки. Опрос просто даёт направление.

Jira-теги.
Создаёте тип задачи «Tech Debt» или метку, тегируете задачи при заведении, в конце квартала считаете story points, но на практике почти никто так не делает. 

Если вы используете SimpleOne SDLC для управления задачами, данные для зарплатного метода и Jira-тегов уже у вас в системе — достаточно настроить тип задачи и отчёт по трудозатратам.

Только 7,2% компаний методично трекают техдолг в каком-либо инструменте. У остальных данных просто нет, а значит, любая цифра будет экспертной оценкой, но не измерением.

Медианное время погашения одного элемента техдолга из трекера в крупной компании, к слову составляет 872 часа. Это примерно пять месяцев на одну задачу. Можно представить, как выглядит бэклог у тех, кто честно всё записывает.

Git churn.
А это самый объективный метод – и единственный, не требующий ручной разметки. Churn считает, сколько раз строка кода была переписана за период: 

(Lines Added + Lines Deleted) / Total Lines × 100%.

Высокий churn в старых модулях спустя месяцы после релиза означает прямой сигнал, что там живёт долг. Данные берутся из git log, без каких-либо опросов.

В связке с DORA-метриками (change failure rate – процент деплоев, вызвавших инцидент) это даёт довольно точную карту: высокий churn плюс высокий процент сломанных деплоев в конкретном модуле вот ваш приоритет номер один.

Вот практический совет: не пытайтесь пробовать сразу всё, это долгоиграющая и компонентная история. Опрос даёт карту за день, Jira-теги начинают работать через квартал, Git churn можно посчитать прямо сейчас на существующей ситуации.

Три методики

Данные есть. Теперь вопрос: как перевести их в рубли?

Универсальной методики не существует, хотя область уже не молодая. Просто техдолг неоднороден: часть живёт в коде и поддаётся автоматическому анализу, часть – в архитектурных решениях, которые никакой сканер не увидит, а оставшееся в упущенных возможностях, которые вообще не про код. Каждая методика берёт один срез и считает его, поэтому на западе их используют в связке, а не выбирают одну правильную.

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

Методика 1: зарплатный метод

Мы упоминали её в исследованиях Stripe с 42%.
Самый простой и самый понятный CFO. Берёте зарплатный фонд команды, умножаете на долю времени, которую разработчики тратят на техдолг  и получаете годовую стоимость.

Выглядит это так. Десять middle-разработчиков по 250 тысяч рублей в месяц = зарплатный фонд 2,5 млн в месяц, или 30 млн в год. Умножаем на 0,42 – получаем 12,6 млн рублей в год, которые команда тратит не на продукт, а на борьбу с собственным кодом.

Плюс метода  в его арифметической прозрачности. CFO хорошо понимает зарплатный фонд, проценты и вопросов к методологии минимум.

Минус в том, что метод видит только людей. Архитектурный долг, инфраструктурный, долг в процессах – всё это останется за кулисами. Если у вас CI/CD собирается 40 минут вместо пяти, это тоже стоит денег, но в зарплатный метод не войдёт. Плюс 42% – средняя температура по больнице: в конкретной команде может быть 15% или 70%, и без честного трекинга вы не узнаете, какая у вас.

Методика 2: SQALE через SonarQube

Если зарплатный метод считает людей, SQALE считает код. SonarQube сканирует кодовую базу и по методологии SQALE (Software Quality Assessment based on Lifecycle Expectations – методика оценки качества кода, разработанная в 2010 году и принятая как индустриальный стандарт) выдаёт долг в человеко-часах. Дальше умножаете часы на стоимость часа разработчика и получаете рубли.

Из этого получается TDR (Technical Debt Ratio), соотношение стоимости устранения долга к стоимости разработки всей системы. SonarQube переводит его в буквенный рейтинг: A – долг меньше 5% от стоимости разработки, это норма. E – больше 50%, это уже серьёзно.

Плюс метода воспроизводимость. Прогнали сканер сегодня, прогнали через квартал – видна динамика. Инструмент делает всё сам, человеческий фактор минимален.

Минус же в том, что статический анализатор видит только то, что можно посчитать в коде. Архитектурные решения, которые замедляют всю разработку, он не найдёт. Дефолтные оценки времени в SQALE тоже условные: инструмент считает, что исправить одно нарушение стоит две минуты, а в реальности это может быть два часа. И ещё один нюанс для российского рынка: SonarQube не поддерживает 1С из коробки. Для огромного пласта корпоративной разработки нужен отдельный BSL Plugin от SilverBulleters. Нишевый, но рабочий инструмент.

Методика 3: Cost of Delay

Первые две методики считают, сколько стоит долг прямо сейчас. Cost of Delay считает иначе: сколько стоит то, что вы не сделали из-за него.

Логика такая. Из-за техдолга фича выходит на три недели позже запланированного. Три недели – это три недели без выручки от данной фичи. Считаете среднюю месячную прибыль продукта, берёте три четверти от неё, вот и стоимость задержки. Плюс долгосрочные потери: более поздний выход означает меньше рыночной доли на старте, ниже пожизненная ценность пользователя.

Плюс метода очевиден: он говорит на языке бизнеса. Не «у нас TDR 23%», а «мы потеряли 4 млн рублей выручки, пока чинили легаси». 

Минус в том, что для этого нужна финансовая модель с данными о выручке на фичу.
У большинства команд её нет и атрибутировать задержку именно техдолгу, а не плохому планированию или внешним зависимостям, тоже непросто.

Эффект накопления 

Техдолг не стоит на месте – он всегда растёт, даже если команда не делает ничего нового. Каждая строка кода, написанная поверх легаси, наследует его зависимости, обходит его ограничения и встраивается в его архитектурную логику, из-за чего рефакторинг одного модуля через полгода неизбежно тянет за собой два соседних, а через год вообще пять. Долг дорожает не потому что его стало больше в штуках, а потому что каждая единица стала сложнее в устранении.

Формализуется это так: Долг × (1 + ставка)^лет, где ставку берут эмпирически – обычно 10–20% в год в зависимости от того, насколько активно команда пишет новый код поверх старого. При ставке 15% техдолг в 12 миллионов рублей через три года превращается в 18 миллионов – без единой новой проблемы, просто за счёт того, что старые стали дороже в обслуживании.

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

Упаковка и хороший/плохой долг 

Допустим, цифра есть. Дальше начинается отдельная задача.

Когда тимлид приносит CFO число –12 миллионов в год, TDR 23%, тот оказывается перед выбором: выделить бюджет на рефакторинг с непонятным горизонтом окупаемости или признать убыток и жить дальше. Второе проще. 

Разница между «мы теряем 12 миллионов в год» и «если потратить 4 миллиона на рефакторинг модуля X, через два квартала ускорим три фичи из роадмапа» – это разница между счётом и инвестиционным предложением. Первое закрывают. Второе обсуждают.

Правильный вопрос для бизнеса – не «сколько стоит наш долг», а «сколько стоит его не гасить

Но гасить нужно не весь долг, а только тот, который реально мешает прямо сейчас. Легаси в модуле, который никто не трогает и трогать не планирует это обязательство без процентов, с ним можно подождать. Приоритет там, где активная разработка постоянно упирается в старые ограничения: высокий churn, частые инциденты после деплоя, фичи из роадмапа, которые буксуют именно здесь.

Короче, разговор стоит начинать с конкретного ROI.

Итого

Выбор методики зависит от ситуации, а не от того, какая точнее. Нет инструментов и почти никаких данных – зарплатный метод даёт первую цифру за час, и этого достаточно чтобы начать разговор. Есть SonarQube или готовность его поднять – SQALE даёт воспроизводимую динамику, которую можно показывать каждый квартал. Есть финансовая модель продукта с данными по выручке на фичу – Cost of Delay говорит на языке, который CFO слышит без перевода.

Данные стоит собирать за квартал, не за спринт.
Один спринт это шум, а вот три месяца уже паттерн, с которым можно идти наверх.

И последнее. Цифра без плана погашения это счёт. Бизнес платит по счетам неохотно, особенно если не понимает за что. 

Цифра с конкретным модулем, стоимостью починки и тем, что разблокируется после уже инвестиционное предложение

Разница только в том, как сформулирован вопрос: не «сколько стоит наш долг», а «сколько стоит его не гасить».