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

В первом приближении техдолг - это некоторое количество задач, которые мы должны сделать. Отсюда возникает два вопроса:

1. Что это за задачи?

2. Почему мы становимся должны их сделать?

Технические задачи (техтаски) - задачи, которые:

• не реализуют функциональные требования к системе;

• влияют на процесс разработки или нефункциональные требования. Естественно, что такое определение требует знания как ФТ/НФТ к системе, так и процессов разработки. Если процессы разработки становятся медленнее или система перестает удовлетворять НФТ - у нас, как у команды, появляются проблемы. Появляются они из-за того, что мы своевременно (или заблаговременно) что-то не сделали, и теперь должны приложить усилия(порой и сверхусилия) для стабилизации ситуации. Набор таких не сделанных своевременно задач и является техдолгом команды.

Почему задачи могли быть не выполнены своевременно:

• О них не было известно;

• Не начали работу вовремя;

• Оптимистично оценили свои силы/время на выполнение;

• Нехватка людей/экспертизы;

• Внешние факторы: ургенты/катаклизмы/больничные и т.п.

Внешние факторы скорее относятся к рискам - команда может влиять на них далеко не всегда, поэтому перейдем к тем пунктам, которые относятся непосредственно к процессам в команде и вне ее.

Техбэклог. Узнаем о задачах заранее

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

• Знали, да забыли. Годами висящие тудушки в коде, забытые сроки обновлений версий БД, упущенные договоренности "сделать, как надо" после выпуска бизнес фич (особенно таким грешат задачи категории "срочно и вчера") - большинство команд сталкиваются с подобными ситуациями.

• Не собирали/не анализировали метрики. Не следили за потреблением ресурсов, и вдруг очередной релиз не раскатывается из-за превышения лимитов. Не следили за bug rate и не заметили необходимость рефакторинга. Не следили за пулом коннектов к БД и начали падать при клиентской нагрузке. И так далее.

• Не подумали/не предусмотрели. Не знали, что фича будет развиваться быстро и не заложили архитектуру. Не знали, что потребитель будет закидывать в топик 100500 событий в секунду и нам это нужно быстро обрабатывать. Ясно, что нельзя предусмотреть все - но попробовать то стоит.

• Внешнее не дошедшее (заранее) до команды требование. Переезды инфраструктуры, апдейты версий брокеров/БД. Взлом конкурента и последующие проверки ИБ - мир вокруг движется и развивается, неизбежно затронет и нас.

Все это можно в значительной степени решить посредством "простых" вещей:

• Знать "настоящее": где мы сейчас и что у нас не так.

• Смотреть в будущее. Будущее фичи, проекта, технологий.

• Фиксировать имеющиеся и потенциальные проблемы.

• Смотреть по сторонам: ИБ, смежники, комьюнити, геополитика, новости предметной области и т.д.

Место, куда складируются задачи на решение обнаруженных проблем - технический бэклог команды (техбэклог). Его полнота позволяет минимизировать проблему незнания (если, конечно, бэклог не становится "долгим ящиком", в который никто не смотрит).
Не все из этих задач потенциально перейдут в категорию техдолга: только те, задержка по которым негативно повлияет на бизнес или текущие процессы команды. Разного рода улучшения могут "не выстрелить" никогда, и это нормально - не получится сделать все идеально и поддерживать в таком состоянии на длинной дистанции.
Важно отметить, что есть команды/проекты, где не разделяют бизнес и тех бэклог - обычно в таком случае нет выделенной квоты на тех задачи ввиду сквозного приоритета.
К сожалению, мне в таком режиме поработать не довелось, буду рад увидеть мнения по поводу в комментариях. Но со стороны кажется, что в таком случае необходимость ведения технической части бэклога только возрастает - интересанты на бизнес задачи есть всегда, а вот про техтаски до известного всем момента с домашней птицей никто, кроме команды, и не вспомнит.

Планирование. Стремимся начинать работу вовремя

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

• Планирование силами лида;

• Выделение отдельной роли;

• Автоматизация через расчет score (RICE/ICE и т.п);

• Демократия (выбирает вся команда);

• Анархия (что хочу - то и беру).

Оценка. Учимся на своих ошибках

Часто разработчики промахиваются в оценках в худшую сторону. Более того, техтаски порой и вовсе не оцениваются. Частично проблема решается качественным планированием и приоритизацией - все таки набор задач на итерацию подразумевает учет затрат на их выполнение. Тем не менее, проблема полностью не решается (ну или я не знаю применимых в жизни решений) - все равно будут недооцененные задачи.
Поэтому тут стоит идти итеративно - периодически оглядываться назад, проводить рефлексию и учитывать полученный опыт в дальнейшей работе. Главный друг в таком подходе - фиксация ожиданий/реальности. Иначе выводов будет делать не из чего, а субъективные ощущения могут быть обманчивы.
Конечно, можно еще и на чужих ошибках учиться. У меня получается с трудом, буду рад, если у вас дела с этим лучше)

Ресурсы/экспертиза. Аргументируем, ищем, выращиваем.

Случаются ситуации, когда проблема есть, а решить ее некому - либо никто не в курсе технологии (или предметной области), или банально все заняты. Без построенного планирования подобные задачи гарантированно попадают в разрад техдолга. При построенном планировании решение ложится на плечи менеджмента в команде - найти ресурс/экспертизу к нужному моменту:

• Объяснить риски/профиты руководству/бизнесу и высвободить ресурсы(это про человекочасы и т.п.) и (или) привлечь внешнюю экспертизу;

• Запланировать получение экспертизы внутри (изучить/научиться самим до начала выполнения задачи). Для любого из вариантов нужно каким-то образом понимать, насколько хорошо мы справляемся c входящим потоком тех задач:

• Сколько их у нас;

• Сколько из них уже стали техдолгом;

• Какая доля задач становится техдолгом сразу в момент появления;

• Какая доля задач "эволюционирует" в техдолг;

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

Что в итоге

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

• Формирование тех бэклога;

• Приоритизация и планирование;

• Ретроспективы, пост мортемы и прочие методы рефлексии;

• Сбор и контроль метрик;

• Управление ресурсами и экспертизой.

В обмен команда получает возможность работать более предсказуемо, спокойно и уверенно.
По крайней мере мне с введением всего описанного жить и работать стало гораздо комфортнее, чего и вам желаю)