Привет!

Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. За годы работы в ИТ я видел десятки команд, которые буквально тонут в техническом долге, но даже не осознают этого. Сегодня хочу поделиться опытом о том, как превратить систему из повторяющихся инцидентов в управляемый процесс.

Как технический долг маскируется под рабочие процессы

Знаете, что самое коварное в техническом долге? Он умеет притворяться обычной рутиной.

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

McKinsey — до 20% бюджета на новые продукты уходит на технический долг

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

Вот несколько симптомов растущего технического долга:

• скорость команды становится меньше;

• постоянно появляются быстрые фиксы на проде, чтобы закрыть какие-то дыры;

• растет MTTR (время восстановления после инцидента);

• увеличивается количество hotfix-ов;

• падает velocity команды.

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

Пример из практики: иерархический список задач

У нас в SimpleOne SDLC был выпущен красивый иерархический список для задач. Он выглядел очень эффектно, но функционально не позволял выполнять большинство операций: там не было инлайн-редактирования, не было фильтров. При этом на обсуждение любых доработок этой функциональности уходило несколько часов, если не дней.

Приносило ли это бизнес-ценность компании? Вопрос.

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

Разрыв между разработкой и поддержкой

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

JPMorgan Chase — сотрудники теряют до 12 часов в неделю на поиск информации, заблокированной в разрозненных системах

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

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

Подробнее о том, как бороться с «бункерами», вы можете прочитать в нашей статье на Хабре.

Откуда брать данные о техническом долге: три источника

Теперь поговорим о том, где искать информацию о техническом долге.

Источник 1: поддержка и Service Desk/ITSM/-система

Если инциденты постоянно падают на какой-то модуль, мы понимаем, что плотность дефектов на этот модуль становится слишком большой. Видимо, надо что-то с модулем сделать — оптимизировать, переписать.

Идеально, когда техническая поддержка не первым делом бежит к разработке с инцидентом, а пытается исправить сама и заносит это в известные ошибки (Known Errors) в базу данных KEDB. А команда разработки время от времени разбирает эти известные ошибки, видит частотные дефекты или инциденты.

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

Инциденты нужно исправлять сразу, когда они появляются. Когда я работал в другой компании, у нас в какой-то момент было так много инцидентов, что мы занимались только ими. Это была проблема, связанная в том числе с техническим долгом. Мы поправили часть долга — и нагрузка упала.

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

Источник 2: сама разработка

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

Проблемы, о которых чаще всего говорят разработчики:

• архитектурные подходы — когда решили не делать микросервисы, а делать монолит, изначально не предполагали, что сервис сильно разрастется и придется переписывать;

• технологическое устаревание — возможно, надо было заложить модульный монолит, который позволил бы быстрее перейти на микросервисы;

• костыли — временные решения, которые стали постоянными.

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

Пример: графовый сервис

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

Через полгода мы все-таки переписали сервис. Во-первых, ускорили аналитику раз в 10 за счет изменения базового процесса. Во-вторых, сделали его супер понятным. 

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

Бизнес думает: все хорошо, все написали, все работает, все отлично. А что под капотом — непонятно.

Источник 3: метрики продукта

Некоторые метрики — это триггеры о том, что нужно задуматься о техническом долге.

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

DORA Research: 2025 — у команд с высоким change fail rate время на неплановые работы в разы выше, чем у лидеров

А вот рост времени на поддержку новой фичи — это уже прямой показатель, что можно проанализировать, какие модули чаще исправляем, и переделать их. К прямым индикаторам также можно отнести defect density (плотность дефектов) — показывает, где у нас дефектов больше всего, в каком модуле, и мы понимаем, какой модуль стоит поправить, и change fail rate — то же самое, показывает появление дефектов или инцидентов относительно модуля.

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

Как встроить управление техническим долгом в процесс разработки

Главная идея — технический долг не должен быть отдельной инициативой. Он часть общего бэклога.

Единый бэклог для всех типов задач

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

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

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

Проблема как тип задачи в ITSM

Когда проблема из KEDB заносится как тип задачи, она становится задачей на разработку.

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

Очень удобно, когда все процессы находятся в одном продукте. Как только это в разных продуктах — команда разработки уже никогда не зайдет в другой сервис. Обычно просто потому, что не знает о нем. Или зачем? У нас есть Jira, есть тест-трекер, есть задачи, мы их делаем. Зачем заходить в другой сервис, чтобы узнать о проблемах и инцидентах, — непонятно.

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

Роли и ответственность

Важно определить, кто отвечает за каждый этап, чтобы было прозрачное взаимодействие:

• поддержка — выявляет повторяющиеся проблемы;

• управление проблемами — анализирует корневые причины;

• владелец продукта — приоритизирует технический долг в общем бэклоге;

• команда разработки — исправляет.

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

Пример из моего опыта, когда я работал в другой компании: была история из разряда «блин, а кто там у нас в технической поддержке отвечает за наш продукт? Кто может помочь в решении инцидента?». Я пошел к лиду технической поддержки, он мне сказал, что нужно идти к другому человеку, и так эта цепочка может долго не обрываться. Система непрозрачна, и это очень неудобно — никто не знает, у кого какая зона ответственности, к кому обращаться по тому или иному конкретному вопросу.

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

Наш опыт миграции

Мы раньше работали в разных продуктах, это было не очень удобно. Задачи не просвечивались, сложно было перейти с задачи разработки на задачу поддержки. Разные интерфейсы, разные правила, сложно взаимодействовать.

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

SDLC и ITSM — процесс непрерывного совершенствования продукта

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

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

Резюме

Управление техническим долгом — это не отдельная инициатива и не роскошь: это необходимая часть процесса разработки, которая напрямую влияет на скорость поставки ценности пользователям.

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

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

А как вы боритесь с тех долгом?