Почему в России все еще не умеют заниматься аутстаффингом разработчиков

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

С чем приходится сталкиваться на практике, и как получить рабочие руки, а не проблемы — рассказывает Андрей Лядков, фаундер агентства Staff-Hub.

Аутсорсингом в формате “Аутстафф” мы начали заниматься еще тогда, когда эту услугу так никто не предоставлял, но потребность у рынка в аренде разработчиков и программистов уже была. Приходилось объяснять, что же это такое, что это за формат и как это работает в части «аренды разработчиков», впоследствии те, кто работал в модели T&M, сказали, что это тоже самое и они уже 100 лет занимаются аутстаффингом )

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

Проблема в том, что запрос на аутстафф привлекает и тех, кто всерьез настроен строить этот бизнес, и тех, кто просто хочет присутствовать на рынке или «временно пристроить» своих разработчиков в ожидании нового проекта. Предлагать услуги может как классическая IT-компания, так и агентство, выступающее в роли HR-посредника, которое подбирает на рынке труда специалиста и "перепродает" его. Проще говоря — у каждого свое представление о том, что такое аутстаффинг, и не все, кто заявляют о том, что он предоставляют услугу аутстафф, на самом деле понимают, как это делать. В результате клиенты могут столкнуться с необязательностью , а порой и некомпетентностью поставщиков, ну или прояснять, кто под этим что понимает.

Данная статья — не учебник для новичков, но, опираясь на свой опыт, постараюсь «подсветить» те моменты, которые помогут обойти часть граблей, разложенных на пути любой компании, выходящей на рынок аутстафф-услуг. Мы всегда обращаем внимание наших партнеров на это, ведь само понимание возможных рисков — это почти готовый ответ на вопрос: «Что делать, чтобы не было проблем».

Модель IT Аутстаффинга — это не «отдал специалиста, и дальше это проблемы клиента», а для агентства это не «купил сотрудника подешевле, продал подороже». Мало подобрать специалиста, и предоставить его клиенту. Да, технические функции контроля и планирования разработки делегируются на сторону клиента. Но мотивация, трудовая дисциплина, hr-менеджмент — остаются в зоне ответственности исполнителя.

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

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

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

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

Результат: сотрудник в стрессе, компания несет репутационные потери, а клиент теряет время на онбординг нового разработчика. Чтобы этого избежать, важно заниматься внутренними hr-процессами и менеджментом специалиста, быть с ним в контакте, вовлеченным в его проблематику.

Какие проблемы могут возникнуть при решении компании предоставлять специалистов в аутстафф? Вот некоторые из них:

Подготовка требует серьезного разъяснения для сотрудников, они должны чувствовать, что занимаются важным для компании делом. Если у разработчиков возникнет ощущение, что ими просто дыры затыкают - это демотивирует.

Особенности, которые надо заранее проговорить со специалистами:

В противном случае — сотрудник может не понять или даже испугаться, и просто откажется работать в новом для него формате.

Перед стартом проекта, надо быть готовым к ряду проблем:

У клиента при этом свои фобии, с которыми надо работать, особенно если у него слабый или отсутствующий опыт в аутстафе:

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

Трудностей на онбординге меньше не становится, разработчикам все еще нужна помощь и поддержка:

У клиента тоже ряд проблем, которые требуют проработки:

Очень важно на этапе подключения настроить инструментарий коммуникаций и заранее собрать первичную информацию по специалистам. Для этого мы в Staff-Hub проводим целый комплекс мероприятий:

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

Основной этап, ради которого все изначально и затевалось — реализация проекта. Казалось бы, клиент найден, сотрудники подключены, процессы настроены… что может пойти не так?

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

Услуга слабо защищена, стандартная система работы — по постоплате, а критерии успеха — максимально субъективное мнение команды клиента, тимлидов и специалистов, что все всем довольны, а потому и возникает ряд трудностей.

Например, со специалистами:

С клиентами тоже немало рисков и трудностей:

Как следствие у компании предоставляющей услугу:

В Staff-Hub мы используем VMCRM в своей повседневной работе для систематизации управления кадрами в процессе сопровождения проекта. Роль «сигнализации», предупреждающей о необходимости вмешательства, выполняют еженедельные отчеты от специалиста обратная связь от тимлида клиентов 1-2 раза в месяц — опрос загруженности, удовлетворенности и планов работ.

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

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

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

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

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

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

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

Важно понимать, что системные решения позволяют решать проблемы заранее, а не пытаться купировать их «на лету» по мере возникновения.

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

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