Компании стали накапливать техдолг быстрее. В чем тут вина agile

Пока рынок активно обсуждает будущее, в которое нас приведет искусственный интеллект, многие компании продолжают зависеть от IT-систем — ровесников кнопочных телефонов. Эти системы пожирают ресурсы, тормозят внедрение новых продуктов и создают колоссальные риски для бизнеса.

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

Что такое технический долг и почему он опасен

Проведите простую аналогию. Вы берете кредит в банке. Это позволяет вам быстро совершить нужную покупку, а не копить годами. За это вы платите проценты. В мире IT технический долг — это такие же «кредиты», которые берут разработчики, сознательно упрощая решение или используя временные меры для скорейшего достижения результата. Тактические упрощения, или, как их называют на профессиональном жаргоне, «костыли», внедряют для скорости, подчас в ущерб качеству и долгосрочной перспективе.

Проблема не в самом факте «кредита» — без него не обходится ни один крупный проект. Проблема начинается тогда, когда команда перестает платить «проценты», то есть обслуживать этот долг, а «костыли» начинают накапливаться. Одно временное решение накладывается на другое, документация не ведется, а IT-подразделение теряет понимание, как система работает изнутри.

Это и есть технический долг — невыполненные обязательства по поддержанию IT-активов в актуальном состоянии. Его главная опасность — кумулятивный эффект. Какое-то время система работает, но с каждым годом стоимость ее поддержки и модернизации растет в геометрической прогрессии. Рано или поздно наступает момент, когда все ресурсы уходят только на то, чтобы поддерживать ее работоспособность, а о развитии и инновациях речи уже не идет.

Как гонка за результатом губит софт 

При кажущейся простоте проблемы и очевидных выводах технический долг является головной болью для IТ-команд и нередко приводит к коллапсу систем. Причем тенденция такова, что превращение ПО в legacy (устаревшее, унаследованное) ускоряется, и все чаще этот термин применяется к решениям, которые перешагнули рубеж в пять лет. Учитывая размер затрат на их создание, такой срок службы у многих вызывает сомнение в целесообразности инвестиций.

Поэтому давайте разберемся, что же способствует стремительному устареванию IT-систем? Ирония состоит в том, что темп накопления техдолга ускорила популярность agile — гибких подходов к разработке программного обеспечения. В России в IT-сфере agile применяет уже 91% организаций.

Принципы agile, эффект от которых достигается при комплексном использовании, часто применяют избирательно и неправильно:

— бизнес ставит в приоритет быстрый результат, не принимая в расчет способы его достижения; — аналитики минимизируют или откладывают описание требований на потом;

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

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

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

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

Однако очень важно знать, что не все «возрастные» системы относятся к legacy. И решение о замене не нужно принимать, ориентируясь исключительно на сроки использования продукта. Риски увеличиваются, когда одновременно сходятся несколько факторов.

— Устаревшие технологии: ограничивают возможности для развития и интеграции или создают угрозы кибербезопасности.

Пример. Более не поддерживаемые вендором версии баз данных Oracle содержат множество неисправленных уязвимостей, которые могут быть использованы злоумышленниками.

— Дефицит кадров: на рынке почти не осталось специалистов, готовых работать с устаревшими языками и платформами. Их зарплатные ожидания зашкаливают.

Пример. Поддержка legacy-систем на Delphi и Cobol осложняется нехваткой кадров, так как новые специалисты ориентированы на современные языки и инструменты (Java, Python).

— Отсутствие документации: никто в компании не может быстро понять, как устроена система. Уход даже одного ключевого сотрудника парализует работу.

Пример. Уход единственного специалиста, понимавшего архитектуру IT-системы для внутренних финансовых операций со сложной структурой, парализовал развитие крупного банка. Отсутствие документации привело к тому, что даже незначительные изменения стали отнимать месяцы работы, блокируя внедрение новых продуктов.

— Неоправданная стоимость: расходы на поддержку и латание дыр начинают превышать ту бизнес-ценность, которую система создает.

Пример. Крупный банк столкнулся с проблемами из-за унаследованной автоматизированной банковской системы (АБС), созданной в конце XX века. Многочисленные патчи (файлы с изменениями) и улучшения не смогли остановить снижение эффективности АБС и рост затрат на ее поддержку. Содержание устаревшего ПО обходилось банку дороже, чем потенциальная выгода от его дальнейшей эксплуатации.

— Критическая важность: на систему завязаны ключевые бизнес-процессы. Ее отказ способен парализовать работу компании.

Пример. Одна из компаний нефтегазовой отрасли использует для управления диспетчерами мейнфреймы (высокопроизводительные, отказоустойчивые компьютеры) и ПО, созданные в СССР. Для минимизации рисков организация постоянно модернизирует инфраструктуру и разрабатывает планы перехода на современное отечественное оборудование.

Чек-лист: как управлять техническим долгом и избежать коллапса

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

1.       Сформулируйте цели и приоритеты при разработке новых функций ПО. Зачем: чтобы каждое действие по развитию ПО

Зачем: чтобы было осознанным и вело к конкретному бизнес-результату.

Что дает: команда не тратит время на второстепенные задачи и понимает, для чего создается та или иная функция.

Результат: повышение фокуса и эффективности разработки, все действия согласованы со стратегией компании.

2.       Определитесь с целевой архитектурой системы.

Зачем: чтобы создать единое видение развития IT-системы, которое будет служить ориентиром для всех сотрудников.

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

Результат: создается масштабируемая и надежная основа для долгосрочного развития вместо лоскутного одеяла модулей и технологий.

3.       Документируйте все изменения в системе с умом.

Зачем: чтобы сохранить критически важные знания о системе и обеспечить преемственность, даже если ключевые сотрудники уйдут.

Что дает: снижает риски и время на онбординг новых участников команды или при решении сложных инцидентов.

Результат: повышается устойчивость команды и системы к изменениям, упрощается поддержка и дальнейшая разработка.

4.       Внедрите практику регулярных небольших задач по рефакторингу.

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

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

5.       Контролируйте техдолг, заводя на каждый «костыль» задачу с оценкой на доработку.

Зачем: чтобы сделать невидимую проблему видимой и управляемой. Неучтенный долг невозможно оценить и приоритизировать.

Что дает: четкое понимание реального объема «задолженности» позволяет принимать взвешенные решения о том, когда и за какие долги «платить».

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

6.       Не забывайте про обновления ПО от вендоров.

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

Что дает: регулярные обновления и сопутствующий рефакторинг помогают поддерживать систему в актуальном и безопасном состоянии.

Результат: снижаются риски кибербезопасности, обеспечивается совместимость с другими системами. 

Вывод прост: регулярное внимание к вопросу технического долга обходится намного дешевле исправления накопленных проблем и выхода из экстренных ситуаций. Достаточно простые организационные меры позволяют на годы продлить срок эксплуатации систем и обеспечивают высокую эффективность инвестиций в IТ.