Аутстаффинг VS штатный сотрудник. Разрушаем мифы

Миф 1 — штатный сотрудник дешевле 1.

Это заблуждение. Уверен, что многие делали этот расчет. Но давайте проделаем его еще раз:

- Допустим, что средняя ЗП мидл разработчика 2500 USD на руки.

- Добавляем 40% налогов Добавляем 20% косвенных расходов (HR, менеджмент, бэкофис, плюшки и прочее)

- Добавляем 12% отпуск и больничные

В итоге получаем расходы на разработчика 6800. Стоимость часа работы такого сотрудника обойдется примерно 6800/168 = 40 USD. При этом среднерыночная стоимость мидл разработчика на рынке аутстаффинга порядка 30 USD (+/- 5 USD)

МИФ 2 - Штатный сотрудник дешевле 2.

И снова, это ошибочное мнение. Каждый рекрутер знает что ЗП разработчика зависит скорее от того, сколько хочет получать разработчик, а не от его уровня. Все знают ситуации, когда в одной компании, скажем, мидл разработчик с 3 годами опыта получает на 1000 USD или даже на 2000 больше, чем его коллега-синьор с 5тью.

МИФ 3 - Штатным сотрудником проще управлять 1

Ошибка. В век глобальной удаленки уже нет разницы штатный у вас сотрудник или взят на аутстафф. Все разработчики сидят по домам. Ко всем разработчикам представлен менеджер. Компании нанимают и платят ЗП менеджерам проектов за УПРАВЛЕНИЕ. И именно менеджеры отвечают за эффективность работы. Если ваш менеджер проекта настаивает, что штатным удаленщиком управлять проще, попросите его объяснить почему.

МИФ 4 - Штатным сотрудником проще управлять 2

Wrong-wrong-wrong!!! В предыдущем пункте я уже говорил про менеджера, который стоит над каждым разработчиком. Однако, стоит учесть, что над аутстафф работником стоит не один менеджер, а ДВА. Один со стороны работодателя, и один со стороны заказчика. А это значит и двойной контроль.

МИФ 5 - Проще взять сотрудника в штат 1

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

МИФ 6 - Проще взять сотрудника в штат 2

Нет, не проще. Вам нужно сначала нанять рекрутера (что, кстати, тоже не всегда простая задача и часто требует существенных вложений), потом этот рекрутер найдет ХХХ CV, отбор, скрининг, тех интервью, тестовое задание, интервью с командой, согласование оффера……..как много времени это занимает? А как много разработчиков нынче готовы пройти весь этот путь? Какой процент разработчиков принимает ваш оффер?

Разработчики с аутстаффа уже прошли весь этот путь . Они готовы пройти еще одно-два интервью с вашим тех. специалистом. Они в 95% случаях не будут отказываться от оффера.

МИФ 7 - Мне могут «впарить» плохого разработчика 1

Тут самое время вспомнить слова Бреда Пита из фильма «Большой Куш» (Snatch): – Ты смотрел когда покупал!

У вас есть возможность на интервью опросить разработчика обо всем! И грамотные заказчики так и делают. И при этом все равно разработчик может «в бою» – оказаться слабым. В случае найма разработчика в штат – есть испытательный срок. А в случае аутстаффинга – триальный период. Да-да, многие подрядчики идут на то, чтобы дать вам разработчика на 2-3 недели по сниженной стоимости. А некоторые готовы дать даже бесплатно, хоть и на более короткий срок.

МИФ 8 - Мне могут «впарить» плохого разработчика 2

Что делать если через 3-4 месяца эффективность разработчика снизилась? Или, например, просто проект закончился. Все зависит от того штатный это разработчик или аутстафф. В первом случае вам надо договориться с разработчиком об уходе по собственному желанию. Ведь испытательный срок обычно к этому моменту пройден. А если вы не договоритесь?! Тогда сокращать и выплачивать очень много денег. Во втором случае, вам надо просто написать подрядчику что более не нуждаетесь в его услугах и через 14 дней расстаться с ненужным разработчиком.

Конечно же, есть и ряд существенных преимуществ в работе со штатным разработчиком. Но, если ваша задача состоит в том, чтобы деливерить, чтобы начать деливерить как можно быстрее, то однозначно надо смотреть оба подхода, чтобы закрыть позицию!

(автор Vitaly Alekseenko - @al_vitaliy)

Готов к дискуссии в комментариях или в ЛС @apozdneev