Yandex.Metrika Counter

Обсудить проект

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

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

Есть два пути. Первый – прямой: аутстафим разработчиков из компании А (подрядчик) в компанию Б (заказчик). Второй – извилистый: аутстафим разработчиков из компании А в команду Б, используя посредника В (компания-интегратор). 

Зачем нужен посредник? Во-первых, компании-заказчику (Б) при наличии посредника не нужно нанимать партнерских менеджеров и тратить время на взаимодействие с аутстаф-компаниями, выбирая подходящую. Создал интегратору задачу и ждёшь себе поставку рабочих рук. Во-вторых, компания разработчик (которая А), может не уметь (хотеть, успевать) искать целевых клиентов. Интегратор берёт на себя поиск лидов и общение с бизнесом. Компания А тогда просто продаёт специалистов. 

 

 

Такая модель сотрудничества жизнеспособна, но вопрос в её эффективности.

Когда аутстаф ломается

Требования к разработчикам, которых ищут через посредников, размываются: нужен Инспектор-Гаджет, который будет уметь всё и сразу. Требования при отборе через интеграторов завышаются, потому что заказчику проще исключить риски и взять на позицию человека, который точно покроет задачи. Не важно, что большая их часть будет по силам и менее опытному специалисту – лучше взять с «запасом».

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

Заказчик хочет получить сеньора чтобы не рисковать, но заплатить за него как за миддла. Компания-разработчик не хочет отдавать сеньора за дёшево, поэтому пытается миддлов преподнести как сеньоров. Из-за этого интеграторам приходится отсеивать нерелевантных специалистов, чтобы найти для заказчика то, что он ищет. А это время и деньги.

Компания-разработчик ≠ кадровое агентство

Вот как устроена работа через посредников. Заказчик общается с 2-3 компаниями-интеграторами. Те создают множество запросов в компании с «готовыми» разработчиками, настраивая поиск по грейду и навыкам. При этом задачи и цели, для выполнения которых бизнес решил нанимать исполнителей, если и раскрываются, то на уровне «создаем приложение для банка на микросервисной архитектуре». Этого, конечно, мало для понимания задачи, а без него тяжело подобрать правильного специалиста. 

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

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

Правильный аутстаф = партнерские отношения

В идеальном мире каждый подрядчик печётся о боли бизнеса заказчика как о своей собственной. Уровень вовлеченности должен быть сильно выше, чем просто писать код по указке с утра до вечера. Идеал, наверное, недостижим, но стремиться к нему стоит.

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

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

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

Почему правильный аутстаф работает

  1. Больше пользы клиенту через понимание задач и целей бизнеса, а значит и точечного подбора экспертизы.
  2. Мы не превращаемся в кадровое агентство. Выращиваем и нарабатываем экспертизу внутри компании и делимся ею с нашими клиентами. 
  3. Клиент распоряжается не навыками отдельно взятых разработчиков, а экспертной мощью всей компании.
  4. Работать напрямую с клиентом значит глубже понять бизнес. Так получается через написание кода решать бизнесовые задачи.
  5. Клиент, работая напрямую с аутстафферами, получает разработчиков под свои потребности и не тратит время на нерелевантных кандидатов.
  6. Разработчики не выгорают, потому что практикуют интересные им задачи, а не выполняют работу «потому что надо».