Я Антон Калуцкий. В ИТ я с 2010 года: начинал с бизнес-аналитики, потом руководил ИТ-подразделением, создавал проектный офис, занимался стратегическими процессами и цифровой трансформацией. Сейчас я управляю партнёрской сетью Devcom. В статье поделюсь опытом: на что обращать внимание при выводе специалиста на проект и как снизить риск инцидентов.
Рассказываю ситуацию из наших рабочих будней, история про «глухие телефоны». Разработчик потратил на задачу больше часов, чем планировалось. Заказчик попросил объяснить перерасход, партнер передал разработчику, что дополнительные часы оплачивать не хотят, и специалист сообщил конечному заказчику, что выходит из проекта.
На самом деле заказчик не отказывался оплачивать работу. Ему нужна была детализация трудозатрат в определенном формате, чтобы согласовать дополнительные часы. Но между заказчиком, партнером и специалистом оказалось слишком много посредников, поэтому обычный вопрос по отчетности превратился в конфликт.
В итоге разработчик решил уйти, заказчик оказался внутри чужих разногласий, а партнер перестал нормально выходить на связь. Нам пришлось самостоятельно восстанавливать факты, готовить детализацию и возвращать участников к обсуждению задачи. Часы согласовали, разработчик получил оплату, а проект удалось сохранить, но сотрудничество с партнером после этого поставили на паузу.
Казалось бы, нашли клиенту подходящего специалиста, проверили его технические навыки и быстро вывели на проект, но это еще не означает, что все вопросы решены и все под контролем.
Проблемы обычно становятся заметны позже: когда специалисту не хватает задач, оценка расходится с фактическими трудозатратами, меняются требования или между участниками возникает конфликт.
Техническое интервью проверяет не все
При выборе внешнего специалиста обычно оценивают профессиональные навыки. Но техническое интервью почти ничего не говорит о том, как человек будет работать каждый день. Будет ли он заранее сообщать о задержке, задаст ли вопрос, если требования непонятны, предупредит ли о трудностях с выполнением задачи, соблюдет ли договоренности с заказчиком. Полностью проверить это до выхода специалиста невозможно.
Иногда в такие правила приходится включать совсем базовые вещи. Например, у нас были случаи, когда мы отдельно проговаривали требования к участию в рабочих созвонах.
Заказчик привлекает внешнего сотрудника не для того, чтобы отдельно объяснять ему нормы делового общения или разбирать каждую нестандартную ситуацию. Если специалист работает через провайдера, последний должен нести ответственность и подключаться к проблемам.
Какие проблемы возникают после выхода специалиста
Есть мнение, что главная проблема аутстаффинга — найти сильного специалиста. Но на практике найти человека — это только начало. Большинство сложных ситуаций возникает уже после его выхода. Разберу несколько частых сценариев.
Специалисту не хватает задач
Простой разработчика не всегда значит, что проблема в нем, в нехватке нужных компетенций. Часто это говорит о том, что команда не подготовила требования, аналитик перегружен, приоритеты постоянно меняются, доступы еще не выданы или непонятно, кто принимает результат.
Когда мы разрабатывали собственную платформу для партнерской сети, штатный разработчик недополучал задачи, потому что мы сами не успевали быстро формировать для него ТЗ.
В такой ситуации замена специалиста ничего не даст. Сначала нужно найти причину простоя. Если узким местом оказывается аналитика, логичнее временно подключить аналитика и ускорить подготовку требований.
При этом простой стоит оценивать не только по стоимости неиспользованных часов. Из-за неподготовленных задач переносится запуск функции или продукта, команда медленнее идет к результату.
Заказчику нужен был другой специалист
Запрос «нужен еще один разработчик» не всегда означает, что проекту действительно нужен разработчик.
По внутренним данным нашей партнерской сети за январь — май 2026 г. доля запросов на разработчиков снизилась с 63 до 49%. Привожу только относительные цифры, чтобы не разглашать коммерческую информацию, но хочу показать динамику. Одновременно вырос спрос на аналитиков, архитекторов и DevOps-специалистов. По нашим цифрам нельзя судить о ситуации на всем рынке, но тенденция выглядит логичной.
Проекты становятся сложнее. И далеко не всегда их можно ускорить, просто добавив еще одного человека, который пишет код. Бывает, что проекту не хватает требований, архитектурных решений или инфраструктурной экспертизы. В первом случае нужен аналитик, во втором — архитектор, в третьем — DevOps-инженер.
Поэтому провайдеру недостаточно получить заявку и найти человека с подходящим набором навыков. Нужно понять, какую проблему заказчик пытается решить с помощью нового специалиста.
Заказчик и специалист по-разному понимают результат
Для разработчика задача может считаться выполненной после написания кода. Для заказчика результатом может быть протестированное изменение, принятое и развернутое в промышленной среде. Обе стороны при этом могут считать свою позицию правильной.
Поэтому критерии готовности лучше определить до начала работы. Иначе в конце месяца появляется спор: задача закрыта в системе, но функция еще не работает у пользователей. В обсуждение подключаются менеджеры и руководители, хотя изначально достаточно было договориться, что именно считается завершением работы.
Кто-то кого-то не понял
Не каждый конфликт связан с технической ошибкой. Специалист может резко ответить в чате, не предупредить о задержке или несколько дней не сообщать о проблеме.
В такой ситуации заказчику обычно не нужен подробный разбор того, кто виноват. Ему нужно решить рабочий вопрос: восстановить работу, согласовать часы, заменить специалиста или изменить порядок взаимодействия.
Поэтому вокруг внешнего специалиста нужен процесс и команда: аккаунт-менеджер, тимлид, понятный порядок эскалации, единая коммуникация. Иначе при возникновении проблемы заказчик вынужден самостоятельно связывать специалиста, его работодателя и посредников.
Как сделать аутстаффинг управляемым
До поиска кандидата стоит разобраться, зачем вообще нужен внешний человек. Какую проблему он должен решить? Почему текущая команда не может сделать это самостоятельно? Кто будет ставить ему задачи и принимать результат? Есть ли готовый бэклог? Какой результат ожидается в первые недели? Ответы помогают понять, действительно ли нужен аутстаффинг.
Выбирать штатный найм логичнее, если потребность постоянная, направление критично для продукта, внутри есть экспертиза для управления сотрудником и компания готова пройти полноценный цикл найма и онбординга.
Аутстаффинг удобнее, когда экспертизы нет, задача носит проектный характер, результат нужен быстро или пока непонятно, станет ли потребность постоянной. Иногда эти модели можно сочетать: сначала подключить внешнего специалиста, проверить реальную загрузку и потребность, а затем принять решение о найме в штат.
Правила нужно определить до выхода специалиста на проект
До первого рабочего дня нужно определить и зафиксировать:
рабочее время;
обязательные встречи;
формат статусов;
систему учета часов;
порядок согласования перерасхода;
ответственных со стороны заказчика и подрядчика;
сроки реакции;
порядок предоставления доступов;
правила конфиденциальности;
требования информационной безопасности;
порядок согласования отсутствий;
сценарий эскалации.
Предположим, специалист понимает, что на задачу уйдет больше часов, чем запланировали. Рабочий процесс должен быть заранее определен: специалист фиксирует причину, сообщает ответственному, предоставляет новую оценку и получает решение — продолжать работу, изменить объем или остановиться.
То же относится к отсутствию задач. Если специалист утром обнаружил, что не может продолжать работу, это менеджер должен узнать об этом в тот же день, а не через неделю по отчету.
Регламент нужен, чтобы специалисты понимали, как им действовать в непонятной/нестандартной ситуации.
Продолжать сопровождение даже после выхода специалиста на проект
После выхода специалиста стоит проверить, получил ли он доступы и задачи, а через первую неделю — собрать обратную связь с обеих сторон. Дальше имеет смысл регулярно проверять фактическую загрузку, наличие стопорящих факторов, учет времени и соответствие промежуточных результатов ожиданиям.
Особенно важны первые недели. В этот период становится понятно, правильно ли определена роль, хватает ли специалисту контекста, совпали ли ожидания заказчика и исполнителя и не появляется ли риск простоя.
У каждого инцидента должен быть владелец
Если происходит конфликтная ситуация, например, как инцидент из начала статьи, нужно придерживаться правил.
В подобных случаях сначала нужно собрать участников на встрече. Если между заказчиком и специалистом есть несколько посредников, информация может искажаться на каждом этапе. Поэтому при серьезном конфликте лучше провести один общий разговор, чем продолжать играть в «глухие телефоны» и пересказывать свою версию событий.
Следующий шаг — отделить факты от интерпретаций. В нашем случае фактом было то, что задача заняла на 16 часов больше. Фраза «заказчик не хочет платить» была уже интерпретацией.
За инцидентом должен быть закреплен один ответственный. Он собирает информацию, фиксирует договоренности, контролирует сроки, сообщает участникам статус и доводит ситуацию до решения.
Заказчик не должен самостоятельно координировать специалиста, его работодателя и всех посредников между ними.
Одновременно нужно оценить влияние проблемы на проект. Решением может стать детализация часов, изменение объема задачи, дополнительное ревью, корректировка процесса оценки или замена специалиста. После завершения инцидента стоит отдельно разобрать, какого правила не хватало, где потерялась информация и почему проблему не заметили раньше.
Что спросить у провайдера до начала работы
Перед началом сотрудничества стоит выяснить:
Кто сопровождает специалиста после выхода?
Как собирают обратную связь?
Кто отвечает за конфликты, перерасход и эскалацию?
Как организованы отчетность и учет часов?
Что происходит при необходимости срочной замены?
Кто отвечает за передачу знаний?
Если на эти вопросы нет конкретных ответов, это повод насторожиться. Особенно если после выхода специалиста менеджер перестает выходить на связь, правила учета времени не определены, процесс замены никто не может объяснить, а заказчику предлагают самостоятельно разбираться с партнером.
Провайдера стоит оценивать не только по скорости подбора и количеству резюме, а потому что происходит после выхода на проект. Пока все идет по плану, аутстафф-подрядчики могут выглядеть одинаково. Разница становится заметной, когда появляется проблема.
