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

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

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

Давайте посмотрим, какие неприятности из прошлого нам могут помешать в будущем.

Можно попробовать разделить техдолг на несколько групп: 

• Кодовый - дублирование, необходимость рефакторинга, обновление библиотек;

• Архитектурный - выбрана неправильная архитектура, технологический стек;

• Информационный - нет логов, мониторинга, документации, плохое покрытие тестами. 

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

• Код - баги, рост сложности системы, трудности в масштабировании;

• Команду - выгорание, сложность онбординга новичков;

• Бизнес - недополучает прибыль из-за скорости поставки, влияние на репутацию.

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

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

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

Мы начали с того, что стали выписывать любые замечания по коду в issue к нашему проекту в Gitlab. Нам это показалось удобнее, чем создавать отдельные задачи в таск трекере. Это ближе к коду, можно добавить ссылки и комментарии из merge request-ов в которых найдены недочеты. Такое краткое описание проблемы, которое создают разработчики в процессе работы, а потом уже менеджеры по необходимости переносят их условную JIra, дополняют описание и добавляют в беклог продукта.

После закрытия таски мы закрываем issue в репозитории. Это позволяет наглядно увидеть объем открытых/закрытых задач по этому направлению работ. Можете сразу создавать задачи в ваших трекерах с определенным типом или лейблом, чтобы потом легко фильтровать по нему. Некоторые команды больше надеются на комментарии в кодовой базе. Соберите и визуализируйте их с помощью нескольких шагов из доклада для работы с этим показателем.

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

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

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

Исходя из ситуации на проекте и текущих задач, обратите внимание на такие аспекты:

• Легкие маленькие фиксы. Это поможет быстро показать как это работает, поможет вдохновить всех причастных.

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

• Критичный для бизнеса функционал. Например, вы разработчики “убийцы” ютуба.  Основной функционал - плеер и все, что с ним связано. Лучше держать кодовую базу, тесты и документацию по такому разделу на хорошем уровне.

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

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

Следующим важным этапом работы с техническим долгом - процесс закрытия.  Варианты:

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

• 20% capacity на технические улучшения. Редко когда могут выделить спринт, но можно получить часть каждого спринта на такие доработки. Главное, чтобы хотя бы одна задача влезала в этот объем.

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

• Добавление технических задач для выполнения квартальных планов, метрик. Если в компании есть KPI, OCR или другие формы построения целей на определенный период - добавьте туда и технические показатели проекта как одно из направлений развития.

Надо помнить, что “продажу” работы над техническим совершенствованием проекта надо осуществлять в нескольких направлениях: вверх - от команды бизнесу; вниз - от лида команде. Для этого покажите, какую пользу это принесет, на языке слушателей, в зависимости от того, кому вы это “продаете”. 

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

Не затягивайте с выплатами процентов и старайтесь закрывать микрозаймы как можно скорее.