Как мы не внедрили аутстаффинг. Поиск модели для небольшой команды

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

В этой статье мы описали опыт нетипичного аутстаффинга от команды разработки — «Студии 15».

Обычно мы работаем по модели аутсорсинга — формируем команду из своего штата под отдельный проект. Иногда интегрируемся в техническую команду клиента, в общем, предлагаем гибкие решения под запрос.

Параллельно мы получаем много заявок на аутстаффинг, но не отдаем в другие компании своих разработчиков: у модели даже в теории есть очевидные минусы.

Однако к 2020 году поток заявок на аутстаффинг стало сложно игнорировать, и мы решили провести эксперимент: можно ли в короткие сроки оптимизировать модель так, чтобы действительно выигрывали все?

Далее — рассматриваем модель со всех сторон и делимся итогами эксперимента.

Содержание

1. Аутстаффинг — «аренда» сотрудников у компании подрядчика.
2. Компании разработки всегда в поиске — или разработчиков, или проектов.
   
3. Аутстаффинг перекрывает боли и заказчика, и подрядчика.
   
4. Аутстаффинг для разработчика: развитие или выгорание?
   
5. Оптимизация модели для трех сторон.
   
6. Подводные камни «человечного» аутстаффинга.
   

В аутстаффинге участвуют три стороны:

1. Компания заказчика. Ищут разработчика на конкретный проект или задачу.

2. Компания-подрядчик. Обеспечивают кадрами компанию-заказчика.
3. Специалист. Сотрудник или кандидат, переходящий в компанию заказчика на временную работу.
   

Аутстаффинг становится популярной моделью для быстрого поиска разработчиков: последние два года нам каждую неделю поступало по несколько заявок. Такой поток запросов мог бы снять часть проблемы «постоянного поиска».

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

С другой стороны — поток заявок на разработку не прогнозируется: заказы на серьезные проекты приходят от крупных компаний. В них обычно несколько лиц, принимающих решение. Зачастую внутренняя бюрократия компании заказчика замедляет процесс заключения сделки, а иногда и срывает ее в последний момент.

Получается, что команды разработки либо перегружены работой на проектах и пытаются найти под них программистов, либо ищут новые проекты для штата.

Такие ситуации случаются 1-2 раза в год.

Отказы объясняются спецификой ведения дел в крупных компаниях:

• Бюрократия. Например, причиной отказа может быть увольнение менеджера/тимлида, который вел сделку.
• Решение «справиться своими силами», чтобы сэкономить бюджет.
  

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

Команда разработки, открывая направление аутстаффинга, получает дополнительный заработок и постоянный поток заказов для своих сотрудников.

По идее, в этой цепочке разработчик может получить ценный опыт работы в разных компаниях при постоянном трудоустройстве.

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

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

Поэтому мы не стали тестировать аутстаффинг на своих сотрудниках: решили собрать направление с нуля, учитывая минусы для разработчиков.

Тестируя модель, мы ставили перед собой три глобальных задачи:

1. Построить аутстаффинг «с человеческим лицом»

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

2. Удовлетворить спрос со стороны заказчиков

К 2021 году поток запросов на аутстаффинг достиг таких масштабов, что его трудно было игнорировать. Учитывая, что мы только запускали направление, подготовленных к аутстаффингу разработчиков у нас было недостаточно. Поэтому мы договаривались с компаниями заказчика о поиске специалистов под их задачи и требования. Большинство компаний соглашались на такой формат.

3. Проверить за короткое время работоспособность модели без многомиллионных инвестиций

Чтобы реализовать две первые задачи одновременно, подход требует больших вложений на содержание и обучение сотрудника до момента его передачи в найм. Мы решили проверить, насколько можно сократить время между нашим внутренним собеседованием и наймом в компанию заказчика.

В теории собранная нами модель выглядела просто:

1. Получаем заявку от компании заказчика.
2. Находим подходящего кандидата.
   
3. Отправляем резюме кандидата заказчику в ответ на заявку на аутстаффинг.
   
4. Назначаем собеседование с тимлидом компании, проходим его.
   
5. Интегрируем сотрудника в команду клиента: настраиваем доступы, получаем задачи.
   

На практике же встречается ряд сложностей. Далее — разбираем опыт компании.

1. Дефицит программистов уровня senior и middle

Мы проводили до нескольких собеседований в день, так как понимали, насколько сложно найти программиста подходящего уровня. Есть разработчики junior, которые выдают себя за middle, а на деле не справляются с простыми задачами. Есть middle, которые не умеют себя «продавать» на собеседовании, и распознать их уровень без включения на пилотный проект практически невозможно.

К тому же у каждой компании свое понимание уровней подготовки программистов, и если кандидат проходит наше собеседование как middle, в компании с другими требованиями его могут определить как junior или senior.

Поэтому кандидат на аутстаффинг должен быть едва ли не идеальным:

• Иметь внушительный коммерческий опыт и разноплановые проекты в портфолио.
• Грамотно говорить.
  
• Уметь продавать себя на собеседовании.
  
• Знать и применять теорию в технологиях.
  

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

2. Кандидату под аутстаффинг нужна «упаковка»

За два месяца тестирования модели аутстаффинга у нас был всего один кандидат, CV которого мы сразу, без доработок, разослали по клиентам.

Других кандидатов необходимо было «упаковывать» под аутстаффинг. Нужно выяснять и подробно описывать их опыт, подтягивать слабые места в теории, готовить к собеседованиям.

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

3. Бюрократия в компании заказчика крадет время — кандидат принимает другой оффер

Мы отправили CV одного из кандидатов в семь компаний, и в каждой принятие решения о собеседовании затянулось на срок от двух недель. Несколько потенциальных заказчиков больше не вышли на связь.

Через две недели ожидания кандидат принял оффер другой компании — за день до запланированного собеседования. Первый опыт аутстаффинга показал, что заказчик долго принимает решение о найме сотрудника. Менеджер передает CV руководителю, далее его согласовывают с конечным заказчиком, после утверждения выбирают время для собеседования, и… мы ищем нового разработчика.

4. Специалист нуждается в адаптации, менеджменте и фидбэке

Со следующей сложностью мы столкнулись, когда интегрировали своего сотрудника в крупный банк. Мы как компания-арендодатель не несем ответственность за менеджмент и трекинг сотрудника, но в компании заказчика не было времени на полноценную адаптацию нового программиста. Поставленные задачи не всегда были точными, вопросы нашего специалиста оставались без ответа, выполненная работа не контролировалась, обратной связи не было.

Через два месяца наш разработчик пришел к полному непониманию процессов и выгоранию. Заказчик не согласился на курирование внутренних процессов нашим тимлидом, поэтому мы вывели специалиста и прекратили сотрудничество по этому проекту.

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

Одна из причин дефицита разработчиков — выгорание. То есть уверенный специалист при текущих условиях рынка «сгорает» быстро, а программисты уровня junior растут медленно. Быстро им негде расти: командам нужны сразу опытные программисты, и начинающие специалисты долго получают опыт на реальных проектах.

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

Чтобы аутстаффинг не перекрывал, а решал эту проблему, разработчики должны расти вместе с компаниями внутри модели.

Модель аутстаффинга «с человеческим лицом» может существовать в форматах:

1. Через инвестиции в содержание и развитие кандидатов на аутстаффинг

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

2. При условии развития направления с двух сторон

Многие минусы модели, описанные в статье, сводятся к одному выводу: мы не можем влиять на процессы внутри компании заказчика, если передаем сотрудника в их команду. Единственный вариант выстроить модель органично — прилагать усилия с двух сторон.

Со стороны команды подрядчика:

• Команда подрядчика подготавливает сотрудников для аутстаффинга: подтягивает технические навыки и учит «продавать» себя на собеседованиях.

• Разработчики проходят собеседования при любой возможности, даже если нет планов интегрироваться в проект — для тренировки soft skills.
  

• Команда выстраивает тимбилдинг и прозрачный рост по финансам, чтобы сотрудники хотели оставаться в компании.

Со стороны компании заказчика:

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

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

И мы продолжим работать по такой модели с командами, которые разделяют наши ценности, либо через классический аутсорсинг.