Долг платежом красен. Почему избавляться от техдолга так же трудно, как его накапливать
Любой цифровой продукт можно считать живым организмом: он растет, развивается, претерпевает изменения, участвует в конкурентной борьбе. И, как следствие, «боевые шрамы» от этих изменений выливаются в образование технологического долга. Почему-то, у одних компаний получается этим техдолгом успешно управлять, а другие буквально начинают в нем тонуть. В чем причина растущего технологического долга, и как с ним работать, чтобы не останавливать бизнес-процессы?
Причины растущего техдолга
Причины, по которым у компании может расти технологический долг в конечном итоге сводятся к двум основным категориям: неподходящая продукту культура разработки и неэффективная ИТ-стратегия бизнеса.
Техдолг может расти различными темпами в зависимости от действующей культуры разработки. Здесь могут играть роль особенности цикла разработки, используемые фреймворки, наличие или отсутствие пользовательской и технической документации, версионность и обратная совместимость, вид используемой архитектуры и др.
Не менее важно, существуют ли безопасные способы устранения технологического долга (например, с помощью выпуска версий). Также помогает покрытие регрессионными автотестами – гарантия того, что ключевая функциональность продукта останется рабочей даже после действий по устранению техдолга.
ИТ-стратегия бизнеса играет не меньшую (а возможно, и большую) роль в вопросе темпов накопления технологического долга. Ключевые моменты здесь: есть ли у бизнеса средне- или долгосрочный план по развитию ИТ-продуктов, есть ли у и команды понимание того, что будет происходить через квартал, полгода, год. Это влияет на то, будет ли уже сегодня закладываться фундамент для будущих изменений.
Если, предположим, технической команде ставят задачу: «сегодня делайте проект по плану А», и она 3 месяца следует этому плану, а дальше принимается решение двигаться по плану B, где придется абсолютно всё переделывать, накопление технологического долга неизбежно. Причина тут в том, что новая разработка начинает выстраиваться параллельно с тем, что уже сделано (дополнительно это увеличит расходы на команду, и теперь придется поддерживать 2 версии продукта в рабочем состоянии). А если бы три месяца назад было известно, что в будущем возможна такая ситуация, можно было бы предусмотреть пространство для маневра под эти изменения. Вообще, конечно, чем дальше горизонт планирования, тем лучше, даже если он обозначен только основными вехами.
То есть, важно изначально закладывать возможность масштабирования. Например, при разработке SaaS продукта или B2B-платформы с множеством интеграций, правильным решением будет уже сегодня заложить такую архитектуру, которая позволит эти интеграции доделать. Для этого уже сейчас можно внедрить в решение какую-то КШД (корпоративную шину данных), которая в настоящий момент может и не требоваться. Пусть не смущает, что она на данном этапе кажется избыточной: если есть понимание, что проект движется к тому, что она будет полезной, такой шаг поможет не накапливать большой техдолг и ускорит будущую разработку.
Как не тормозить бизнес-процессы, устраняя технологический долг
На самом деле, и культура разработки, и стратегия бизнеса в идеальном мире должны взаимодействовать на пользу друг другу, тогда и вопрос о том, как внедрять изменения, не затормаживая бизнес-процессы, возникать будет крайне редко. Но мы в идеальном мире не живем, поэтому рассмотрим, какие стратегии помогут минимизировать технологический долг без ущерба для развития продукта.
- Эффективное ресурсное планирование. Можно изначально процессы выстраивать таким образом, чтобы накапливалась качественная документация, код был покрыт тестами и т.п. Команду можно готовить к разделению на две части: одна будет работать над развитием продукта, другая – заниматься устранением техдолга (для повышения эффективности, если продукт уже запущен, этой же команде можно доверить техническую поддержку). Распределяет разработчиков (да и в целом управляет ресурсами по данному направлению) технический лидер. При этом у бизнеса должно быть понимание, какой объем ресурсов будет неизбежно затрачиваться на устранение техдолга. А со стороны техлида необходимо честное своевременное предоставление информации бизнесу для принятия более точных решений, а также прозрачное управление-администрирование этими ресурсами.
Простой пример того, какая подготовка поможет реализовывать эту стратегию эффективней: если есть хорошая техническая документация, то даже тот сотрудник, который не писал код изначально, может, опираясь на документацию, очень быстро разобраться, как устранить долг.
- Замедление команды. В этой стратегии разработчики руководствуются, так называемым, “правилом туриста” (убрать за собой весь свой мусор и захватить немного чужого). При реализации подхода закладывается дополнительное время на выполнение задач. Например, по оценке на фичу потребуется 10 дней, но закладывать нужно 12, чтобы оставить время на рефакторинг всех тех модулей и участков, которыу будут затронуты при работе над этой фичей. То есть искусственно замедляется скорость разработки с тем, чтобы во всех частях кода, которых касаются при разработке, сразу устранялся техдолг. Код ревью осуществляет техлид или CTO (в случае небольшого продукта), который предварительно устанавливает правила для рефакторинга. А любой разработчик, когда касается какого-то участка кода, уже должен знать, каким образом он его будет этот процесс осуществлять.
Как внутри первой, так и внутри второй стратегии помогают инструменты автоматизации, например, так называемые линтеры, статические анализаторы кода и другие. Как это работает: есть определенный код, для него придуманы новые правила. После того, как его проверили статическим анализатором стало понятно, что код на 80% не соответствует принятым правилам. И с каждым следующим релизом нужно следить, начал ли вновь изготовленный код, либо старый изменённый, подходить под эти правила. Это, кстати, снимает часть нагрузки с техлида при код ревью, ведь код ревью – это не основная его задача, он еще и продукт должен успевать развивать.
Инструменты, помогающие отслеживать критический рост технологического долга
Какой-то универсальной системы по решению данной задачи нет, так как продукты очень разные и имеют свои особенности (как минимум, технические). К тому же, в ИТ для одной и той же задачи может быть множество работающих решений. Поэтому расскажу о тех метриках, которые может мониторить владелец продукта, и по которым косвенно можно судить об объеме технологического долга, чтобы дальше предпринимать действия для его устранения.
Это, во-первых, velocity команды. Если вдруг команда стала соразмерную фичу делать либо заметно быстрее, либо заметно медленнее, это однозначно симптом того, что что у тебя накопился долг, или что-то другое идет не так.
Запросы от руководителя ИТ-команды на ее расширение, когда есть сомнения в том, что скорость реально увеличится, тоже могут сигнализировать о том, что есть проблема с техдолгом. Например, руководитель ИТ-команды говорит, что если увеличить команду в 2 раза, то скорость их работы увеличится только на 10%. Это, кстати, не обязательно проверять фактически, добавляя людей, часто достаточно выслушать аргументацию.
Ну и, конечно, такие общепринятые показатели, как количество падений, багов в продакшене, рейтинги мобильных приложений в сторах (это покажет, насколько имеется понимание конечного пользователя и тех фич, которые он ожидает), изменение уровня продаж. Всё это также можно связать с объемом тех долга.
То есть прямых корреляций нет, но за тем, что может оказаться симптомом накопления технологического долга стоит следить. Более того, я бы рекомендовал замерять любые показатели, если это не обходится дорого. Даже если сегодня эти метрики не кажутся существенными. В дальнейшем, например, при привлечении консультантов такие измерения могут оказаться полезными.
Вообще универсального рецепта по снижению технологического долга я (да, пожалуй, и никто) дать не смогу, так как каждый проект уникален. Но я убежден, что для любой ситуации можно подобрать те или иные инструменты. Хотя в вопросе управления техдолгом эффективнее, конечно, продумывать стратегию заранее, предусматривая и возможность для масштабирования, и необходимость внедрения интеграций в будущем. Говоря супергеройским языком: лучше быть предотвратителем, а не мстителем.
Опубликовано 04.02.2025