«Представьте себе, что вы строите замок из кубиков, но постоянно торопитесь, стремясь уложиться в определенное время. Вместо того чтобы аккуратно выравнивать каждый ряд, вы кое-как водружаете детали, думая: «Потом исправлю!» Это и есть технологический долг в миниатюре — когда разработчики выбирают быстрые, но не самые качественные решения, откладывая «правильную» реализацию на потом. Технологический долг коварен тем, что поначалу он почти незаметен. Как кредитная карта с отложенными платежами, он позволяет быстро получить желаемое. Но процент «переплаты» растет в геометрической прогрессии: каждое новое изменение в коде становится все сложнее внедрить, баги множатся, а производительность команды падает.
Масштаб проблемы поистине впечатляет. Согласно исследованию Gartner, до 20% годового ИТ-бюджета средних и крупных компаний может расходоваться на управление и снижение технологического долга. Это включает затраты на рефакторинг кода, обновление устаревших систем и исправление ошибок, возникших из-за первоначальных компромиссов в разработке.
Особенно опасен «невидимый» технический долг — устаревшие библиотеки, отсутствие автоматических тестов, запутанная архитектура. Как ржавчина разъедает металл изнутри, так и технический долг незаметно подтачивает проект, пока однажды все не рухнет под собственной тяжестью.
Но есть и хорошие новости: такой долг можно и нужно контролировать. Регулярный рефакторинг, правильное планирование, инвестиции в качество кода — все это помогает держать долг в разумных пределах. Главное — не делать вид, что проблемы не существует, ведь, как и с финансовыми долгами, игнорирование только усугубляет ситуацию. Умение балансировать между скоростью разработки и качеством кода — настоящее искусство, которым должен владеть каждый ИТ-менеджер.
Откуда долги?
Артем Смирнов, технический директор компании BSL, утверждает, что основными причинами возникновения и накопления технологического долга являются несколько факторов. Во-первых, сжатые сроки разработки и давление со стороны бизнеса. Он отмечает: «Команды часто выбирают быстрые решения в ущерб качеству, чтобы уложиться в дедлайны или удовлетворить краткосрочные цели». Во-вторых, по его мнению, отсутствие продуманной архитектуры на старте проекта приводит к тому, что система становится сложной для масштабирования и поддержки. Со временем это вынуждает разработчиков прибегать к временным решениям, которые впоследствии превращаются в долг. Эксперт также указывает на недостаток документации как на существенную проблему. Если на начальных этапах не уделяется внимание описанию структуры и логики системы, в будущем работа с кодом становится сложной и требует больше ресурсов. Еще одной причиной он называет низкое качество кода, связанное либо с недостаточной квалификацией разработчиков, либо с нехваткой времени на рефакторинг и тестирование. Кроме того, регулярное игнорирование или откладывание обновлений технологий и инструментов приводит к устареванию системы, что также влечет за собой накопление технического долга. Артем отмечает, что все эти факторы взаимосвязаны и в долгосрочной перспективе могут существенно замедлить развитие продукта.
Долг платежом красен. Почему избавляться от техдолга так же трудно, как его накапливать
«Источники технического долга в ИТ-инфраструктуре такие же, как и в программном обеспечении: устаревшие технологии, откладывание решения проблем, отсутствие документации, неправильное проектирование и неудовлетворительное обслуживание, — дополняет Олег Бунин, директор департамента поддержки информационных систем компании «CИГМА». — Причин накопления технического долга всегда две — либо отсутствие политики по внедрению и сопровождению ИТ-инфраструктуры, либо слабый контроль за ее исполнением. Именно в наличии политики по развитию и сопровождению ИТ-инфраструктуры и жестком контроле за исполнением разница между компаниями, которым удается поддерживать технический долг на низком уровне, и компаниями, накапливающими его до критического уровня.
В свою очередь Алексей Захаров, директор по технологическому консалтингу компании Axiom JDK, утверждает, что первая причина возникновения технологического долга — это непонимание реального конечного результата. Он отмечает: «Многие компании-разработчики или отделы разработки внутри организаций при создании ПО пытаются формулировать задачу так, как они ее поняли, а не так, как ее понимает заказчик». Это приводит к тому, что функционал, необходимый для решения поставленной задачи, реализуется лишь частично. В итоге, когда реальный пользователь начинает работать с системой, возникает необходимость корректировок. Следующая причина, по его мнению, — это Agile-подход быстрой реализации базового функционала и постепенной доработки. Алексей подчеркивает, что компания осознает: изначально все продукты не могут быть идеальны и нужно постоянно бюджетировать ресурсы на доработку того, что уже создано. Еще одной причиной эксперт называет непризнание того, что технический долг существует. Такая ситуация складывается там, где компания считает, что если продукт создан или внедрен, то для его модернизации необходимо запускать отдельный проект. Финансирование на то, что уже создано, не выделяется, и, по его словам, «проще инициировать новый проект, из которого «втихаря» доделать то, что было уже реализовано».
Работает, но не развивается
Одним из наиболее частых симптомов накопления технологического долга можно назвать большой объем в компании legacy-решений и «костылей». Legacy-системы, будучи устаревшими технологиями или программными обеспечениями, часто не соответствуют современным требованиям к скорости, безопасности и масштабируемости. «Костыли» — временные решения или обходные пути, которые внедряются для оперативного исправления проблем без глубокого анализа причин. Хотя они позволяют быстро решить возникшую задачу, такие способы часто привносят дополнительную сложность в систему. Однако влияние legacy-решений и «костылей» не всегда однозначно отрицательное. В некоторых случаях legacy-системы продолжают эффективно выполнять свои функции, и замена их может быть экономически невыгодной или сопряженной с большими рисками для бизнеса. Принцип «работает — не трогай» имеет свои основания, особенно когда вмешательство в действующую систему может привести к перебоям или дополнительным расходам. Если система выполняет свои задачи без сбоев и нет критических причин для ее модернизации, то вмешательство может быть необоснованным. Так ли это на самом деле?
«Legacy-решения не обязательно вредны — в некоторых случаях они являются опорой стабильности. Однако стоимость их поддержки и невозможность масштабирования часто становятся препятствием для бизнеса. Что касается принципа «работает — не трогай», это может быть оправдано на краткосрочной дистанции, но для долгосрочного развития компании необходимо планировать обновление таких систем и, если необходимо, обращаться к специалистам», — считает Максим Башарин, управляющий директор ГК A1TIS.
Как отмечает Николай Тихомиров, директор дивизиона технического развития платформенных решений компании «Т1 Иннотех», с точки зрения краткосрочной стратегии подход «работает — не трогай» может быть оправдан. Однако, подчеркивает он, когда речь идет о долгосрочном развитии компании на горизонте 3–5 лет, такие решения превращаются в «якорь корабля, который забыли поднять». Этот якорь, по его словам, будет замедлять движение в самый неподходящий момент и тянуть назад, если не на дно.
Сергей Капралов, ведущий инженер-программист компании Sigur, напоминает, что, помимо влияния на эффективность и производительность, необходимо рассматривать и другие параметры. Он подчеркивает: «Важно иметь способность за вменяемый бюджет выпускать фичи с должным уровнем качества в срок». По мнению эксперта, принцип «работает — не трогай» — палка о двух концах. С одной стороны, этот подход позволяет минимизировать возникновение регрессий, потому что именно изменения, вносимые в старый функционал, их и порождают. С другой стороны, он отмечает, что «это постулат, который делает мышление бизнеса неподатливым в тот момент, когда пришло время что-то менять, а делать это страшно».
Начинаем снижение
Как и в случае с любыми видами долгов, первое, что нужно сделать для решения проблемы, — прекратить накапливать новые долги, а затем сразу же начать их ликвидировать и закрывать. По мнению Артема Смирнова (BSL), для предотвращения накопления технологического долга важно назначить ответственного, например, техлида или тимлида, который контролирует работу с долгом. Он отмечает: «Вместе с менеджером они должны формировать отдельный бэклог задач, связанных с долгом, и оценивать их на грумингах». Эксперт подчеркивает, что оптимальной стратегией считается постепенное включение таких задач в текущие спринты. По его словам, «добавляя по одной-две задаче, можно снизить долг, не прерывая основной процесс разработки». Однако он замечает, что успех этого подхода зависит от объема долга, доступных ресурсов команды и сроков. Если долг слишком велик или команда перегружена, Артем предлагает рассмотреть проведение отдельных технических спринтов, полностью посвященных рефакторингу и доработкам. Но при этом он предупреждает: «Для этого нужно убедить бизнес в необходимости работы над техническим долгом, а это отдельное и не всегда простое днло». В итоге Артем Смирнов заключает, что каждая компания должна адаптировать стратегию работы с техническим долгом под свои процессы, ресурсы и приоритеты.
«Предотвратить накопление техдолга можно, выстроив заранее аналитику и процессы работы в команде и с заказчиком. Если изначально продумать всю архитектуру кода на проекте, спланировать загрузку команды с учетом тестирования и доработок, составить регламенты, стандарты качества, то можно минимизировать шанс возникновения долга», — комментирует Олег Громов, генеральный директор компании Extyl.
Олег Бунин («СИГМА») предлагает универсальный рецепт: формирование политики внедрения и развития ИТ-инфраструктуры в виде входящих требований к целевому состоянию (состояние to-be). Он считает, что необходимо провести аудит текущих систем и декомпозировать их на компоненты (состояние as-is), а затем сформировать план по каждому компоненту системы. Далее он рекомендует создать дорожную карту или чек-лист с оценкой затрат для приведения состояния as-is к состоянию to-be. Эксперт подчеркивает: «Политика и аудит должны быть посвящены источникам накопления технического долга — устаревшие технологии, откладывание решения проблем, отсутствие документации, неправильное проектирование и неудовлетворительное обслуживание». На выходе, по его словам, получается план с оценкой сроков и затрат. Он добавляет: «Если есть алгоритм, значит, его можно «оцифровать».
Стратегия борьбы с технологическим долгом
Максим Башарин (A1TIS) отмечает, что избежать накопления технологического долга помогает тщательное планирование архитектуры систем и своевременное обновление используемых технологий и инструментов. Он подчеркивает, что такой подход снижает риски зависимости от устаревших решений, которые со временем становятся дорогостоящими в поддержке и модернизации. Спикер также указывает, что на помощь нередко приходят ИТ-партнеры и интеграторы. По его словам, они могут не только оптимизировать архитектуру и настроить процессы тестирования и анализа кода, но и выстроить систему регулярного аудита. Он считает: «Важно связать ИТ-стратегию компании с ее долгосрочными целями». Такой подход позволяет, по его мнению, минимизировать риски, повысить эффективность работы систем и подготовить команды к использованию современных технологий.
«Тяжелое наследие» западных ИТ-компаний
Несмотря на то что технологический долг — это общемировая проблема, у нашей страны есть своя особенность. Для России характерна ситуация, когда компании упорно сидят на зарубежных системах, хотя их разработчики давно ушли из нашей страны. Алексей Захаров (Axiom JDK) согласен с тем, что текущая ситуация с зарубежным программным обеспечением несет существенные риски для бизнеса. Он напоминает, что системы, построенные на импортном ПО, больше не получают обновлений и компании сталкиваются с отсутствием поддержки. Эксперт подчеркивает недопустимость задержки перехода на российские аналоги для критически важных систем. Алексей поясняет, что регуляторы уже определили понятия критической инфраструктуры и использование зарубежного ПО недопустимо в системах, критически важных для компании или населения, особенно если они обрабатывают персональные данные. Алексей Захаров также обращает особое внимание на программное обеспечение с открытым исходным кодом. «Исходный код и продукт на его основе — это не одно и то же», — подчеркивает он. По его мнению, для работы с такими системами, как Linux или JDK требуется серьезная внутренняя экспертиза или поддержка отечественного производителя с опытными инженерами. Специалист приводит статистику: согласно данным «Лаборатории Касперского» за 2022 год, было обнаружено зараженное ПО с открытым кодом в различных репозиториях. Он отмечает, что по информации компании Solar, к концу 2024 года количество атак с использованием Open Source-родуктов увеличилось вдвое всего за год.
В то же время Николай Тихомиров («T1 Иннотех») считает, что описанная ситуация нехарактерна для среднего и крупного бизнеса. По его наблюдениям, большинство компаний уже разработали стратегии импортозамещения и трансформации ИТ-инфраструктуры, действуя либо самостоятельно, либо при поддержке регуляторов. «Конечно, часть рисков уже реализовалась», — отмечает эксперт, указывая на отсутствие третьей линии поддержки от вендоров и проблемы с ЗИПами для многих зарубежных решений. Однако он подчеркивает, что за прошедшие два года компании успешно адаптировались к новым условиям. Наш собеседник размышляет о том, можно ли считать данную ситуацию технологическим долгом. По его мнению, такое определение справедливо, только если компания изначально планировала переход на российское ПО. В противном случае эксперт предлагает рассматривать это как реализовавшийся риск.
«Компании, ушедшие с российского рынка, как правило, закрывают свою поддержку. Получается, что для пользователей зарубежных систем — большой риск остаться на старом стеке, а это и является технологическим долгом. С другой стороны — даже в условиях отсутствия глобального рынка, российские компании-разработчики адаптировались под эти изменения и неплохо справляются с возникшими сложностями», — заключает Сергей Капралов (Sigur).
Как единодушно подтвердили опрошенные нам эксперты, в современных условиях успешное управление технологическим долгом становится не просто технической задачей, а важным фактором конкурентоспособности и устойчивого развития бизнеса. При этом особую актуальность приобретает необходимость баланса между сохранением работоспособности существующих систем и их своевременной модернизацией с учетом новых технологических и геополитических реалий.