Стратегии работы с техническим долгом #

Статья вдохновлена докладами с TechLead Conf и личным опытом системной работы с техдолгом.

Что такое техдолг и зачем он мне? #

Техдолг — это аналог кредита в банке: ускорение разработки сейчас путём замедления в будущем.

Техдолг увеличивает энтропию ПО:

Энтропия ПО (Software Entropy) — это деградация эффективности дальнейшей разработки программного обеспечения с течением времени.

Если техдолг игнорировать, то энтропия ПО уничтожит команду:

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

Управление техдолгом позволит продукту жить намного дольше.

А почему нельзя без техдолга? #

Есть метафора из сферы финансов: код — это пассив, а не актив.

Код забирает деньги и требует затрат на сопровождение
Продукт может принести деньги, окупив затраты на код

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

Оценка и учёт техдолга #

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

Какую именно задачу он возьмёт?
А способен ли он её сделать ?
Насколько она полезная в сравнении с другими?
Сколько времени она займёт согласно оценке?
Какова точность этой оценки?

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

Поэтому техлиду надо копить заметки о техдолге заранее:

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

Занимайтесь не только добавлением в бэкелог техдолга, но и груммингом (триажем).

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

Как найти время на техдолг #

На техдолг нужно время. Есть 6 способов найти время на исправление технического долга:

Налог на фичу — вы берёте техдолг как часть плановых работ над фичей, появлению которой мешает техдолг
- пример: перед добавлением арабской версии сайта привести в порядок механизм интернационализации
- пример: перед редизайном уведомлений, отправляемых на email клиентам, сделать новый механизм генерации писем из шаблона: с i18n, удобным языком шаблонов, снапшотными тестами
- риск: налог на фичу может сильно увеличить оценку или добавить неопределённости
- возможность: иногда с налогом на фичу оценка либо не меняется, либо становится стабильнее
Квота X% — вы договаривайтесь с владельцами/менеджерами продуктов, что 10/25/50% в времени будет уходить на технические задачи
- риск: технические задачи могут включать не только техдолг, но и дежурства, решение проблем производительности, инфраструктурные задачи и так далее
- риск: на практике могут быть попытки «откусить» часть квоты под бизнес-задачи, поскольку в моменте они выглядят важнее
Остаток периода — вы договариваетесь с владельцами/менеджерами продуктов, что в конце квартала или года остаток времени уйдёт на техдолг
- минус: этого остатка очень мало
- риск: остаток будет «съеден» текущими бизнес-задачами и «долгами» команды по ним
Выходные дни — разработчик исправляет проблемы вне рабочего времени
- очевидно, что это будет либо добровольно по желанию разработчика, либо с нарушением ТК
- риск: борьба с техдолгом во внеурочное время крайне демотивирует
- работает, наверное, только с техническими улучшениями, если разработчик очень хочет их получить
Выделенная команда — в продукте выделяют подкоманду, которая занимается техдолгом
- риск: не все разработчики в восторге от такой роли
- такой команде по-прежнему надо определять приоритеты и грамотно расходовать время
- такие команды часто называют «командой ядра» (core team)
Когда нечем заняться — когда разработчику в моменте нечего делать, он берётся за техдолг
- риск: неочевидная нагрузка на другие узлы в цепочке создания ценности (value stream) снизит продуктивность команды
- риск: задачу на техдолг берёт кто угодно, а не тот, кто сделал бы её лучше
- риск: крупный техдолг сделан не будет

Из личного опыта:

лучше всего работают методы «налог на фичу» и «квота в X%»
- налог на фичу работает как фильтр действительно важного техдолга
- квота в X% требует «продажи» этой идеи бизнесу
точно не стоит полагаться на методы «остаток периода» и «когда нечем заняться
очень мотивированные люди могут сделать ключевое изменение во внерабочее время
- это происходит спонтанно
- на этом нельзя строить стратегию команды или компании»

От техдолга к техническому улучшению #

Суть идеи такова:

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

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

Примеры технических улучшений:

Выделить общие CI/CD Components в Gitlab для похожих сервисов
Автоматизировать публикацию из markdown-файлов репозитория в корпоративную Wiki
Автоматизировать генерацию описаний Merge Request в корпоративном Gitlab с помощью AI (LLM)

Внедрение метода «налог на фичу» #

Этот метод прекрасно внедряется снизу вверх.

Начните вести бэклог техдолга и технических улучшений заранее
Оценивайте, сколько времени добавит конкретное улучшение к оценке фичи
- бывает так, что и с разработкой технического улучшения, и без него оценка фичи примерно одинакова
- в этом случае смотрите на риски: насколько вы уверены, сделать техническое улучшение получится? А какие проблемы появятся без него?
Занимайтесь «продажей» конкретных улучшений и команде, и руководству

Внедрение метода «квота X%» #

Этот метод внедряется только решением или разрешением «сверху».

Начните вести бэклог техдолга и технических улучшений заранее
Аккуратно выбирайте конкретные задачи — иначе вы дискредитируете свою квоту
Показывайте результаты, чтобы защитить квоту времени от посягательств
Будьте готовы адаптировать квоту в обе стороны
- завышенная квота времени должна быть честно снижена
- заниженную квоту можно повысить, «продавая» эту идею руководству