23 апреля мы в Sympace® провели мастермайнд-сессию с ИТ-руководителями. Обсуждали не абстрактные тренды, а живые вопросы, которые каждый день прилетают в рабочий календарь ИТ-директора: пользователи требуют быстрее, бизнес хочет дешевле, проекты не ждут, оборудование нужно «еще вчера», импортозамещение не прощает ошибок, а команда уже работает на пределе.
Один из самых точных вопросов прозвучал так: как ИТ-руководителю работать, когда «не хватает рук»?
На первый взгляд ответ очевиден: нанять людей. Но в 2026 году в России это уже не универсальное решение. На рынке действительно много соискателей, но квалифицированных специалистов под конкретные задачи — архитектуру, безопасность, инфраструктуру, данные, сложную эксплуатацию — по-прежнему не хватает. В 2026 году дефицит все чаще становится не массовым, а точечным: бизнесу нужны не просто «айтишники», а люди с конкретными компетенциями, способные быстро включаться в критичные задачи.
Разберем, что именно съедает ресурс ИТ-команды и какую часть этой нагрузки вообще не должны выполнять сильные специалисты?
Нехватка рук почти всегда начинается не с людей, а с хаоса
В ИТ-отделе редко бывает одна большая проблема. Обычно есть много маленьких: пользователи пишут в мессенджеры, звонят напрямую системному администратору, руководители подразделений ставят задачи «по дружбе», бухгалтерия просит срочно восстановить доступ, склад ждет оборудование, директор хочет отчет, подрядчик не отвечает, лицензии заканчиваются, сервер шумит, сеть «подвисает», а где-то в углу лежит проект, который должен был стартовать еще месяц назад...
В какой-то момент ИТ-руководитель понимает: команда не управляет потоком задач, а просто реагирует на него.
Это опасная точка. Потому что дальше начинаются типичные симптомы:
- специалисты постоянно отвлекаются;
- сложные проекты двигаются медленнее;
- важные задачи тонут среди мелких обращений;
- пользователи недовольны сроками;
- руководитель не может доказать бизнесу, почему нужен ресурс;
- команда привыкает жить в режиме пожара;
- лучшие сотрудники выгорают первыми.
Именно поэтому мы в Sympace® считаем: нехватка рук — это не только кадровая проблема. Это проблема управляемости.
Можно нанять еще одного инженера, но, если входящий поток не разобран, через три месяца он тоже будет перегружен. Можно купить новую систему заявок, но, если приоритеты по-прежнему ставятся криком, она станет красивым складом хаоса. Можно отдать часть задач подрядчику, но, если не понять, что держать внутри, а что выносить наружу, компания получит зависимость вместо разгрузки.
Решение начинается не с найма. Решение начинается с наведения порядка.
Первое правило: брать в работу не все, а важное
У ИТ-отдела есть особенность: если он хорошо работает, к нему быстро начинают нести вообще все.
- Нужно настроить принтер? К ИТ.
Нужно подобрать ноутбук? К ИТ.
Нужно продлить лицензию? К ИТ.
Нужно понять, почему медленно работает программа? К ИТ.
Нужно выбрать систему для отдела продаж? Тоже к ИТ.
Нужно срочно «посмотреть один файлик»? Конечно, к ИТ.
Проблема в том, что не все задачи одинаково важны. Но если у отдела нет правил отбора, все задачи начинают выглядеть срочными.
На мастермайнд-сессии мы отдельно обсуждали: ИТ-руководителю важно не пытаться выполнять весь входящий поток. Нужно научиться отсекать или откладывать то, что не влияет на бизнес, не снижает существенные риски и не дает заметной пользы.
Здесь помогает простой фильтр.
Задача должна отвечать хотя бы на один вопрос:
- она снижает риск простоя?
- она защищает данные?
- она влияет на выручку или обслуживание клиентов?
- она обязательна по закону, договору или внутреннему регламенту?
- она помогает выполнить важный проект?
- она убирает повторяющуюся нагрузку с команды?
Если нет — задача может подождать. Иногда ее можно упростить. Иногда передать в первую линию. Иногда вообще не делать.
Это звучит жестко, но зрелая ИТ-функция не может быть службой исполнения любых просьб. ИТ-отдел должен быть управляемым ресурсом бизнеса.
Приоритизация должна быть прозрачной, а не «как руководитель почувствовал»
В малой компании приоритеты часто держатся на личной памяти ИТ-руководителя. Он знает, что у директора важно, у бухгалтерии срочно, у производства критично, у склада «не горит, но надо». Пока задач немного, это работает.
Но когда поток растет, личная память становится слабым местом.
Приоритизация должна быть понятной и защищаемой. Не «мне кажется, это важнее», а «эта задача выше, потому что простой стоит дороже, риск выше, срок ближе, зависимость сильнее».
Практически это можно сделать через несколько критериев:
- влияние на бизнес;
- стоимость простоя;
- количество затронутых пользователей;
- связь с критичными процессами;
- срок исполнения;
- риск для безопасности;
- зависимость от других задач;
- стоимость ошибки;
- наличие внешнего обязательства.
Пример. Есть две задачи: настроить новый монитор руководителю отдела и восстановить нестабильный канал связи между офисом и складом. Первая может быть неприятной и заметной. Вторая может остановить отгрузки. Значит, вторая выше.
Другой пример. Нужно обновить парк рабочих станций и одновременно выбрать систему резервного копирования. Если текущие резервные копии не проверялись полгода, вопрос защиты данных может оказаться важнее обновления техники, даже если техника «виднее» пользователям.
Для ИТ-руководителя прозрачная приоритизация полезна еще и тем, что она переводит разговор с бизнесом из эмоций в факты. Не «мы не успеваем», а «у нас 140 обращений в месяц, 35 из них повторяются, 12 касаются критичных систем, а текущий ресурс закрывает только 80 без переработок».
С такими цифрами уже можно обсуждать штат, подряд, автоматизацию, бюджет и сроки.
Все обращения должны попадать в единую систему
Одна из самых частых причин перегруза — задачи живут в разных местах.
- Часть в почте.
- Часть в мессенджере.
- Часть в голове у администратора.
- Часть в блокноте руководителя.
- Часть «устно попросили на кухне».
- Часть вообще всплывает только тогда, когда пользователь снова рассерженно спрашивает: «Ну что там?»
Такой режим убивает управляемость.
Система заявок — это не бюрократия. Это приборная панель ИТ-отдела.
Она показывает:
- сколько задач приходит;
- какие темы повторяются;
- кто перегружен;
- какие подразделения создают больше всего обращений;
- где нарушаются сроки;
- какие задачи требуют квалифицированных специалистов;
- что можно автоматизировать;
- где нужна база знаний;
- какой объем работы реально выполняет команда.
Важно: система заявок не обязана быть сложной. На первом этапе достаточно, чтобы каждое обращение имело автора, описание, статус, ответственного, срок, результат и историю действий.
Но должен быть один принцип: если задачи нет в системе, ее не существует как управляемой работы.
Пользователям это может не понравиться. Они привыкли писать напрямую «своему» специалисту. Но задача ИТ-руководителя — защитить не только пользователей, но и команду. Когда все идут напрямую к сильному инженеру, компания сама превращает дорогую экспертизу в диспетчерскую.
База знаний экономит больше времени, чем кажется
В любой компании есть обращения, которые повторяются десятки раз.
- Не подключается почта.
- Не печатает принтер.
- Не открывается общий диск.
- Пользователь забыл пароль.
- Нужно настроить доступ.
- Не работает удаленное подключение.
- Закончилась лицензия.
- Нужно установить стандартную программу.
- Нужно объяснить, как подключиться к видеоконференции.
Если каждый раз специалист отвечает вручную, компания платит за одну и ту же задачу снова и снова.
База знаний решает эту проблему.
В нее стоит выносить:
- типовые инструкции;
- порядок оформления доступа;
- частые ошибки;
- готовые ответы;
- правила обращения в ИТ;
- сценарии первичной диагностики;
- чек-листы для новых сотрудников;
- описание стандартного оборудования и программ.
Хорошая база знаний не заменяет ИТ-отдел. Она снимает с него повторяющийся шум.
Есть еще один важный эффект: когда пользователь заполняет заявку по шаблону или читает короткую инструкцию, он сам лучше формулирует проблему. Вместо «у меня все сломалось» появляется: «не подключается к сетевой папке, ошибка такая-то, доступ нужен к такому-то каталогу».
Для инженера это уже не хаос, а нормальная исходная информация.
Не всякую задачу должен делать сильный специалист
Одна из дорогих ошибок — использовать квалифицированных инженеров как универсальных помощников.
Если специалист, который должен заниматься архитектурой сети, сложными отказами, безопасностью или серверной инфраструктурой, половину дня отвечает на типовые обращения, компания теряет деньги дважды.
Во-первых, дорогой специалист делает работу, которую можно регламентировать и передать.
Во-вторых, сложные задачи ждут, потому что эксперт занят мелочами.
Здесь помогает разделение по уровням.
- Первая линия принимает обращения, уточняет детали, решает типовые вопросы, работает по инструкциям, закрывает простые заявки.
- Вторая линия подключается там, где нужна техническая квалификация: серверы, сети, учетные записи, оборудование, сложные настройки.
- Третья линия занимается архитектурой, критичными системами, проектированием, глубокими инцидентами, нестандартными ошибками.
Такой подход не всегда требует большого штата. Первую линию можно частично отдать подрядчику. Часть повторяющихся операций можно формализовать. Часть вопросов закрывать через базу знаний. Часть закупочных и интеграционных задач — передавать надежному ИТ-партнеру.
Подряд полезен, если отдавать не ответственность, а лишний шум
Подряд — не волшебная таблетка. Если отдать наружу все без разбора, можно получить новые риски: зависимость от исполнителя, потерю внутренней экспертизы, медленную коммуникацию, размытые зоны ответственности.
Но если использовать подряд правильно, он отлично разгружает команду.
Что можно отдавать наружу:
- первичную поддержку пользователей;
- типовые обращения;
- повторяющиеся операции;
- часть рутинных настроек;
- подбор и поставку оборудования;
- подбор программного обеспечения;
- сравнение предложений поставщиков;
- первичную подготовку спецификаций;
- точечную внешнюю экспертизу;
- часть внедрения и сопровождения решений.
Что лучше держать внутри:
- архитектуру;
- ключевые решения;
- приоритеты;
- бюджет;
- управление рисками;
- контроль качества;
- знание критичных бизнес-процессов;
- экспертизу по системам, где ошибка приводит к прямым потерям.
Например, если в компании есть производственная система, 1С, складской контур или инфраструктура, от которой зависит отгрузка, внутреннее понимание этой системы критически важно. Но это не значит, что внутренний специалист должен сам искать поставщиков, сверять цены, собирать несколько коммерческих предложений, проверять совместимость оборудования, уточнять сроки поставки и переписываться с десятком менеджеров.
Эту часть можно и нужно выносить.
Именно здесь ниша Sympace® особенно близка ИТ-руководителям: мы в Симпэйс помогаем сделать удобными процессы подбора, закупки, выбора, настройки и поддержки ИТ-инфраструктуры.
Для руководителя это означает простую вещь: не нужно превращать собственную команду в отдел закупок, техническую справочную и службу поиска дефицитного оборудования одновременно.
Найм не отменяется, но его нужно считать
Конечно, иногда людей действительно не хватает. И никакая база знаний не заменит инженера, если объем сложной работы вырос вдвое.
Но перед тем, как открывать вакансию, стоит честно ответить на несколько вопросов.
- Какие задачи новый человек должен закрыть?
- Они постоянные или временные?
- Нужен штатный специалист или достаточно внешнего ресурса?
- Есть ли внутри повторяющиеся операции, которые можно убрать?
- Не выполняют ли дорогие специалисты низкоквалифицированную работу?
- Можно ли закрыть часть потребности обучением текущих сотрудников?
- Можно ли привлечь удаленного специалиста из другого региона?
- Есть ли смысл в релокации?
- Что дешевле на горизонте года: штат, подряд, обучение, автоматизация или смешанная модель?
На мастермайнд-сессии отдельно обсуждали удаленных специалистов из других регионов. Если задача формализована и не требует физического присутствия, такой подход расширяет рынок поиска. Но он требует четких правил, описанных задач, понятных сроков и нормального управления результатом.
Релокация тоже может работать, особенно для дефицитных специалистов. Но здесь нужна экономика: переезд, жилье, адаптация, удержание, риски ухода. Иногда это оправдано. Иногда дешевле вырастить человека внутри или привлечь внешнюю экспертизу точечно.
Главное — не принимать кадровые решения из состояния паники.
Узкие специалисты — не проблема, если они на своем месте
Есть распространенная управленческая ошибка: считать, что хороший ИТ-специалист должен уметь всё.
На практике универсальность полезна только до определенного уровня. В критичных системах компании часто спасают именно узкие эксперты.
Специалист по 1С, инженер по промышленным контроллерам, эксперт по сетевой безопасности, архитектор хранилищ, инженер по сложным бесперебойным системам — это не «люди с одной рукой». Это люди, чья ценность раскрывается в конкретной зоне.
Проблема начинается не тогда, когда специалист узкий. Проблема начинается тогда, когда человек не делает свою работу качественно, не развивается, не передает знания и становится единственной точкой отказа.
Поэтому задача руководителя — не избавиться от узких специалистов, а правильно встроить их в систему.
Нужны:
- резервные инструкции;
- документация;
- передача знаний;
- понятная зона ответственности;
- второй человек на критичные процессы;
- внешний партнер на случай пиковых нагрузок;
- план развития компетенций.
Узкая экспертиза должна быть силой компании, а не скрытым риском.
Переработки — временный инструмент, а не способ управления
Когда рук не хватает, самый быстрый путь — попросить команду «немного потерпеть».
Один раз это нормально.
Два раза — бывает.
Постоянно — уже система, которая ломает людей.
Переработки опасны тем, что сначала выглядят как решение. Команда закрыла аврал, пользователи довольны, бизнес получил результат. Но через несколько месяцев падает качество, растет раздражение, люди начинают болеть, сильные сотрудники смотрят вакансии, а руководитель получает еще меньший ресурс, чем был.
Постоянная загрузка на 100% лишает команду возможности ускориться в критический момент. В нормальной ресурсной модели должен быть запас.
В ИТ это особенно важно. Отказ оборудования, атака, сбой обновления, срочный переезд офиса, проверка, новый проект, замена поставщика — все это может случиться внезапно. Если команда уже работает на пределе, любой новый инцидент превращается в пожар.
Правильная модель — планировать нагрузку ниже максимума. Не потому, что люди должны «сидеть без дела», а потому что ИТ-инфраструктура требует резерва так же, как сервер, канал связи или источник бесперебойного питания.
Мотивация — это не только деньги
Когда команда перегружена, руководитель часто думает только об оплате переработок. Это важно: сверхурочная работа должна быть ограниченной, прозрачной и оплачиваемой.
Но деньги не закрывают все.
Для ИТ-специалистов важны:
- обучение;
- интересные задачи;
- понятный рост;
- уважение к экспертизе;
- нормальная нагрузка;
- отгулы после авралов;
- участие в выборе технологий;
- возможность развивать смежные навыки;
- признание результата;
- адекватные инструменты и оборудование.
Особенно важно обучение. На мастермайнд-сессии прозвучала мысль, с которой мы в Sympace® полностью согласны: если сотрудников обучать, есть риск, что они уйдут. Но если не обучать, есть риск, что они останутся и не станут сильнее.
Для бизнеса второй вариант опаснее.
Развитие сотрудников снижает зависимость от рынка. Компания не каждый раз ищет готового специалиста, а постепенно выращивает внутренний кадровый резерв.
Студенты и стажеры — длинная, но рабочая стратегия
Кадровый дефицит нельзя закрыть только срочными решениями. Нужен длинный контур.
Работа с вузами, практикантами, стажерами, молодыми специалистами — это не способ быстро заткнуть дыру. Это способ через год-два получить людей, которые знают внутренние процессы, культуру, оборудование, пользователей и реальные задачи компании.
Да, риск есть: молодой специалист может вырасти и уйти. Но этот риск снижается, если у него есть наставник, понятная траектория развития, достойная оплата, интересные задачи и уважительное отношение.
Стажер не должен быть «мальчиком на принеси-подай». Ему нужны задачи по уровню, постепенное усложнение, обратная связь и понятные правила.
Так компания выращивает не просто исполнителей, а людей, которые понимают, как работает именно ее ИТ-среда.
Закупки тоже съедают руки ИТ-команды
О нехватке рук часто говорят в контексте поддержки и эксплуатации. Но есть еще одна зона, которая незаметно забирает огромное количество времени: ИТ-закупки.
- Подобрать ноутбуки под разные роли.
- Сравнить серверы.
- Найти совместимые комплектующие.
- Проверить сроки поставки.
- Собрать спецификацию.
- Подобрать российский аналог программного обеспечения.
- Согласовать цену.
- Проверить условия гарантии.
- Разобраться с оплатой, документами, доставкой.
- Учесть будущую поддержку.
- Не ошибиться с совокупной стоимостью владения.
Каждый пункт вроде бы понятный. Но вместе они превращаются в отдельный проект.
И если всем этим занимается ИТ-руководитель или сильный инженер, компания снова использует экспертное время не там, где оно дает максимальную пользу.
Для ИТ-директора это не просто удобство. Это освобождение времени команды.
Дешевое решение не всегда дешевое
Когда рук не хватает, возникает соблазн выбирать самое быстрое и самое дешевое: оборудование подешевле, подрядчика попроще, лицензию «как-нибудь потом», поддержку минимальную.
Но в ИТ цена покупки — только часть расходов.
Есть совокупная стоимость владения: первоначальная цена, настройка, внедрение, простои, поддержка, обучение, совместимость, обслуживание, гарантия, риски безопасности, время команды.
- Дешевое оборудование может чаще выходить из строя.
- Неподходящее программное обеспечение может потребовать дорогостоящей доработки.
- Слабая поддержка может увеличить простой.
- Неверная спецификация может сорвать проект.
- Ошибка в совместимости может забрать недели.
Поэтому при нехватке рук особенно важно выбирать решения, которые не создают дополнительную нагрузку после покупки.
Мы в Sympace® всегда смотрим не только на цену входа, но и на дальнейшую эксплуатацию. Иногда выгоднее выбрать решение дороже на старте, если оно надежнее, проще обслуживается, лучше поддерживается и не будет каждые две недели требовать внимания инженеров.
Для ИТ-руководителя это принципиально: хорошая закупка должна уменьшать нагрузку, а не создавать новую.
Интеграция должна быть проектом, а не набором разрозненных действий
Еще одна ловушка — внедрять решения кусками.
- Купили оборудование.
- Потом отдельно думаем, кто настроит.
- Потом выясняется, что не хватает лицензий.
- Потом нужно согласовать доступы.
- Потом оказывается, что пользователи не обучены.
- Потом поддержка не понимает, кто отвечает за результат.
Так рождаются долгие внедрения, раздраженные пользователи и перегруженный ИТ-отдел.
Системная интеграция нужна как раз для того, чтобы связать решение целиком: проектирование, внедрение, настройку, сопровождение, документацию, ответственность.
Для компаний, где ИТ-команда и так перегружена, это особенно важно. Внутри можно оставить контроль, архитектурную логику и приемку результата, а исполнение части работ передать партнеру.
Это не ослабляет ИТ-руководителя. Наоборот, дает ему возможность управлять, а не тушить каждую техническую мелочь лично.
Плюсы и минусы основных решений
У каждого подхода есть сильные и слабые стороны.
Найм дает контроль и внутреннюю экспертизу, но требует времени, бюджета и адаптации. В условиях дефицита конкретных компетенций вакансия может закрываться долго.
Удаленные специалисты расширяют рынок поиска и могут быть удобны для формализованных задач. Но требуют дисциплины в постановке задач, документации и контроле результата.
Релокация помогает закрыть дефицитную роль, если нужного человека нет в регионе. Но это дорогое решение, и оно работает только при понятной экономике удержания.
Подряд быстро снимает часть нагрузки, особенно рутину, закупки, внедрение и узкую экспертизу. Но подряд нужно правильно встроить: оставить внутри контроль, приоритеты и ответственность за бизнес-результат.
База знаний и самообслуживание пользователей уменьшают повторяющиеся обращения. Минус — ее нужно регулярно обновлять, иначе она быстро устареет.
Система заявок дает прозрачность и доказательную базу для управленческих решений. Минус — пользователей придется приучать к новому порядку.
Обучение сотрудников развивает внутренний ресурс и снижает зависимость от рынка. Минус — результат не мгновенный, а риск ухода обученного человека остается.
Переработки помогают пережить короткий аврал. Минус — как постоянная модель они разрушают команду.
Поэтому сильное решение почти всегда смешанное. Немного найма, немного обучения, немного подряда, нормальная система заявок, база знаний, понятная приоритизация и грамотные закупки.
Мы в Sympace® хорошо понимаем эту боль ИТ-руководителей. Симпэйс работает там, где бизнесу нужно подобрать, закупить, настроить, внедрить и поддержать ИТ-инфраструктуру без лишних нервов. Мы поставляем программное и аппаратное обеспечение, занимаемся системной интеграцией и оказываем ИТ-услуги для бизнеса.
Иногда ИТ-руководителю действительно нужны новые сотрудники. Но иногда достаточно надежного партнера, который возьмет на себя часть закупочной, интеграционной и организационной нагрузки — и вернет команде время на то, ради чего она действительно нужна бизнесу.
Когда ИТ работает спокойно, бизнес растет спокойнее. А значит, задача не просто в том, чтобы найти еще руки. Задача в том, чтобы каждая рука занималась правильной работой. Обращайтесь!