Как «технический долг» становятся причиной кадрового кризиса и что с этим делать?

Привет! С вами Дмитрий Шеверев, основатель Naimee AI, сервиса на основе искусственного интеллекта для автоматизации процесса найма. Naimee берёт на себя такие рутинные задачи по найму сотрудников, как поиск кандидатов, предварительный отбор резюме, проведение первичных интервью и организацию встреч с перспективными соискателями.

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

Как «технический долг» становятся причиной кадрового кризиса и что с этим делать?

Рано или поздно это приводит к тому, что нанять новых разработчиков становится практически невозможно. Парадоксальным образом такие организации существуют годами. Каковы реальные причины и последствия подобной ситуации? Какая судьба ждет бизнес, который не может (или не хочет) меняться? И есть ли выход?

В этой статье мы подробно разберем:

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

Технический долг — это совокупность проблем и недоработок в коде, архитектуре и инфраструктуре, которые копятся, когда компания в угоду скорости выпускает «заплатки» вместо качественного рефакторинга и постоянного улучшения продукта. Как правило, бизнес-руководители редко видят прямую угрозу в изношенной кодовой базе: «Всё работает — зачем менять?»

Однако с годами «долг» растет, качество системы падает, а простой функционал «выстреливает» неожиданными багами. Типичная картина:

Устаревшие языки (Visual C++ 6, Classic ASP, COBOL, ColdFusion и т.д.);
Патчи поверх патчей, отсутствие единой архитектурной логики;
Минимум тестов (особенно интеграционных), а значит, любое новое изменение может «сломать» все, что угодно;
Множество «ручных» операций: разворачивать продукт и выполнять рутинные задачи могут лишь пару «счастливчиков», которые знают систему изнутри.

В глазах руководства это может выглядеть как «маленькие незначительные изъяны». Но для новых разработчиков ситуация оборачивается кошмаром: самостоятельно разобраться в нагромождении кода практически нереально, а «ветераны», способные объяснить, как это всё еще работает, массово увольняются при первой возможности. Как итог — на рынке труда о проекте ходит дурная слава, и опытные специалисты обходят его стороной, даже если предлагают высокую зарплату.

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

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

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

Стоит лишь раз зайти в профильные чаты и форумы, как становится ясно: плохая репутация технологий и менеджмента передается моментально. Один из распространенных примеров — компании, где всю инфраструктуру завязали на малоизвестном (и не слишком удобном) CMS-решении вроде Sitefinity или совершенно архаичных сборках на Visual C++ 6. Разработчики, услышав подобное, зачастую даже не откликаются на вакансии.

Как результат: HR-ы буквально в отчаянии пишут тем, кто «не проходил мимо» — будь то джуниоры или даже люди из смежных IT-областей. В ход идут завышенные зарплатные ожидания и обещания «интересных проектов», но в реальности девелопера ждет кодовая каша, которую нужно латать сутками.

Второй фактор — внутренняя культура. Если в компании разработчики из года в год бьются над одной и той же «з legacy» проблемой, то неминуемо приходит профессиональное выгорание. Систему не дают полностью переписать (или хотя бы рефакторить), а постоянное «залатывание дыр» превращает работу в рутину без перспективы роста.

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

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

Будет ли это «вечная поддержка» ради legacy-технологий?
Есть ли возможность сделать что-то новое, полезное, масштабируемое?
Какова культура менеджмента и общения в компании?

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

Нередко, когда кадровый голод становится критичным (штаты пустеют, дедлайны горят, клиенты начинают жаловаться), руководители принимают экстренные меры:

Самый очевидный и быстрый путь — нанять внешнюю команду. Формально звучит неплохо: «Вот вам деньги, возьмите наш старый код и почините!» На практике:

Подрядчики часто просят значительно большую сумму (до 2–3 раз выше рыночной), учитывая сложность, риски и невнятную документацию.
Есть риск «прогорания» контракта: плохие подрядчики могут лишь временно «заморозить» код, не решив проблему.
Возникает постоянное трение между внешними специалистами и внутренними: первые не хотят вдаваться в корпоративные тонкости, вторые — не всегда имеют полномочия для полноценного взаимодействия.

В итоге такой «ремонт» длится долго и не всегда решает первопричину: необходимость глобального апгрейда.

Некоторые компании делают ставку на узкий круг «героев», готовых за высокую зарплату взяться за самую сложную архитектуру. Иногда это срабатывает — опытный инженер или архитектор действительно может «вытащить» проект на новый уровень. Однако для этого нужны:

Поддержка на уровне менеджмента (выделить ресурсы, не мешать, слушать аргументы);
Время на рефакторинг и переписывание ключевых модулей;
Гарантии, что специалист не уйдет через полгода, столкнувшись с бюрократией.

Без этих условий даже «звездный» инженер в одиночку мало что сделает.

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

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

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

Разработчик рассказывает, что в компании стоит одна CMS, тяжеловесная и непопулярная у девелоперов. Годами руководство не хочет менять технологию, вакансии висят месяцами, никто не откликается. Предложения перейти на другую современную связку отклоняются. В итоге проект висит на одном-двух «несчастных» сотрудниках.
Многие крупные организации (особенно банки) тянут с собой устаревшие технологии. Сложность заключается в том, что найти специалистов по таким стеку тяжело, да и «наследников» нет. Несмотря на то, что эти системы могут работать десятилетиями, любая ошибка обходится в миллионы, а обновление — в целое состояние. Чтобы не выглядеть «устаревшей» конторой, фирмы завлекают IT-специалистов большими зарплатами или зовут консультантов, которые «сидят на золотой жиле» и берут астрономические ставки.
Микросервисное «безумие». Бывают и обратные примеры, когда компания вроде и использует «современный» подход (например, микросервисы), но делает это без архитектурного плана. Каждая сервисная «болванка» имеет собственную базу данных, а интеграционные тесты не работают с прошлого года. После нескольких попыток нанять новых специалистов выясняется, что даже опытные инженеры не хотят тратить время на «хаотичный зоопарк».

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

Рост стоимости разработки. Когда найти людей трудно, компании вынуждены переплачивать за труд, нанимая либо дорогих подрядчиков, либо «звездных» сотрудников под космические зарплаты. Но даже они могут не справиться без радикальных изменений инфраструктуры.
Ухудшение качества. Недостаток людей — меньше времени на тесты, QA, код-ревью. Снижается качество продукта, увеличивается количество багов и регрессии. Проект становится еще менее привлекательным для будущих кандидатов.
Снижение темпов роста. В условиях засилья legacy-инструментов и отсутствия кадров компания не может внедрять новые функции и «поворотные» технологии (AI, блокчейн, микроfrontend и т. п.). Бизнес застревает в прошлом веке, а конкуренты обгоняют.
Критический отказ. В крайних случаях все настолько запущенно, что: «Ветераны», знающие систему, давно уволились; Документация не актуализирована; Некому обслуживать сервера и базы данных; Отсутствует элементарная защита от кибератак. Наконец, система падает, обновлять ее невозможно, а бизнес вынужден «с колен» строить всё с нуля или в срочном порядке продаваться.

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

Самое важное и сложное — принять факт, что ваша IT-система нуждается в капитальном ремонте. Без внутреннего понимания на уровне CEO/CTO любые попытки «подлатать» код будут проваливаться. Важно:

Выделить реалистичные бюджеты на модернизацию.
Определить конкретные цели: «Уйти от старой CMS в течение 12 месяцев», «Переписать модуль оплаты на современном фреймворке за 6 месяцев» и т. д.
Расставить приоритеты: какие части системы критичны для бизнеса, какие можно отключить или «заморозить».

Невозможно «реанимировать» старое решение без ядра людей, которые:

обладают видением правильной архитектуры;
готовы погружаться в legacy-код;
получают поддержку (и полномочия) от руководства.

Это могут быть как штатные инженеры (старый или новый костяк команды), так и привлеченные консультанты. Главное условие успеха: дать им полномочия принимать решения и время на качественные изменения. Приглашенные специалисты, которым «сверху» диктуют, что «не надо переписывать, только подкрутите», редко дают долговременный эффект.

Если кодовая база огромна и критична для работы, делать переписывание «с нуля» за раз — слишком рискованно (и дорого). Реалистичный подход — поэтапно выносить модули на более современные технологии:

Определите «монолиты» или опасные участки кода, которые чаще всего ломаются. Начните с них.
Внедрите регулярное тестирование и CI/CD, насколько это возможно.
Параллельно выпиливайте устаревшие компоненты, переводите их на более гибкий фреймворк или даже на микросервисную архитектуру (только системно).

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

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

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

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

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

Спасибо, что дочитали эту статью до конца! По поводу внедрения самых современных ИИ нейросетей в рекрутинг и HR ботов а так же любые другие вопросы можете писать мне в Телеграм: