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

Из последствий можно выделить:

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

Откуда берётся технический долг?

• Сжатые сроки. Давление со стороны бизнеса и/или менеджмента может заставить команду принимать решения, которые не соответствуют лучшим практикам.
• Недостаток ресурсов. Сильно связан с предыдущей причиной: разработчики выбирают более простые решения вместо более сложных, но более надежных и более «дальновидных».
• Частые изменения в требованиях заставляют команды постоянно модифицировать существующий код, что может привести к ухудшению качества.
• Недостаток документации. Если код не документирован должным образом, это может усложнить его поддержку и развитие в будущем.

Идентифицировать техдолг можно в следующих разрезах:

• По кодовой базе. Некачественный или неэффективный код, который сложнее (бизнесу: дороже) поддерживать.
• По архитектуре. Когда затруднено масштабирование или интеграция новых функций.
• По тестированию. Недостаточное покрытие тестами может привести к росту ошибок и проблем доступности программного продукта в будущем.
• По документации. Отсутствие оной или устаревшая документация, затрудняющая понимание кода.

Как бизнесу бороться с техническим долгом?

1. Осознать его неизбежное существование.
2. Формировать с командами приоритизированный бэклог задач на его минимизацию в зависимости от влияния на проект. В рамках этого бэклога могут быть задачи на обновление документации, рефакторинг уже существующего функционала, обновление архитектуры и инфраструктуры
3. Начинать включать работу с техдолгом в план разработки. Идеально - если под этот пул задач есть фиксированная квота, но для сложных, вышедших из управляемости ситуаций лучше данную квоту делать динамической.