Хабр, привет! Меня зовут Дима, и я — деливери-менеджер технического отдела «Автомакон». Сегодня хочу рассказать, как мы пересмотрели подход к управлению техническим долгом и чего добились благодаря этому.

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

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

Мы пошли дальше стандартного определения и включили в понятие технического долга такие аспекты, как:

• повышенное потребление ресурсов сервера;

• долгое время выполнения процедур;

• несоблюдение стандартов разработки, созданные архитектором совместно с командами разработки правила работы в стеке SQL;

• доработки для работы под высокой нагрузкой.

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

Этап 1. Оптимизации техдолга: управляемый подход к техдолгу

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

Как это работало:

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

• Менеджер создавал задачи для команды разработки и контролировал выполнение.

Каких результатов удалось добиться:

• Критические угрозы стабильности были под контролем.

• Однако, накопление бэклога задач стало неконтролируемым.

Чтобы техдолг сгорал быстрее, чем накапливается, мы ввели правило резервирования времени: 30% от месячного времени команд отводилось на задачи технического долга. 

Также была внедрена приоритизация по задачам решения техдолга:

• Критичный приоритет — ошибка оказывает значительную нагрузку на систему.

• Высокий приоритет — ограниченная масштабируемость функциональности системы при планируемом росте нагрузки.

• Средний приоритет — проблемы с производительностью, которые могут усугубиться при увеличении нагрузки на сервис.

• Низкий приоритет — незначительные архитектурные недоработки.

Этап 2. Оптимизации техдолга: стандартизация и структурирование

Первый этап прошел успешно и дал свои результаты, но выявил две новые проблемы:

1. Отсутствие стандартизации описания задач.

2. Неконтролируемый рост бэклога.

Разберем каждую проблему и ее решение подробно.

После первого этапа оптимизации техдолга столкнулись с проблемой отсутствия стандартизации описания задач:

• Первичное обращение архитектора требовало уточнений. Заказчик указывал на проблему и конечное решение. Далее в работу вступал менеджер, уточнял требования к выполнению и составлял подробное описание задачи.

Для того, чтобы решить эту проблему, мы создали шаблон для описания задач с четкой структурой — с разделением описания задачи на пункты: с отдельными пунктами для dor, dod, описания проблемы и цели задачи.

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

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

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

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

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

Что дальше?

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

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