Долг платежом красен

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

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

С подобным выбором сталкивались практически все развивающиеся проекты, и именно из этого выбора появилось понятие технического долга, впервые сформулированное Вардом Каннингемом (Ward Cunningham) в 1992 году.

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

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

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

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

Отсутствие автотестов, низкая частота релизов, отложенный рефакторинг, жесткая связанность компонентов инфраструктуры, отсутствие стандартов и компетенций – всё это признаки проблем с квалификацией команды.

Если же эти принципы нарушаются, то возникает вопрос о квалификации команды разработки.

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

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