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

Что такое технический долг

Понятие «технический долг» (Tech Debt) ввел Уорд Каннингем как метафору накопленных в программном коде и архитектуре проблем, которые в будущем увеличивают затраты на разработку.

Почему этот долг появляется? Причины бывают разные:

• сжатые сроки для сдачи проекта, когда команда выбирает быстрые решения и осознанно жертвует качеством, надеясь вернуться к этому позже;
• временные решения для устранения повторяющихся инцидентов из-за проблем в глубинной архитектуре;
• отсутствие тестов, код-ревью и комплексной системы управления качеством разработки;
• необходимость внесения значительных изменений на поздних этапах проекта или изменение бизнес-требований.

Иногда в качестве причины указывают недостаток компетенций разработчиков, но технический долг и плохой код — не одно и то же. Чаще долг возникает как осознанный компромисс, поэтому неизбежен в любом ИТ-проекте.

Пополнение технического долга из бэклога.

На российском ИТ-рынке также говорят о техническом долге в контексте инфраструктурного программного обеспечения и проблемы импортозамещения. По данным исследования OCS, у 25% крупных российских компаний технический долг затрагивает более половины инфраструктурного ПО.

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

Зачем бизнесу следить за техническим долгом

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

Скрытые в архитектуре и коде проблемы влияют на окупаемость проектов и конечную прибыль. Ниже — общие последствия технического долга:

• замедление разработки, когда до 40% времени команды уходит на поддержку вместо развития продукта;
• учащение аварий и простоев в работе сервисов из-за нестабильной архитектуры;
• учащение аварий и простоев в работе сервисов из-за нестабильной архитектуры;
• невозможность быстро реагировать на новые бизнес-требования и потеря гибкости продукта;
• выгорание команды и текучка кадров из-за необходимости постоянно «тушить пожары».

Как рассчитать стоимость технического долга

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

Если команда разработки использует систему спринтов, самый простой способ оценить размер техдолга — посчитать, во сколько обходятся потери времени в спринтах.

Другой вариант — посчитать стоимость изменений кода, времени на исправление ошибок, исходя из доли технических задач в бэклоге.

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

Команды разработчиков используют академические метрики и стандартизированные формулы, например, модель SIG, модель COCOMO II, CISQ ATDM. Последний применяют, если нужно автоматизировать расчет.

Этот стандарт от OMG/CISQ основан на подсчете нарушений паттернов кода и оценке усилий на их исправление. Для каждого типа нарушения (например, SQL-инъекция) задано базовое время исправления (например, 90 минут). Оно умножается на количество вхождений и поправочные коэффициенты (сложность, связанность, концентрация).

Какие решения проблемы бывают

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

Мы занимаемся заказной разработкой более 15 лет. Были случаи, когда на поддержку приходили проекты со значительным техническим долгом. Иногда действовать приходилось радикально — переписывать код с нуля. Это было дешевле и быстрее, чем вносить изменения в легаси.