Привет! Я Ефанов Михаил, Tech Lead в компании Skyeng, и сегодня расскажу, как выстроил работу с техническим долгом внутри нашей команды.

Проблема

Когда технический долг бесконечно оседает в бэклоге и на него никто не смотрит, появляется несколько типичных проблем:

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

2. Бэклог не оценён.
   Тимлид не понимает, сколько времени займёт та или иная задача, что мешает планировать и защищать время под техдолг.

3. Сложно проталкивать QoL-инициативы.
   Когда есть огромный список техдолга, кажется, что нет смысла предлагать улучшения — ведь «и без того работы невпроворот». В итоге мотивация снижается, а долг только растёт.

Внедрённое решение

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

1. Настройка фильтра и состава задач

В доску попадают только задачи с типами Epic, Spike и Tech из основного проекта (у вас могут быть свои типы).

Мы создали сохранённый фильтр:

project = TEAMTAG AND issuetype in (Epic, Spike, Tech) ORDER BY Rank ASC

Чтобы доска не засорялась старыми задачами, добавили подфильтр:

fixVersion in unreleasedVersions() OR fixVersion is EMPTY

2. Структура колонок

Процесс максимально прозрачный и простой:

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

• To Discuss — колонка для подготовки к встрече по техдолгу. Раз в две недели мы собираемся и обсуждаем задачи, которые разработчики хотят поднять.

• Ready for Development — сюда попадают задачи, которые мы обсудили, оценили и приоритизировали.

• В работе — активные задачи, находящиеся в разработке.

3. Быстрые фильтры

Чтобы удобно смотреть задачи по направлениям, мы добавили быстрые фильтры:

• FE — задачи с лейблом frontend

• BE — задачи с лейблом backend

Это помогает быстро сфокусироваться, так как я отвечаю за технический долг FE и BE, но сами синки разделяю на ревью FE и BE технического долга c фронтендерами и бекендерами соответствено.

4. Регулярный груминг техдолга

Каждую неделю проводим встречи с чередованием FE и BE, на которых:

1. Обсуждаем задачи из колонки To Discuss (разработчики заранее туда двигают темы).

2. Просматриваем верх бэклога.

3. Определяем приоритет и оцениваем задачи.

4. После обсуждения двигаем их в Ready for Development.

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

5. Работа с задачами

В любой момент тимлид или разработчик может взять задачу из Ready for Development, начиная сверху.
Это позволяет не «замораживать» инициативы и не терять контекст между встречами.

6. Прозрачность и контроль

Благодаря такой структуре:

• Любой член команды может предложить задачу по техдолгу.

• На встречах видна вся картина — что обсуждалось, что в приоритете, что уже в работе.

• Можно анализировать метрики: сколько техдолга закрывается за квартал, какие области чаще страдают и т. д.

Результаты

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

1. Появился приоритет и прозрачность

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

2. Техдолг перестал копиться «в стол»

Благодаря регулярным встречам и колонке To Discuss, любая проблема имеет шанс быть замеченной и проработанной.
Разработчики видят, что процесс работает — и начали чаще предлагать улучшения.

3. Стало проще брать задачи без хаоса

Когда есть чёткая колонка Ready for Development, не нужно гадать, что брать.
Хочешь помочь — открываешь доску, берёшь верхнюю задачу.
Это экономит время тимлида и снижает когнитивную нагрузку при планировании.

4. Улучшилось качество кода и инфраструктуры

Многие старые костыли, которые висели годами, начали исчезать.
Теперь это плановая, контролируемая работа, а не стихийное «давайте попробуем поправить, если не упадёт».

5. Повысился уровень инициативности

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

Метрики и контроль

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

? Как это работает:

• Каждая задача в Jira помечается лейблом — frontend, backend, qa.

• Дашборд агрегирует данные и считает долю времени, потраченную на техдолг, от общего времени команды.

• Можно задать целевой процент и отслеживать отклонения.

На дашборде отображаются:

• фактические часы, потраченные на продуктовые задачи, техдолг и баги;

• процент отклонения от целевого уровня;

• детализация по типам задач (FE, BE, QA);

• ссылки на конкретные задачи в Jira.

? Пример:
На графике видно, что команда потратила на 191 часов часов больше времени на технический долг, чем планировала (считается на базе процента от времени потраченного на все задачи). Поэтому в ближайшее время большинство задач будут продуктовыми.
Это помогает балансировать нагрузку — если техдолг начинает «съедать» слишком много, мы корректируем приоритеты на следующих планированиях.

Выводы

Работа с техническим долгом — это не про героизм и не про «когда-нибудь потом».
Это такой же процесс, как разработка фич, и он требует своей системы.

Из опыта выделю несколько ключевых принципов:

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

2. Дайте команде голос.
   Пусть разработчики сами поднимают проблемы и предлагают улучшения. Если есть понятный путь от идеи до реализации — инициативы не исчезают.

3. Регулярность важнее скорости.
   Даже один груминг раз в две недели приносит порядок. Главное — чтобы обсуждения проходили регулярно.

4. Приоритизация и прозрачность — ключ к доверию.
   Когда видно, какие задачи обсуждаются и почему, пропадает ощущение хаоса и «вечного долга».

? Если вы уже пробовали выстраивать процесс работы с техдолгом — расскажите в комментариях, что у вас сработало, а что нет.