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

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

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

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

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

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

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

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

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

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

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

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

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

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

• предыдущий опыт и отраслевая экспертиза в IT-сфере чаще всего неприменимы;
• портфолио реализованных проектов не работает, нужна квалификация и компетенции конкретных разработчиков;
• аутстафф ведется в формате «white label», а значит и поддержку основной разработке аутстафф обратно не даст;
• процессы, отлаженные для внутренней продуктовой разработки, не работают в аутстаффе;
• сам специалист становится значимой единицей услуги, его ценность как конкретного исполнителя для клиента возрастает;

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

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

• у специалиста возникает два руководителя, с одним он решает все технические и проектные вопросы, с другим все организационные;

• объяснить особенности white label;
• объяснить, что это в принципе нормальное развитие отрасли, и умение работать в таком формате сейчас такой же полезный навык, как и понимание процессов классической разработки;
• возможны дополнительные требования от службы безопасности, компания и сам специалист должны быть к этому готовы;

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

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

• клиент может долго принимать решение. Возникнет простой;
• выбрав специалиста, клиент может отложить старт, например потому что “тимлид в отпуске” или “нужно готовить доступы”;
• порой клиент отказывается согласовывать документы, пока не выберет специалиста, а выбрав, начинаются разборки с юристами по документам, что формирует простой;
• клиенты любят прятать аутсорс под аутстафф и требуют ответственности за дефекты, сроки и прочие гарантии, не свойственные аутстаффу;

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

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

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

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

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

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

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

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

• предстартовое анкетирование;
• опросные листы, которые позволяют выяснить график отпусков и наличие специалистов на проекте, кто из разработчиков на испытательном сроке;
• постоянные созвоны с командой клиента и со специалистами;
• дополнительные инструменты, которые меняются в зависимости от сложности проекта;

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

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

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

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

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

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

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

• сроки оплаты срываются, если некорректно выстроены клиентские процессы, а пени работают слабо;
• обратная связь запаздывает;
• как бы ни понимали суть услуги, остается желание переложить на исполнителя какую-нибудь ответственность;
• клиент может оказаться ненадежным, и свернуть проект, а иногда и бизнес быстрее оговоренных сроков.

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

• возможна ситуация кассового разрыва;
• низкая маржинальность, особенно в агентской модели, сводит на ноль доходность, как только попадается неблагонадежный клиент, а суды - дело долгое;
• специалист много времени проводит в общении с командой клиента, необходимо компенсировать это вниманием внутри компании, иначе корпоративные связи будут ослабевать;
• риски хантинга остаются, силы, вложенные в рост специалиста, могут сойти на ноль: вырастили, и он ушел — от этого никто не застрахован;
• нужно организовывать внутренние процессы hr, контроля качества, обмена опытом, обратной связи, чтобы специалисты чувствовали заботу и внимание;
• необходимо системно организовать процессы сбора обратной связи от клиента для своевременного выявления трудностей;

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

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

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

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

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

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

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

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

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

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

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

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