Мы всегда стараемся внимательно изучить потенциальный проект, особенно если он требует единовременного выделения не менее 5 человек. После того, как интервью пройдены и клиент утвердил специалистов, мы предлагаем провести discovery call между командами. Тимлиды, проект-менеджеры и другие активные участники проекта со стороны клиента отвечают на вопросы наших специалистов, обсуждают роли на проекте и организационные моменты. После звонка мы обсуждаем проект в команде, собираем обратную связь от специалистов. Если все участники удовлетворены своими перспективами участия в проекте, то мы готовы стартовать. Клиенту этот звонок тоже помогает убедиться в правильности выбора и синхронизироваться по ключевым вопросам. Это особенно важно, если впереди у нас длительный проект.

Вот пример из нашей практики. Далее со слов разработчика: «Первоначальное собеседование проводил телеграм-бот. Стартовал таймер, бот дал задачку академического уровня (а ты знаешь, как я не люблю академические задачи), в ответ нужно отправить ему код решения. Потом он в пяти разных формулировках уточнил, как работает код и что можно в нем улучшить. В результате определил мой уровень soft skills как низкий (как?!) и предложил пройти собеседование еще раз, но с живым человеком».

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

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

Екатерина Снегирёва, E-commerce Content Product Owner в AliExpressОптимальный вариант — это два встречи. Первая — установочная, когда мы рассказываем о продукте, его ценности, обсуждаем будущие задачи, делимся документацией, отвечаем на вопросы. Чтобы человеку был понятен, а главное интересен проект, которым ему предстоит заниматься.Вторая встреча — организационная, когда техническая команда помогает получить нужные доступы, понять, где что лежит, куда и по каким правилам коммититься, как выглядит архитектура продукта, рассказывают какие-то особенности и так далее. Если ребята живут в общей парадигме процессов команды, то онбординг получается легким и быстрым. Вначале они работают чуть медленнее, но в процессе ускоряются и вливаются в единый поток. Конечно, внутренняя команда может на старте негативно оценивать внешних «новичков» — это нормальный процесс, который обычно органично решается на уровне техлида и в каких-то ситуативных коммуникациях.

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

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

Екатерина Снегирёва, E-commerce Content Product Owner в AliExpressПервое, на что я обращаю внимание, — человек не закрывается от общения, выходит на связь и доступен, чтобы команда могла как минимум выйти с ним на связь и в целом найти общий язык в последствии. Эффективность работы оценивается внутренней командой по объему работы и качеству кода. Техлид дает оценку, насколько результат работы внешних специалистов соответствуют нашему запросу, гайдлайнам, выполняется ли запланированный объем работы. Первые четыре двухнедельных спринта обычно дают понимание, как ребята вошли в процесс — и по их итогам мы принимаем решение, как работаем дальше.

Александр Морозов, руководитель центра компетенций РосбанкаВажно разговаривать с человеком, а не скатываться в бюрократию. Иначе у сотрудника может сложится впечатление, что он попал во враждебную среду. На моем прошлом месте работы мы даже внедряли программу наставничества: чтобы полчаса в день утром и полчаса вечером уделять своему подопечному в виде обязательной беседы. Все это применимо и к аутстафферам, потому что они такие же члены команды. Реальность такова, что сегодняшний аутстаффер через год-два может стать твоим штатным сотрудником (даже если ты этого совершенно не предполагаешь), и надо сразу относиться к нему как к своему человеку. Также важно понимать, что покинувший компанию аутстаффер с негативным осадком рассказывает об этом везде, формируя репутацию компании заказчика. Как ты потом будешь доказывать, что это именно потому, что это был аутстаффер? Да и, скорее всего, только хуже будет. На моем опыте работы с 70-80 аутстафферами не могу припомнить, чтобы кто-то из них не был мотивирован — все относились к работе как к своей. На мой взгляд, аутстаффер плохо работает, если он плохой работник, а не из-за того, что он аутстаффер.  

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

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

Денис Самбудагва, Product Manager в Delivery ClubЕсли вы инхаус разрабатываете бэкенд, а фронтендом занимается внешняя команда, то надо понимать, сможете ли вы работать синхронно. Мы сталкивались с ситуацией, когда подрядчик почти закончил приложение, а наш бэкенд сделал API только на 50%. Чтобы не расходиться в сроках и ожиданиях, важно заранее договариваться и предупреждать, если разработка задерживается. 

Александр Морозов, руководитель центра компетенций РосбанкаВ частных компаниях к этому относятся проще, чем в банках. У нас же этими вопросам занимается служба безопасности. Как и везде, они устанавливают Citrix, который обеспечивает безопасный доступ к внутренним приложениям..