Воплощение ваших идей
через управление проектами

Вверх

Технический долг платёжом красен

Технический долг платёжом красен

20 мая 2021

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

Технический долг – это метафора, описывающая стоимость выбора в пользу быстрых, краткосрочных решений, которые потребуют дополнительной работы в будущем. Как говорится на бытовом языке, это то что нужно бы сделать правильно, но нет времени, знаний, сил, денег или желания. Поэтому делаем как-нибудь и наивно внушаем себе, что однажды исправим это. Потому что думать о себе как о временно плохом менеджере или программисте сейчас и потенциально хорошем - в будущем, психологически комфортнее, чем признаться заранее, что эти “временные” решения на самом деле гораздо более постоянные, чем что-либо еще в организации, где вы работаете. Зачастую к исправлению технического долга возвращаются только после наступления кризиса, когда долг настолько большой, что двигаться вперед практически невозможно. 

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

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

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

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

В своем квадранте технического долга разработчик Мартин Фаулер выделяет четыре типа техдолга:

Другими словами, вы берёте на себя технический долг одним из четырех способов:

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

Все это со временем может привести к срыву сроков  проекта и разрастанию трудоемкости реализации даже простейших фич в программном продукте, длительному исправлению ошибок и частым неуспешным с технической точки зрения проверкам гипотез. Управление техническим долгом может показаться камнем, тянущим на дно весь проект. Программисты и так уже достаточно нагружены работой. Ведь в т.ч. поэтому они и накопили технические долги в созданной ИТ системе. И вам кажется, что поставив команде задачу «разобраться с долгами», вы только повысите уровень стресса у разработчиков. Не тут-то было! Программисты очень часто обожают работать над техническими задачами и исправлять технический долг! Работе команды над техническим долгом зачастую сопротивляются именно заказчик проекта и другие бизнес-стейкхолдеры. Но организации, которые хотят снизить свой технический долг, должны научиться расставлять приоритеты.

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

4 эффективных способа управления техническим долгом:
  1. В большинстве случаев появление технического долга – это красный флаг, означающий, что стратегия проекта не была тщательно продумана. Таким образом, лучший способ справиться с техническим долгом, когда он уже существует, – пересмотреть первоначальную стратегию проекта, выявить слабые места в управлении и процессах, которые вынудили вашу команду взять на себя технический долг, и заполнить эти пробелы. Решение может включать в себя установление новых стандартов написания кода,  пересмотр критериев готовности фич, критериев готовности требований к началу дизайна и разработки.
  2. В гибких проектах технический долг встречается особенно часто. Если вы работаете по скраму, подумайте о выделении в каждом спринте 15-20 процентов ресурсов команды на рефакторинг и исправление недостатков создаваемой ИТ системы. Другой способ – использовать специальный технический спринт для немедленного устранения большого объема технической задолженности. Правда, это сильно нарушает правила скрама. Но вы сами вольны решать, что вам важнее - следовать книжке или исправлять техдолг семимильными шагами. Подумайте о том, насколько устранение технического долга создает ценность вашему заказчику - в текущем и будущем спринтах. Даже если вы не делаете поставки готовой новой функциональности, вы исправляете глубинные проблемы в коде, что упрощает и удешевляет развитие и поддержку ИТ системы. Разве это не ценность? Ваш выбор будет зависеть от объема, сложности техдолга, лояльности заказчика, готовности команды и наличия времени. Ну и приоритетов, конечно же.
  3. Самый простой способ накопить технический долг – это попросить слишком много от ваших разработчиков в сжатые сроки. Или же когда менеджмент “играется в аджайл, хочет гибкого скоупа, но сроки сдвигать не хочет”. Т.е. культр карго, а не аджайл. Поэтому при разработке дорожной карты продукта проконсультируйтесь с инженерами, чтобы убедиться, что ваши ожидания относительно сроков соответствуют их оценкам и понимаю реалистичного. И будьте готовы на компромиссы по срокам и содержанию. Иначе технического долга не избежать. Также не лишним будет определение и согласование со всеми заинтересованными сторонами и командой того, как должен выглядеть финальный результат. Не считайте что-то завершенным, пока оно не будет соответствовать критериям приемки и вызревшим на опыте команды за несколько спринтов побед и поражений критериям готовности.
  4. Еще один способ избавиться от технического долга – его количественная оценка с помощью метрик. Цель состоит в том, чтобы преобразовать абстрактное понятие технического долга в нечто измеримое, чтобы команды могли отслеживать и анализировать его «погашение». Команды могут использовать разные типы метрик в зависимости от требований. Количество дефектов за поставку, за спринт, т.н. “сбежавшие дефекты”, т.е. обнаруженные на боевом окружении после поставки, время цикла дефекта, скорость отклика на дефект  - полезные метрики для мониторинга качества продукта. Улучшения в данных показателях могут в том числе свидетельствовать о снижении технического долга, и наоборот.

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

Иногда бывает сложно определить, какое решение лучше всего подходит для вашего конкретного случая. Всего существует 3 рабочих стратегии:

  1. Погашение долга через рефакторинг кода, замену фреймворка или платформы, которые считаются источником технического долга;
  2. Конвертация долга: замените текущее решение «хорошим, но не идеальным» решением. Это компромиссный вариант, если создание идеального решения слишком дорогое;
  3. Просто смиритесь и живите с этим долгом, потому что рефакторинг может оказаться дороже, чем работа системы с несовершенным кодом. Особенно это касается очень старых и не имеющих критического значения корпоративных ИТ систем.

Однако все таки лучше всего минимизировать последствия технического долга, помня о его причинах и соответствующих профилактических мерах. Перечисленные выше идеи и решения могут помочь справиться с технической задолженностью и заодно улучшить процессы создания поставляемых результатов в вашем проекте, в конечном итоге улучшая качество не только продукта, но и проекта в целом. Что ни говори, а в проекте две самые приятные вещи - это успешные релизы и высокий NPS от заинтересованных сторон! Чего вам и желаем!

 

СПИСОК ИСТОЧНИКОВ:

  1. Technical debt: 5 ways to manage it
  2. Allie Dyer Bluemel (2020) Project managing your way through technical debt
  3. E.Wolff, S.Johann Managing Technical Debt

Все посты