Технологии28.07.2026, 02:152 мин чтенияNEWS

Управление техническим долгом: опыт команды Совкомбанк Технологии

Тимлид Ирина рассказывает, как выстроить системную работу с техдолгом в проекте с 8-летней историей

Управление техническим долгом в Совкомбанк Технологии
КРАТКО

Что нужно знать

  • В проекте с 8-летней историей 80% кодовой базы требовало переработки.
  • Команда внедрила скоринговую карту для приоритизации задач техдолга.
  • Для поиска времени на техдолг важно говорить с бизнесом на языке метрик и выгоды.
ИсточникХабр ↗

Тимлид компании «Совкомбанк Технологии» Ирина опубликовала на Хабре статью, в которой подробно описала подход к управлению техническим долгом в проекте с 8-летней историей. Около 80% кодовой базы требовало глубокой переработки. Команда столкнулась с хаосом в коде, разношерстным стеком, угрозами безопасности и низкой скоростью сборки.

Проблемы проекта

Среди ключевых проблем: сотни пометок TODO и FIXME без контекста, три библиотеки для кэширования с одинаковой функциональностью, устаревшие языковые конструкции, три разных подхода к стилям (scss, tailwind, styled components), сотни уязвимостей в каждом анализе, сборка в dev-режиме более пяти минут. Разработчики тратили 60% времени на понимание «почему это не работает», погружение новых сотрудников занимало месяцы.

План действий

Команда разработала план из четырёх этапов: подготовка и организация процесса, выявление проблем, оценка и приоритизация, поиск времени и ресурсов.

Подготовка и организация

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

Выявление проблем

Провели ручную проверку кода: собрали все комментарии TODO, FIXME, HACK. Зафиксировали технические предупреждения из консоли браузера и терминала, заглушки по типизации (any, unknown, @ts-ignore), предупреждения линтеров. Замерили метрики: скорость сборки, размер бандла, velocity, TTM, количество багов. Использовали инструменты SAST, DAST, SCA, Secret Detection, npm audit. Также создали несколько AI-агентов для конкретных задач.

Оценка и приоритизация

Команда использовала скоринговую карту, позаимствованную у коллег-экономистов. Каждая задача оценивалась по четырём критериям с весами: критичность (40%), влияние на команду (30%), стоимость (20%), бизнес-риск (10%). Приоритет вычислялся по формуле. Для оценки стоимости применяли урезанную последовательность Фибоначчи. Также рассмотрели методики WSJF, матрицу приоритизации и оценку по критериям.

Поиск времени

Ирина рекомендует искать союзников в команде и учиться говорить на языке бизнеса. В статье приведены два примера «продажи» задач: внедрение системы моков и замена устаревшего WYSIWYG-редактора. Для каждого были собраны метрики, текущие значения и прогнозы, что позволило утвердить задачи.

Что это значит

Статья представляет собой практическое руководство для команд, работающих с легаси-проектами. Основной вывод: технический долг неизбежен, но им можно управлять системно, используя приоритизацию, метрики и коммуникацию с бизнесом. Материал опубликован на Хабре в блоге компании «Совкомбанк Технологии».

ВОПРОСЫ И ОТВЕТЫ

Коротко о главном

Какие проблемы были в проекте?

Хаос в коде, три библиотеки для кэширования, устаревшие конструкции, три подхода к стилям, сотни уязвимостей, сборка более 5 минут.

Как команда приоритизировала задачи?

Использовали скоринговую карту с критериями: критичность (40%), влияние на команду (30%), стоимость (20%), бизнес-риск (10%).

Какие инструменты использовали для выявления проблем?

SAST, DAST, SCA, Secret Detection, npm audit, Webpack Bundle Analyzer, Speed Measure Plugin.

Как подготовлен материал

Черновик был создан с помощью AI по указанному первоисточнику и опубликован в формате ITBlogs. Факты следует сверять с оригинальной публикацией.

С
АВТОР

Сергей

Администратор проекта

DISCUSSION

Комментарии · 0

Войдите, чтобы участвовать в обсуждении.