Как управлять техническим долгом, чтобы балансировать между качеством, сроками и бюджетом проекта?

Эффективное управление техническим долгом

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

При разработке программ часто не хватает времени на всё, что хотелось бы сделать. Разработчикам приходится выбирать самые важные задачи и делать в первую очередь их. Обычно больше времени уделяют тому, что видит пользователь. Оставшиеся задачи относятся к улучшению кода и инфраструктуры проекта — такие задачи называют техническим долгом.

Чем он опасен?

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

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

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

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

Все эти факторы делают технический долг серьезной проблемой, которую опасно пускать на самотёк. Эффективное управление техническим долгом обеспечивает более стабильную, быструю и экономичную разработку продукта.

Причины технического долга

Что не является техдолгом?

Беспорядок в коде – это не технический долг.

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

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

Опасность здесь в том, что зачастую этот аргумент ошибочен, поскольку динамика техдолга не соответствует динамике финансовых кредитов. Принятие на себя техдолга для ускорения выпуска продукта работает только в том случае, если вы остаётесь ниже линии design payoff line в гипотезе об устойчивости архитектуры, а разработчики часто пересекают её уже через несколько недель, а не месяцев.

Если вы берете техдолг и при этом находитесь выше design payoff line, то вы всегда задержите delivery (по сравнению с опцией сначала спроектировать, а потом сделать).

На графике показана зависимость разработанной функциональности (cumulative functionality) от времени для двух воображаемых типовых проектов:

• проекта с хорошим дизайном
• проекта без дизайна

Проект, в котором нет дизайна, сначала разрабатывается быстрее, потому что не тратятся никакие усилия на проектирование.

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

Mind-map «Эффективное управление техническим долгом»

• Как не повредить развитию бизнеса, постоянно отдавая технический долг

• Как выстроить процессы так, чтобы не копить технический долг и планово его устранять

• Как поступить с человеком, который допускает ошибки на проекте

Квадрант техдолга

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

Мартин Фаулер использует квадрант для объяснения аналогичных понятий, где он указывает, что бесполезно обсуждать, является ли что-то долгом или нет, лучше спросить, является ли это необдуманным или обдуманным. Чем больше вопросов, направлений находится в зоне "Обдуманный", тем лучше.

✓ Что поможет – продуманный план того, как решить проблему техдолг в будущем.
Не позволяйте ему вырасти за пределы вашей способности его погасить.

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

Квадрант Обдуманный/Умышленный

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

Квадрант Неосознанный/Умышленный

✓ Единственное, что поможет: изменение культуры.

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

Квадрант Неосознанный/Неумышленный

✓ Что поможет: обучение членов команды.

✓ Что поможет: продуманный план того, как решить проблему техдолг в будущем.
Не позволяйте ему вырасти за пределы вашей способности его погасить.

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

Квадрант Обдуманный/Умышленный

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

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

Квадрант Осознанный/Неумышленный

Этот вид технического долга неизбежен
и происходит постоянно. Устаревшие конструкции становятся техдолгом.

Где трэкать техдолг?

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

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

Телеграмм канал

Подключайся к комьюнити опытных инженеров