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