Стратегии снижения технического долга без ущерба бизнесу
изображение создано нейросетью
IT-World выяснял, как найти баланс между скоростью вывода новой функциональности и поддержанием здоровья кодовой базы.
Технологический и технический долг — это неизбежная часть разработки программного обеспечения, с которой сталкивается каждая продуктовая компания. Бизнес стремится быстрее выпускать новые возможности, а разработка хочет делать все качественно и основательно. В погоне за скоростью команды часто жертвуют качеством кода, документацией и тестированием, что со временем затрудняет развитие продукта.
Меня зовут Артем Герасимов, я владелец продукта для разработки программных продуктов и решений на основе гибких методологий от компании SimpleOne (входит в корпорацию ITG) — SimpleOne SDLC. В статье расскажу, как найти баланс между скоростью вывода новой функциональности и поддержанием здоровья кодовой базы и поделюсь примерами из практики.
Содержание:
Природа технического долга
Многие компании начинают гнаться за скоростью разработки и выпуска новых фичей, из-за чего забывают о фундаменте, нужном для стабильного развития. В результате образуется технологический долг в разработке, аналитике и тестировании: команды пропускают написание документации, откладывают автотесты, в итоге сроки разработки увеличиваются, а поддержка ИТ-системы становится дороже.
При этом ситуация, когда технический долг минимален, — это скорее редкость. Все гонятся за деньгами, а деньги приносит новая функциональность, для которой даже не нужен идеальный код. Бизнес всегда ищет возможность увеличить прибыль за счет скорости разработки, из-за чего качество может страдать. Если смотреть на ситуацию в целом, можно выделить несколько основных причин накопления технического долга:
- Фокус на скорости выполнения продуктовых задач. Как только скорость выпуска новой функциональности становится важнее всего, команда начинает упускать важные дефекты и инциденты.
- Отсутствие учета долга, когда проблему обсудили, но сразу же забыли о ней. Это приводит к накоплению проблем, потому что никто не знает реального объема долга и не успевает вовремя принять стратегические решения.
- Отсутствие практики работы с техническим долгом. Продуктовые менеджеры не считают это приоритетным, а разработчики не умеют объяснить владельцу продукта, почему нужно уделять этому время.
- Отсутствие технического лида, который следит за качеством кода. Разработчики стремятся сделать больше фичей, потому что им платят за функциональность, а не за идеальную реализацию.
При этом те компании, которые готовы закладывать время на качественную реализацию и умеют учитывать технический долг, могут сокращать его до некритичного уровня, который не сильно влияет на будущее развитие. Но бизнес чаще выделяет ресурсы на новые фичи, потому что они приносят понятные и осязаемые деньги.
Технический долг: вызов или возможность? Как управлять наследием разработки и сохранять баланс в развитии ИТ-систем
Например, мы захотели внедрить новую платежную систему — эта функциональность привлечет сотни пользователей, из-за чего прибыль вырастет, поэтому бизнес ставит задачу реализовать фичу в сжатые сроки. Чтобы быстрее выпустить функциональность, разработчики решают, что сейчас не будут закладывать масштабируемость базы данных. В итоге может возникнуть такая ситуация: мы начнем быстро наращивать количество пользователей, а система начнет замедляться, потребуется больше ресурсов на поддержку решения. Хорошо, если разработчики предусмотрели ситуацию, в которой база данных выйдет из строя. Если они этого не сделали, то потеря транзакций может нанести ущерб репутации и прибыли компании.
Как распознать проблему
Для отслеживания технического долга существуют как прямые, так и косвенные метрики. Использование прямых метрик возможно, когда мы начинаем вести учет долга. Один из инструментов для отслеживания — CFD-диаграмма, которая показывает, насколько сильно растет бэклог по сравнению со скоростью разработки. Если видим, что количество задач растет намного быстрее, чем мы успеваем их решать — пора принимать меры. Однако чаще всего учет не ведется, поэтому приходится смотреть косвенные метрики:
Для оценки технического долга нужно понимание, как он влияет на будущую функциональность. Если разработчики могут показать, что конкретный долг не позволит реализовать нужную функциональность, бизнес охотнее вкладывается в его устранение.
Стратегии работы с долгом
Существует четыре базовых варианта действий, когда в компании образуется технический долг:
- Ничего не делать и надеяться, что ничего не сломается
- Частично править без определенной стратегии
- Стратегически переписывать модуль за модулем
- Полностью переписать с нуля
Редко компании выбирают последний вариант — он самый дорогой и сложный, но именно полное переписывание продукта позволяет изначально предусмотреть все упущенные нюансы. Особенно если долг связан с архитектурными решениями, например, когда приложение написано как монолит с большими зависимостями из-за нехватки времени на правильное проектирование. Переписать такой монолит очень сложно, проще сделать новое решение с учетом всех потребностей и более качественной архитектурой.
Как таковых готовых решений для управления долгом нет, но есть несколько основных рекомендаций. Первое и главное — нужно ввести культуру управления техническим долгом. Для этого необходимо начать его учитывать и обучить разработку заводить отложенные задачи в определенном месте, чтобы все накапливалось централизованно. Даже начать вести учет в чате уже хорошо, в будущем эти заметки можно перевести в полноценные задачи внутри системы для управления разработкой.
Жизненный цикл разработки на low-code
Следующий важный момент — объединение всех задач в общем бэклоге. Обычно при разработке продукта в продуктовый бэклог вносят новую функциональность, а техдолг ведут отдельно. Идеальный вариант, когда бэклог единый, где и новые фичи, и долг приоритизируются одинаково, с использованием моделей приоритизации, например, WSJF, RICE или MoSCoW. Если компания против единого бэклога, можно использовать канбан-доски, выделив отдельную дорожку под техдолг и установив минимальный WIP-лимит. Либо при планировании выделять определенный процент задач, например, 20%, на работу с долгом. Правда, такой подход часто проваливается — бизнес все равно просит делать что-то более важное, или эти 20% забивают мелкими незначительными задачами.
Также я не могу рекомендовать делать отдельные спринты только под исправление дефектов — это выматывает разработчиков, потому что они, как и все мы, любят создавать что-то новое и не любят разбираться в чужой работе. Важно понимать, что в любом случае скорость разработки новых фичей замедлится, поскольку ресурсы будут частично переключаться на технический долг. В конечном счете успех в управлении техдолгом зависит от правильного баланса между скоростью разработки и качеством реализации, а также от выстраивания процессов, которые позволяют системно работать над улучшением кодовой базы без критического замедления развития продукта.
От проблемы к инновациям
Существуют показательные примеры, когда объемный технологический долг становится стимулом для инноваций. Возьмем продукты Atlassian — у них есть разделение между серверной и облачной версиями Jira. Серверная версия написана много лет назад, там много легаси-кода, неудобных UX-решений, сложных зависимостей в реализации и уязвимостей. В какой-то момент было принято решение не развивать ее дальше, а в облачной версии была начата масштабная переработка — переход на новый стек, с Java на Kotlin. За счет того, что это облачное решение, они могут больше тестировать и проверять, потому что можно в реальном времени выпускать новые релизы. Для серверных версий, которые устанавливаются у компаний, такое частое обновление слишком дорого. В результате облачная Jira сейчас на несколько порядков лучше серверной.
Похожий опыт был у одной из петербургских ИТ-компаний — команда начинала с создания MVP и для разработки использовала устаревший фреймворк. Со временем стало понятно, что он не выдерживает нагрузку, и была разработана новая версия платформы на Java. Благодаря этому решению компания смогла запустить несколько дополнительных продуктов и расширить влияние на рынке. В прошлом году платформа даже получила награду «Цифровой прорыв в промышленности».
Резюме
Технический долг — это не всегда проблема, иногда он становится катализатором позитивных изменений. Когда накопленные технические решения начинают тормозить развитие продукта, команды находят в себе смелость делать радикальные шаги: переписывать системы с нуля, переходить на новые технологии, менять архитектуру. В результате продукт не просто возвращается к нормальной скорости разработки, а получает второе дыхание и возможности, которые были недоступны раньше. Читайте также
Продукты года 2025 Революционные перемены, произошедшие на российском рынке в последние годы, привели к кардинальному изменению ландшафта, а соответственно, и имен победителей, заслуживших нашу главную награду — Продукт года. Впрочем, есть и несколько брендов, которые не впервой получают наш ИТ-орден, им особая честь и хвала!
Но чтобы технический долг стал точкой роста, а не камнем на шее, нужно научиться им управлять: выстроить процессы учета и приоритизации, найти баланс между новой функциональностью и работой над качеством кода, договориться с бизнесом о выделении ресурсов на технические улучшения. Самое сложное здесь — начать относиться к техническому долгу не как к досадной неизбежности, а как к области для системной работы. Тогда вместо бесконечной борьбы с последствиями мы можем сфокусироваться на предотвращении проблем и создании надежного фундамента для будущего роста.
Артем ГерасимовВладелец продукта SimpleOne SDLC, компания SimpleOne, корпорация ITG