В 2021 году технический долг компаний, вызванный пандемией, составил почти 25% ИТ-бюджета, и более двух третей компаний ожидают, что в 2022 году расходы на него возрастут. Аналогичное число компаний заявили, что технический долг стал причиной замедления их инициатив по цифровой трансформации.
Для компаний, быстро перешедших на новые технологии во время пандемии, наступает переломный момент. Компании по всему миру внедрили новые технологии для поддержки удаленных работников и ускорили выпуск цифровых продуктов в ответ на пандемию. Этот переход обеспечил гибкость, но для многих компаний он обошелся недешево: рост технических долгов.
Почти восемь из 10 компаний увеличили технический долг за последний год, и только 6% уменьшили его, говорится в недавнем отчете Software AG, основанном на опросе более 738 ИТ-руководителей.
Для 56% компаний дополнительный технический долг был необходим для адаптации к меняющимся условиям. Остальные 48% заявили, что взятие на себя технического долга было преднамеренным действием, чтобы быстро воспользоваться новыми возможностями.
“Это было правильное время, чтобы внедрить новые технические решения. Долги для того и нужны, чтобы пережить трудные времена”, – сказал Джеймс Утер, старший ведущий инженер цифровой практики в компании Oliver Wyman. “Организации сделали много быстрых изменений, внедрив новые приложения и новые системы управления. Но теперь им приходится возвращать этот долг”.
Неспособность решить проблемы, связанные с отложенными регламентами, может означать, что компании затягивают цикл инноваций, тратя ресурсы на ранее игнорируемые проблемы вместо того, чтобы удовлетворять грядущие потребности клиентов и сотрудников.
Технический долг оправдан, но есть предел
Точно так же, как кто-то может взять кредит на покупку автомобиля вместо того, чтобы откладывать деньги на оплату наличными, команда инженеров может выпустить продукт, даже если часть кода еще не готова, или команда ИТ-специалистов может запустить приложение сейчас, вместо того чтобы потратить месяцы на его интеграцию с внутренними системами. Это и есть технический долг.
В некоторых случаях технический долг оправдан. По результатам опроса Software AG, 95% компаний, взявших на себя технический долг для поддержки гибридной работы, заявили, что сделали бы это снова, а 86% сказали, что их технический долг был оправдан, поскольку привел к более быстрому запуску продукта.
Недостатком, как и в случае с финансовым долгом, является слишком большой долг или слишком долгий срок его погашения.
Чем дольше сырой код остается без исправлений, тем выше вероятность сбоя. Чем дольше корпоративное приложение находится в изолированном состоянии, тем больше снижается производительность, поскольку сотрудники вручную переносят информацию или переключаются между несколькими системами.
“Когда системы становятся старыми и сложными, люди могут утратить понимание логики их работы, они могут не знать всех возможностей и не предвидеть того, что произойдет, если начать что-то менять”, – говорит Мэтт Макларти, технический директор и вице-президент отдела цифровой трансформации компании Mulesoft.
По его словам, если компании необходимо взяться за большой проект, такой как перестройка системы планирования ресурсов предприятия (ERP), часто бывает трудно найти время на то, что не представляет прямого интереса для бизнеса.
Признание важно, но также важно и управление
Как и финансового долга, технического трудно избежать. Фактически, по данным Software AG, восемь из 10 компаний заявили, что пандемия повысила осознанность собственного технического долга и его и признание.
Признание – это первый важный шаг, говорит Дин Фолкнер, партнер и глава инженерного отдела компании Oliver Wyman. “Технический долг нельзя считать злом”, – сказал он. “Хуже технического долга, когда команда инженеров гонится за чем-то неосуществимым. Это более неэффективно, чем признание технического долга”.
После признания должно наступить время для оценки и управления техническим долгом. Исследование Software AG показало, что компании более уверены в способности сделать первое: 82% опрошенных заявили, что они могут оценить большую часть или весь свой технический долг, но только 58% имеют официальную стратегию управления им.
За это приходится платить. В 2021 году технический долг составил почти 25% ИТ-бюджета, и более двух третей компаний ожидают, что в 2022 году расходы на него возрастут. Аналогичное число компаний заявили, что технический долг стал причиной замедления их инициатив по цифровой трансформации.
“Технологические компании могут хорошо управлять техническим долгом, поскольку все менеджеры являются техническими специалистами, но в большинстве организаций нет руководителя высокого уровня, который разбирается в коде”, – сказал Утер. “Они знают, что работа идет все медленнее и медленнее, но они не понимают, сколько технического долга они на себя берут”.
Открытые стандарты, формализация и постепенные изменения могут помочь
По аналогии с финансовым долгом, можно представить, как лучше управлять техническим долгом. Если у кого-то есть два кредита: проценты по одному кредиту начисляются в размере 20%, а по второму – всего 1%, то имеет смысл сосредоточиться на первом кредите, сказал Фолкнер.
“Вам нужно потратить время на то, чтобы понять значимость долга и соответственно с ним разобраться”, – сказал он. “Это могут быть инженерные работы, но могут быть и изменения требований. А затем вы должны сформулировать и принять свой допустимый технический долг”.
Упреждающие шаги могут помочь минимизировать последующее влияние технического долга. Одним из таких шагов является принятие открытых стандартов, сказал Фолкнер. Это ограничит необходимость переопределения процессов или работ по интеграции.
Другая задача – использовать формализацию и отказаться от жесткой привязки к поставщику, говорит Фолкнер. “Если вы платите поставщикам за независимую интеграцию, то вы оказываетесь заперты в их формате данных и не можете выйти за пределы их систем”, – сказал он.
По словам Фолкнера, компании могут избежать этого, требуя, чтобы любая внешняя техническая работа не только отвечала функциональным требованиям, но и соответствовала их собственным принципам управления архитектурой.
По мнению Макларти, для компаний, пытающихся справиться с техническим долгом, связанным с устаревшими системами, лучше всего подходит поэтапный подход.
“У нас есть много доказательств того, что одношаговые интеграции новых платформ обречены на провал”, – сказал он. “Потому, что трудно мигрировать не саму систему, а данные, которые в ней хранятся. Если у вас есть унаследованная система, вам нужно найти поэтапное решение и постепенно мигрировать”.
