Технический долг: вечная проблема или умение управлять ИТ-проектом?

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

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

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

Примеры:

Большая древняя база данных без бэкапов - потянул время, она упала, все потеряно.

Монолитный и запутанный код (легаси) - нужно организовывать и планировать рефакторинг, но главное - планово и не тупить. Забил - получаешь накопленные баги, которые с каждым месяцем растут. Ведь разработчики занимаются правками и доработками вслепую, что неизбежно влечет баги. И тут уже мы встаем в позу: нам либо править баги, либо планировать рефакторинг. Как правило, начинают делать и то и другое, так как в этот момент уже понятно, что мешает, и понятно, что баги уже видят пользователи. И это уже другие накладные расходы. Эффективность такого ИТ-менеджера сразу вызывает вопросы.

Любой сложный вопрос требует системного подхода.

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

Во-вторых, вам нужно опередедить минимальный %, который должен быть закреплен за командой каждый квартал, и это первая важная договоренность с бизнесом. Обычно это 20%, но важно отметить, что это минимальный порог из моей практики. В зависимости от ресурсов и команд, на какое-то время в каких-то командах он может быть выше. Например, у меня в практике было так, что 2 команды жили год со 100%. Минималка нужна, чтобы больше не возвращаться к этому диалогу и работать в свободном плановом цикле.

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

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

Очень часто бытует мнение, что бизнес может принять риски. В теории да, но это не всегда так просто сделать. Важно выполнять все шаги, рассмотренные выше, и рассказать об этом всем, в том числе ИТ-директору.

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

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

В конце концов, если не мы, то кто?

Если вам нравится то, о чем я пишу, подписывайтесь на мой канал в ТГ и рекомендуйте друзьям https://t.me/carbonka

Я буду рад, если вы попросите раскрыть какую-то тему более детально.