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

Как выходить на игру вдолгую и взаимовыгодные отношения с заказчиком. Бонус: вовлеченные разработчики, которые хорошо знают бизнес.

50% того что мы делаем с 2001 года — это аутстаф IT-специалистов для решения задач бизнеса. Мы работаем напрямую с конечными клиентами, но есть опыт работы и через брокеров.

В этой статье мы делимся нашим видением рынка аутстаффа в России и рассказываем о нашем подходе.

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

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

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

Когда аутстаф ломается, страдают и заказчики, и разработчики

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

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

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

Работа через посредника исключает прямую обратную связь от заказчика. Компания-исполнитель не знает (а может и не узнать до конца проекта), как там работается ее сотруднику(ам), всё ли радует заказчика, и нужно ли что-то улучшить. Невозможно быстро среагировать на прецеденты и принять правильные решения для лучшего результата.

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

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

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

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

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

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

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

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

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

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

Мы доносим бизнес-ценность и в будущем получаем сильных специалистов с экспертизой.

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

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

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

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

Один наш читатель описал минус аутстаф-модели метафорой, сказав: «Ребенок не будет слушать чужую маму так же, как свою, пока его оставили с ней на время,» подразумевая, что работая на условно «чужого» начальника, исполнители будут поставлять менее качественный результат. Однако мы уверены, что вполне реально организовать работу так, чтобы дети не только были послушными и оставили после себя порядок, но ещё помыли посуду и заказали пиццу, чтобы «чужая» мама была максимально довольна! 🙂

0
9 комментариев
Написать комментарий...
Артем Салютин

Спасибо за материал. Посредник без добавленной ценности = зло. Но если интегратор может переварить запрос 30FTE Java разработчиков, то продакшн нет. И это уже добавленная ценность. Поэтому совет хороший но для small и mid-size бизнеса.

Ответить
Развернуть ветку
Вениамин Мустафин

Артем, спасибо за комментарий!

Да, наша идея походит больше малому или среднему бизнесу.
Мы в статье не делаем на этом акцент, а надо было бы, как я теперь вижу :)

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

Мы, видимо, настолько ЧСВ, что не хотим быть одними из 30 Java разработчиков, которые будут работать с корпорацией через интеграторов ))
Поэтому пытаемся прокачивать альтернативный путь ) Может иногда даже в ущерб объемам.

Ответить
Развернуть ветку
Alexander

Аутстафф крайне сложно продать напрямую в крупные проекты, корпоративным или гос.заказчикам. Да и вообще всем кто готов работать только по модели fixprice, оплачивая готовый результат а не часы. Вот здесь-то и нужны интеграторы. Крупный проект может длиться год, и до завершения заазчик в лучшем случае закроет какие-то этапы. Да еще и с отсрочкой платежа дней в 60. Богатый интегратор может себе позволить такие инвестиции, небольшая аутстафф-галера точно нет (она и за результат-то не отвечает). А между тем основные деньги в IT в России крутятся именно в таких проектах.

Ответить
Развернуть ветку
Вениамин Мустафин

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

Ответить
Развернуть ветку
Alexander
А отсрочка платежей уже такой рудимент, от которого уже давно пора отказаться.

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

Ответить
Развернуть ветку
Alexander
Гос. заказчики да, напрямую выйти на них почти нереально. Знаю несколько примеров, когда это удавалось, но это скорее исключение из правил и не знаю, чем все там закончилось.

Там проблема не в том чтобы выйти, проблема в том что аутстафф фактически не совместим ни с 44-ФЗ ни с 223-ФЗ о госзакупках.

Ответить
Развернуть ветку
Георгий Лессар
Разработчики не выгорают, потому что практикуют интересные им задачи, а не выполняют работу «потому что надо.

Это тоже описание идеальной ситуации. Они так редки.

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

1. Сотрудники
2. Клиенты
3. Сами учредители/акционеры

Ответить
Развернуть ветку
Вениамин Мустафин

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

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

Допускаю, что мы просто тогда не научились работать с командой и есть на рынке компании, у которых в этом плане все ок.

Ответить
Развернуть ветку
Вениамин Мустафин

Гос. заказчики да, напрямую выйти на них почти нереально. Знаю несколько примеров, когда это удавалось, но это скорее исключение из правил и не знаю, чем все там закончилось. Но мы в гос и не суемся — не умеем с ними работать, боимся :)

В корпорации заходить можно, но там все зависит от проекта и от человека, который принимает решение. Чем прогрессивнее взгляды, тем легче зайти :) Главное пользу дать.

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

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

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда