Почему компании с сильными ИТ-командами всё равно привлекают подрядчиков? Исследование с участием представителей 16 организаций показывает, где проходит граница между внутренней экспертизой и внешней инженерной поддержкой.
- 1. Введение
- 2. О чём это исследование
- 3. Инфраструктура стала непрерывным процессом
- 4. Дефицит носит структурный характер
- 5. Режим тушения пожаров
- 6. Почему наём больше не решает проблему
- 7. Где проходит граница между своими и подрядчиками
- 8. Критерии выбора подрядчиков
- 9. Выводы
Введение
Инфраструктура и безопасность перестали быть проектами, которые делают один раз и сдают в эксплуатацию. Теперь это непрерывный поток задач: облачные миграции, выполнение требований по безопасности, аудиты и постоянный рост нагрузки происходят одновременно, без пауз и перерывов. Команды, которые справлялись с прежним темпом, перестают успевать не потому, что стали хуже работать, а потому, что темп изменился. Рост сложности инфраструктуры и новые требования безопасности опережают возможности внутренних команд, формируя устойчивую потребность во внешних инженерных ресурсах.
Это не наблюдение со стороны, а вывод исследования, которое мы провели недавно.
О чём это исследование
В ходе исследования мы пытались понять, как компании на практике закрывают этот разрыв, какой реальный спрос существует и какие сценарии работы с внешними подрядчиками они предпочитают. Мы поговорили с ИТ- и ИБ-руководителями, а также с ведущими специалистами из 16 компаний малого, среднего и крупного бизнеса — от облачных платформ, финтеха и телекома до образования и НКО. Формат — глубинные интервью продолжительностью 30–45 минут, которые дали нам понимание логики, по которой ИТ- и ИБ-руководители принимают решения сегодня.
Именно эти интервью позволили увидеть несколько закономерностей, которые повторялись независимо от отрасли, масштаба бизнеса и размера ИТ-команды.
Рисунок 1. Описание выборки исследования
Инфраструктура стала непрерывным процессом
Вот что мы увидели в первую очередь. Раньше инфраструктурный проект имел начало и конец: спроектировали, внедрили и передали в эксплуатацию. Сегодня для большинства компаний в выборке это не проект, а непрерывный поток задач: поддержка, модернизация, масштабирование, разбор последствий прошлых решений.
При этом независимо от размера компании и отрасли список задач один и тот же, различается только масштаб:
- развитие и модернизация инфраструктуры;
- миграции;
- информационная безопасность и DevSecOps;
- DevOps и автоматизация;
- импортозамещение;
- оптимизация затрат и ИТ-архитектуры.
Для большинства компаний это постоянный поток инженерной работы, часть операционной деятельности ИТ- и ИБ-подразделений и источник регулярных рисков, а не набор проектов с понятным началом и концом.
«Много времени уходит на заведение и поддержание реестра реквизитов удалённых точек: мониторинг их актуальности, перевыпуск и работу с ними, если возникают проблемы с доступностью в каком-то регионе. Плюс организация резервных каналов и настройка VPN на удалённых машинах. Если автоматизировать это не удаётся, всё приходится делать вручную», — CTO, RideTech.
Подобные задачи редко становятся заметными для бизнеса, но именно они ежедневно занимают значительную часть времени инженеров. И чем масштабнее инфраструктура, тем сильнее этот эффект проявляется во время крупных изменений, например миграций.
Миграции — одни из самых сложных типов инфраструктурных проектов. Они часто откладываются годами из-за рисков, масштабности, нехватки ресурсов и невозможности остановить бизнес, но остаются неизбежными: как при росте бизнеса, так и при устаревании технологий и уходе вендоров.
В результате инфраструктурные задачи превращаются в долгосрочную инженерную нагрузку, а не в проект с понятным началом и концом.
Информационная безопасность — один из самых часто упоминаемых блоков задач в интервью. И здесь та же логика, что и с инфраструктурой: ИБ больше не существует как отдельный «контрольный слой». Безопасность перестаёт быть отдельной функцией и становится частью ежедневной инженерной работы — на уровне инфраструктуры, CI/CD и архитектуры приложений.
На практике это выливается в конкретный список задач:
- управление доступом;
- сегментация сети;
- защита облачной и on-prem-инфраструктуры;
- мониторинг инцидентов;
- безопасная разработка;
- аудит безопасности инфраструктуры.
Ни один из этих пунктов не закрывается один раз — каждый требует постоянного сопровождения.
«Количество атак и их сложность растут экспоненциально», — руководитель центра противодействия внешним атакам, финтех.
Рост числа атак — лишь одна сторона проблемы. Не менее важно, что меры защиты тоже нельзя внедрить один раз и считать задачу закрытой. Именно эту мысль повторяли многие участники исследования.
«Безопасность — это постоянный процесс. Нельзя сказать: всё, мы завершили проект и теперь всё безопасно. Сколько я занимаюсь безопасностью, я ещё ни разу не сделал „безопасно“, и такого состояния в принципе невозможно достичь», — специалист по информационной безопасности, цифровая платформа, недвижимость.
Такой подход оказался характерен не для отдельных компаний, а для большинства участников исследования. Безопасность всё чаще воспринимается как часть повседневной инженерной работы, а не как проект с конечным результатом.
Итог: ИБ — это не проект с датой сдачи, а постоянная инженерная нагрузка, которая в современных условиях только растёт.
Дефицит носит структурный характер
Если инфраструктура и ИБ требуют постоянного внимания, логично спросить, откуда компании берут на это ресурсы. Ответ был почти всегда один. Дефицит инженеров носит структурный характер. Почти в каждом интервью звучит один и тот же тезис: «ресурсов не хватает», «команда перегружена», «нужной экспертизы нет в штате».
«Сейчас такая ситуация на рынке, что всем компаниям не хватает кадров. Есть специалисты разного уровня, но если говорить о высококлассных специалистах, которых нам хотелось бы видеть, то их особенно не хватает. Квалифицированные инженеры и разработчики на вес золота», — руководитель направления, ИБ-вендор.
Независимо от отрасли собеседники описывали проблему почти одинаковыми словами. Различались детали, но не сама причина дефицита.
«Основная проблема — нехватка рук и людей, чтобы выполнить те объёмы работы, которые есть», — начальник отдела, телеком.
Причины повторяются во всех сегментах: рост сложности инфраструктуры, рост стоимости инженеров, конкуренция за высококвалифицированных специалистов, текучка и новые требования, которые наваливаются одновременно: облака, безопасность, автоматизация — всё сразу.
Режим тушения пожаров
Фраза «мы постоянно в режиме тушения пожаров» встречается в интервью с компаниями разного масштаба — от малого бизнеса до крупных организаций. Нестабильность становится не временным состоянием, а рабочей реальностью, в которой ИТ-команды живут годами.
Такой режим влияет не только на скорость выполнения задач. Он постепенно вытесняет работу по развитию инфраструктуры, потому что приоритет неизменно получают срочные проблемы.
Причины устойчиво повторяются: нехватка людей и времени, отсутствие формализованных процессов, быстрый рост систем, накопленный технический долг, фрагментированная инфраструктура с размытыми зонами ответственности.
«Типовая проблема любой большой организации — это пользователи: у них бесконечно что-то не работает, поэтому инженерный состав постоянно на ногах», — заместитель начальника управления цифрового развития и партнёрства, образование.
«Одно из основных направлений работы сейчас — автоматизация всего, что только возможно. Задач очень много, поэтому мы стараемся максимально всё автоматизировать — начиная от мониторинга и заканчивая каким-то базовым процессом реагирования», — руководитель центра противодействия внешним атакам, финтех.
В результате большая часть времени уходит не на развитие, а на реакцию: устранение инцидентов, разбор последствий ранее принятых решений и ручную поддержку. Нестабильность перестаёт быть временным состоянием и становится рабочей нормой ИТ-команд.
Почему наём больше не решает проблему
Сложность инфраструктуры растёт, кадров не хватает, команды живут в постоянном аврале. Казалось бы, не хватает людей — ну наймите больше. Но всё не так просто, и данные исследования говорят о другом.
Почти все компании независимо от численности ИТ-подразделений описывали одну и ту же ситуацию: даже успешный наём не успевает компенсировать рост сложности инфраструктуры.
Даже там, где команда сильная и с кадрами всё в порядке, разрыв не исчезает. Компании с развитыми внутренними ИТ-функциями оказываются в той же ситуации, что и небольшие: рост инфраструктуры и сложность задач обгоняют возможности закрыть их своими силами.
Проблема носит структурный характер: нанять «ещё немного людей» не решает её, потому что объём и сложность задач растут быстрее, чем команды могут расширяться, и так будет продолжаться. Поэтому компании ищут способ быстро нарастить инженерную мощность — тогда, когда она нужна, и ровно в том объёме, в котором нужна.
Где проходит граница между своими и подрядчиками
Практически все участники исследования используют смешанную модель: часть задач выполняется внутренними командами, часть — передаётся подрядчикам. Модель «делаем всё сами» или «отдаём всё наружу» в чистом виде почти не встречается.
Гибридная модель возникает как практический компромисс между необходимостью сохранять контроль над ключевыми системами, ограничениями по ресурсам, потребностью в редких или временных компетенциях и скоростью реализации проектов.
Подрядчики перестают быть временной заменой и становятся частью операционной экосистемы компании. При этом степень вовлечённости внешних команд сильно варьируется — от точечных консультаций на отдельных этапах работы до полной ответственности за результат «под ключ».
Рисунок 2. Распределение задач между внутренними командами и подрядчиками
Компании стремятся делать своими силами и удерживать внутри те зоны, которые напрямую влияют на устойчивость бизнеса и непрерывность операций: ежедневную эксплуатацию, ключевые архитектурные решения, продуктовую логику, базовые процессы ИБ.
Подрядчикам же системно передают проектные и нерегулярные задачи — те, что требуют узкой экспертизы, несут высокую цену ошибки или экономически нецелесообразны для содержания в штате. На практике это аудит, сложные миграции, DevOps-, DevSecOps- и масштабные сетевые проекты.
Показательный пример — информационная безопасность: даже там, где команда сильная, конкретных узких навыков может не хватать.
«По отдельным направлениям, например по безопасной разработке или специфическим платформенным сервисам, командам иногда не хватает экспертизы, и тогда привлекают внешних специалистов», — Product Owner, облачная платформа.
Во многих интервью звучит важная мысль: внутренняя экспертиза воспринимается как стратегический актив, а не просто как операционная необходимость. Это объясняет осторожное отношение к полному аутсорсу ключевых функций.
Доверие к внешним командам не бесплатное — вот что рынку предстоит преодолеть, прежде чем подрядчик получит доступ даже к тем задачам, которые готовы отдать.
Главные препятствия для делегирования связаны не столько с бюджетом, сколько с доверием и управляемостью. Респонденты называли несколько повторяющихся категорий, основные: сомнения в качестве работы и вовлечённости подрядчиков, высокая стоимость сложных проектов и отсутствие доверия без рекомендаций.
Ниже — несколько показательных высказываний.
«Мы привлекли компанию, чтобы выстроить процессы ИБ, привести в порядок документацию и определить зоны ответственности. В итоге всё это длится уже почти год, а результатов до сих пор нет. При этом люди пришли проводить аудит облачной инфраструктуры и строить процессы, но что такое облако, они не понимают совсем. Для меня это было большим разочарованием», — ведущий DevOps-инженер, B2B-платформа, промышленность.
«Зачастую дольше объяснять задачу подрядчику и тратить время на взаимодействие, чем подождать и сделать самому позже, но как надо», — CTO, RideTech.
«На самом деле у нас, как у безопасников, привлекать внешних подрядчиков не особо принято, потому что решение любой задачи требует достаточно глубокого вовлечения в процессы безопасности, а привлекать кого-то снаружи в процессы безопасности, ну, откровенно говоря, не особо секьюрно», — руководитель центра противодействия внешним атакам, финтех.
«Наш опыт показывает, что в аутстаффинге примерно 80 % специалистов не заинтересованы в результате своей работы», — руководитель DevOps-направления, заказная разработка.
Практически во всех этих примерах повторяется одна и та же мысль: компании готовы делегировать работу только тогда, когда уверены, что подрядчик действительно снимет нагрузку, а не создаст новую.
Делегирование часто происходит точечно и осторожно, через проверенных партнёров и в рамках задач с ограниченным риском. А один из главных барьеров — это риск получить формальный результат, за которым придётся ходить и перепроверять самому.
Критерии выбора подрядчиков
Из этого страха вырос вполне конкретный набор критериев. Во всех интервью прослеживается единый набор базовых критериев, по которым компании оценивают ИТ-подрядчиков. Формулировки различаются, но логика совпадает: подрядчик должен не просто «выполнить работу», а взять на себя ответственность за итоговый результат.
Рисунок 3. Один подрядчик отвечает за все этапы: от архитектуры до рабочего решения
Список критериев выбора подрядчика вряд ли кого-то удивит: экспертиза, качество, надёжность, цена, вовлечённость, рекомендации. Такой список назовёт кто угодно, кто хоть раз выбирал подрядчика в любой сфере, не только в ИТ и ИБ.
Интересно то, что стоит за этим списком: один и тот же неформальный тест, который почти каждый респондент, по сути, описывает своими словами. Практически все критерии можно свести к одному вопросу: уменьшит ли подрядчик нагрузку на внутреннюю команду или, наоборот, потребует постоянного контроля.
«Первый показатель — это моя маржинальность: насколько хорошо подрядчик закрывает свою функцию и сколько моего времени приходится в это инвестировать», — CTO, RideTech.
Тот же респондент формулирует эту же мысль ещё раз, но немного иначе: если подрядчика всё равно приходится перепроверять — «проще самому один раз разобраться». Вопрос, который стоит за всеми критериями, — сколько моего времени этот подрядчик у меня отнимет вместо того, чтобы его сэкономить.
Экспертиза — это, по сути, прогноз: если специалист не разбирается в предметной области, время на объяснения и переделки съест всю экономию от найма подрядчика. Вовлечённость — то же самое, с другой стороны: типовое решение «под копирку» почти гарантированно потребует доработки самим заказчиком.
«Конечно, я бы хотела, чтобы компания или специалист действительно имели опыт и разбирались в своей предметной области. Чтобы, если ко мне приходит человек проводить аудит облачной инфраструктуры, мне не пришлось бы рассказывать ему, что такое облако, — он должен знать это лучше меня.
Для меня важна вовлечённость: чтобы задачу делали не ради галочки и не просто копипастили документы с предыдущего проекта, а действительно погружались в задачу. Чтобы понимали нашу специфику, чем мы отличаемся от других компаний, какие могут быть нюансы, и подбирали решение именно под наш проект. Не просто предоставили типовое решение, как для десятков B2B-платформ, — я хочу решение под свою конкретную задачу», — ведущий DevOps-инженер, B2B-платформа, промышленность.
Именно поэтому заказчики всё чаще оценивают не только опыт компании, но и её способность разобраться в конкретной ситуации, а не предлагать универсальные решения.
Если собрать всё вместе, картина, которую даёт исследование, оказывается на удивление цельной.
Выводы
Рост сложности инфраструктуры опережает возможности внутренних команд — это не гипотеза, с которой мы начали статью, а вывод, к которому привели результаты исследования.
Рост сложности инфраструктуры, импортозамещение, усиление требований к безопасности, дефицит инженерных кадров и нерегулярность сложных задач формируют структурный разрыв между объёмом ИТ-задач и возможностями внутренних команд. Этот разрыв не является временным и не связан с отдельными кризисами — он закономерно возникает по мере развития современных ИТ-систем. Компании оказываются в ситуации, когда:
- задачи усложняются быстрее, чем команды успевают расти;
- критические изменения происходят волнами (миграции, регуляторные требования, инциденты);
- расширять штат под редкие, но тяжёлые проекты экономически невыгодно;
- цена ошибки слишком высока, чтобы экспериментировать внутри.
В результате спрос смещается от консалтинга как источника знаний и самостоятельного продукта к внешним инженерным командам, способным закрыть этот разрыв.
Компаниям нужны не рекомендации и консалтинг, а подрядчики, которые могут довести решения до рабочего состояния. Почти все задачи, которые озвучивали респонденты, имеют прикладной инженерный характер. Речь идёт не о формировании абстрактных рекомендаций, а о конкретных инженерных действиях: проектировании архитектуры и информационных систем, внедрении и настройке инфраструктуры, миграции сервисов, платформ и legacy-сред, выстраивании DevOps- и DevSecOps-процессов, доведении решений до стабильной эксплуатации.
Во всех сегментах запрос формулируется одинаково: «сделать так, чтобы работало». «Чистый консалтинг» — в виде отчётов, рекомендаций и стратегических документов — не закрывает эту потребность. Он может быть полезен как один из этапов проекта, но не как самостоятельный продукт. Фактически рынок требует совмещения двух ролей в одном подрядчике: головы — чтобы разобраться в проблеме, спроектировать решение, учесть ограничения бизнеса и среды, и рук — чтобы это решение внедрить, отладить и довести до рабочего состояния.
Системный интегратор в этой картине перестаёт быть компанией, которая просто «внедряет железо» или продаёт лицензии. Он становится, по сути, дополнительной инженерной командой — той самой, которую компании физически не могут набрать сами, но регулярно нуждаются в её возможностях. Это прямое следствие того, о чём мы с вами говорили в начале статьи: если разрыв между сложностью и возможностями команд не закрывается наймом, значит, рынок покупает ресурсы подрядчика.
На этом рынке выигрывает не тот, у кого громче бренд, а тот, кто умеет закрыть конкретную инженерную задачу и не оставляет после себя работу, которую потом приходится переделывать.
