Три сигнала, что технический долг уже стоит денег

Есть слой экономики ИТ, который редко виден отдельной строкой бюджета - это архитектура и технический долг.

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

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

Сигнал #1. Каждое следующее изменение обходится дороже

Если продукт становится сложнее, рост стоимости изменений нормален. Но если объём и сложность задач сопоставимы, команда примерно та же, а на следующее изменение требуется всё больше времени и людей - нужно смотреть на архитектуру и накопленные зависимости.

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

Сигнал #2. Обычный релиз превращается в событие

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

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

Для бизнеса это означает простую вещь: скорость реакции на рынок падает ещё до того, как что-либо сломалось.

Сигнал #3. Команда растёт, а изменений больше не становится

Если бизнес растёт, увеличение команды нормально. Но если людей в разработке и эксплуатации становится больше, а объём изменений продукта не растёт сопоставимо - стоит посмотреть, куда уходит дополнительная мощность.

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

В этот момент компания масштабирует уже не продукт. Она масштабирует стоимость его поддержки.

Как это увидеть в цифрах

Я бы не начинал с отдельного "индекса технического долга". Для первого приближения достаточно трёх показателей:

• Стоимость изменения. Если сопоставимые изменения несколько кварталов подряд требуют всё больше человеко-дней или денег - разбираю, из чего выросла стоимость. Cost per story point я бы здесь не использовал как главный показатель. Story point - внутренняя и по сути всегда относительная оценка команды: сама шкала со временем меняется. Лучше сравнивать сопоставимые классы изменений, человеко-дни или стоимость конкретного типа изменения.
• RUN / CHANGE. Если всё большая часть мощности команды уходит на поддержку при сопоставимом объёме бизнеса - смотрю, что именно её съедает. Сам по себе рост RUN ещё ничего не доказывает.
• Lead Time for Changes. Если от готового решения до выпуска проходит всё больше времени, а команда, процесс и требования к качеству существенно не изменились - ищу дополнительные зависимости, тесты, ручные этапы и архитектурные ограничения.

Один показатель ничего не доказывает. Если одновременно дорожает изменение, растёт RUN и увеличивается lead time - дело уже не в красоте архитектуры. Это чистая экономика.

Где проходит граница

Технический долг сам по себе не проблема. У любой работающей системы он есть. Вопрос в том, сколько бизнес за него платит.

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

Не "погасить технический долг".
Не "сделать архитектуру правильной".
Убрать ограничение, которое уже стоит бизнесу денег.