Термин “технический долг” вводит в заблуждение:
- есть ощущение, что что-то нужно отдавать
- есть ощущение, что это реально отдать
На самом же деле, ни первое, ни второе не верны.
Что такое технический долг? Это что-то не связанное непосредственно с фичами продукта, но вызывающее у нас какую-то боль. Примеры:
- зп у специалистов в технологии выше, чем у конкурирующих (Oracle?)
- технология уже настолько устарела (Cobol) (или наоборот настолько молода), что трудно найти готовых специалистов на рынке (да и просто готовых ее учить)
- продукт нестабильно работает
- при аудитах безопасности постоянно находят кучу проблем и непонятно как это “нормально” решить
- код или технология слишком сложные: требуется повышенная квалификация сотрудников и больше времени
- …
Иногда технический долг рассматривают более узко: как что-то ухудшающее опыт разработки. Это обычная позиция разработчиков. Более узкое трактование так же не влияет на необходимость отдавать и возможность всё отдать.
Можно выделить основные группы проблем:
- нефункциональные (скорость, стабильность, системные требования, …)
- отдела кадров: трудно найти, дорого найти, часто увольняются, быстро падает мотивация
- юристов: эффективное соблюдение требований законов, сомнительные лицензии
- безопасников: по возможности решение проблема на уровне технологий, быстрые обновления безопасности для технологий
- ux: по возможности решение проблема на уровне технологий (особенно функции доступности для людей с ограниченными возможностями)
- dx (опыт разработчика): медленно писать, изменять в куче мест, хрупкий код и т.п.
Можно ли выплатить весь технический долг? Нет:
- это очень дорого
- это остановит продуктовую разработку, а значит во многом и увеличение продаж
- даже если попытаться это сделать (останавливаем разработку и идем по созданным задачам тех. долга), то поймем, что можем еще столько же задач написать (не менее длительных, но, надеюсь, уже менее критичных). Т.е. он бесконечен.
Если долг нельзя выплатить, то это уже неправильное название. Гораздо больше подходит “техническое несовершенство”. Тут уже все понятно: да, что-то не так, но совершенство недостижимо, нужно смотреть что нам действительно сейчас мешает, и только это исправлять.
Программирование – это во многом ремесло. Если у человека нет навыка (даже просто знаний часто недостаточно), то он производит некачественный код (относительно опытного человека). Так же слабый программист часто снижает качество своего кода, чтобы поспеть за сильным программистом в команде. Всё это может быть приемлемо, может быть нет. Т.о., есть технический долг, который появляется просто от развития продукта и технологий, а есть от несовершенства людей в команде.
Время от времени встречается подход когда сначала программируют с пониженным качеством, а потом берут отдельные спринты на его повышение. Если в этом есть какой-то бизнес-смысл (например, успеть к открытию выставки), то нормально. Если же такого смысла нет, то скорее вредит: баги исправляются тем легче/быстрее, чем они свежее.
Выводы:
- Технический долг – отвратительный термин. Лучше техническое несовершенство. Еще лучше его вообще не использовать (и не думать в этом термине).
- Забота технических лидеров вовремя выявлять потребности бизнеса (прежде всего непродуктовые, т.к. продуктовые выявляют специально обученные люди).
- Так же задача технических лидеров выставлять планки качества для компании, продуктов, отдельных фичей. И своевременно их обновлять, т.к. ситуация со временем меняется.
- Выявленные потребности преобразуются в задачи и приоритизируются.
- Другой вариант – обучение людей, введение автоматических вспомогательных и проверочных утил. Сюда же относится изменение политик работы: это вариант длительной и медленной переработки существующей кодовой базы. Длительное и медленное – это не только минус, но и плюс: есть прогресс, он постепенный с набором опыта (а значит более эффективный), нет полной остановки других задач.