Один IT-сотрудник перегружен: когда нужен аутсорсинг

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

Перегруз универсального солдата опасен не только выгоранием. Он опасен качеством решений: на глубокую проработку бэкапов, доступов и мониторинга просто не остаётся внимания. Критичные задачи конкурируют с очередью мелочей. В итоге компания платит дважды — зарплатой за героизм и простоем, когда героизм не успел.

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

Сигналы, что один человек уже не тянет контур

Сценарий вечной очереди. Стратегические задачи живут в бэклоге месяцами, потому что ежедневно побеждает «горит принтер». Техдолг растёт незаметно.

Сценарий отпуска как аварии. Любой отъезд превращается в режим ЧП. Знания не зафиксированы, доступы не делегированы.

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

Грабли усиления команды

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

Как подключать внешний контур без войны ролей

Опытный подход предполагает сначала отделить потоки работ. Мелочи рабочего места — один контур. Критичная инфраструктура и дежурства — другой. Развитие и проекты — третий. Универсальный солдат не обязан быть одновременно всеми тремя линиями.

Зафиксировать SLA и каналы. Куда писать, что считается инцидентом, сколько ждать реакции. Иначе внешняя команда станет ещё одним чатом без приоритетов.

Оставить внутреннему сотруднику роль архитектора/заказчика. Он знает бизнес контекст. Внешний контур даёт руки, дежурства и узкую экспертизу.

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

Документировать-accesses-и-регламент. Аутсорс без документации превращает зависимость от одного человека в зависимость от одной компании — чуть лучше, но всё ещё хрупко.

Модель аутсорсинга IT-команды здесь уместна как способ добавить ёмкость и глубину, а не как кнопка «забрать проблему с глаз долой».

Шаги для решения проблемы

1. Две недели посчитать, на что уходит время единственного IT-сотрудника.
2. Выделить задачи, которые можно стандартизировать и отдать по SLA.
3. Оставить внутри то, что требует знания доменной специфики бизнеса.
4. Описать доступы, инвентарь и критичные системы до подключения внешней команды.
5. Через месяц сравнить: сократилась ли очередь, меньше ли ночных аварий, появилось ли время на проекты.

Что меняется для бизнеса

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

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

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

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

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

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

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