Дефицит кадров в индустрии не дает компаниям развиваться только за счет внутреннего найма. Компании, которые хотят быстро расти, опережать конкурентов с релизами и выигрывать битвы за потребителя, используют все доступные инструменты, чтобы вовремя масштабироваться. Поэтому спрос на аутстаффинг постоянно растет.
Чтобы IT-аутстаффинг приносил максимальный эффект обеим сторонам, мы подготовили исчерпывающий мануал, в котором разобрали существующие страхи клиентов и способы их избежать. Материал — must read для ресурс-менеджеров, рекрутеров, тимлидов, продактов и для всех, кто участвует в работе с внешними исполнителями на своих проектах.
Всем пользы!
На старт, собираем команду, марш!
Страх: а что если я соберу на проект команду неподходящих специалистов? Нужно больше кандидатов, чтобы было из кого выбрать!
«Нужна разработка фронтенда на React» — возможно, неплохое начало знакомства, если все вводные от клиента на этом не заканчиваются. Чтобы получить наиболее качественный результат, лучше разъяснить детали прямо в начале поиска аутстафф-команды на свой проект.
Помогите команде подрядчика понять ваши требования, чтобы подобрать кандидатов. CV, тестовое задание и техническое интервью — не вся информация, которая нужна разработчикам. Отправляйте специалистам подробное описание проекта, дедлайны и детали технологического стека. Они легче и быстрее пройдут онбординг если будут заранее понимать с каким проектом им предстоит работать, смогут освежить знания в нужных темах и поизучать документацию.
Если вы этого не сделали, а ваш подрядчик не постарался качественно снять требования, велика вероятность, что вас завалят десятками нерелевантных СV. А если все же удастся выбрать разработчика, можно получить отказ — так как спрос на хороших специалистов большой, и выбираете не только вы, но и вас.
Как не допустить?
Перед просмотром CV и проведением интервью , можно подготовить чек-лист передачи информации о проекте. Можете использовать наш шаблон .
Мы рекомендуем использовать следующие пункты:
- Обязательные требования к специалисту и те, что «будет плюсом». Легче всего — взять его из описания своих вакансий.
- Состав команды — кто уже работает на проекте. Это нужно, чтобы подрядчику легче было понять, каких специалистов предлагать: если аутстафферу предстоит влиться в команду из 5-10 и более человек, соло-игроков предлагать не стоит.
- Сроки проекта, чтобы не возникало неловких пауз. Подрядчику лучше заранее иметь возможность составить производственный календарь и свериться с графиком отпусков.
- Описание: отрасль, суть проекта, как устроены процессы. Чем больше подробностей, тем выше шансы получить разработчиков с релевантным опытом.
- Список задач, которые предстоит решать. На чем нужно будет сконцентрироваться, какой тип задач преобладает на проекте? Разработка с нуля или работа с legacy-кодом? Проектирование архитектуры, code review, багфикс, рефакторинг, реализация новых функций?
Мы всегда стараемся внимательно изучить потенциальный проект, особенно если он требует единовременного выделения не менее 5 человек.
Если все специалисты успешно прошли интервью и утверждены клиентом , мы проводим discovery call между командами. Клиентская сторона представленная тимлидами, проект-менеджерами и другими активными участниками проекта старается подробно отвечать на вопросы наших специалистов. Мы обсуждаем роли на проекте и организационные моменты. Клиенту этот звонок так же полезен, чтобы синхронизироваться с командой и убедится, что выбор сделан верно. Затем, уже внутри своей команды мы обсуждаем проект и собираем обратную связь от разработчиков. Если перспектива участия в проекте всех устраивает, мы стартуем.
Страх: а что если я недостаточно тщательно подхожу к отбору? Давайте проведем еще два этапа собеседования. И лайвкодинг!
Часто бывает, что к аутстафф-кандидатам заказчики относятся очень ответственно — возможно, даже серьезнее, чем к подбору сотрудников в штат. Классическая ситуация: два часовых интервью, тесты на теоретические знания , и сеанс лайвкодинга, когда разработчик в реальном времени решает задачи под наблюдением 3-5 человек во главе с вице-президентом компании (ладно, здесь мы погорячились, но это не точно).
Вот пример из нашей практики. Далее со слов разработчика: « На первом собеседовании меня ждал телеграм-бот. Он дал мне академическую задачу и запустил таймер (а ты знаешь, как я не люблю академические задачи), в ответ нужно было отправить ему код решения. З атем бот в пяти разных формулировках спрашивал меня , как работает код и что можно в нем улучшить. Мой уровень soft skills по результатам такого тестирования он определил как низкий (как?!) и предложил пройти собеседование еще раз, но с живым человеком».
В казарму новобранцев заходит лейтенант:
— Кто тут разбирается в электричестве?
— Я! — вскакивает один новобранец.
— Что закончил?
— МЭИ с красным дипломом.
— Сойдет. Будешь следить, чтобы свет выключали в 22:00.
Статистика показывает, что жесткость и неприступность отбора очень редко зависит от сложности и престижности проекта . Неоправданно завышая требования, заказчик лишает себя подходящих кандидатов, из 20 хороших CV едва ли пропускает один.
Как не допустить?
Интервью должно соответствовать задачам проекта. Если на следующий этап отбора прошло критически мало разработчиков, возможно, дело не в них ? Уточните входные требования, чтобы получать более релевантные CV, или слегка ослабьте гайки при отборе — так вы повысите конверсию и сэкономите ресурсы на подбор кандидатов достаточной для проекта квалификации (если задача все-таки нанять, а не создавать видимость работы).
Не бойтесь прислушаться к мнению подрядчика, если вы делаете с ним уже не первый совместный проект и прошли вместе огонь и воду. Бывает, что волнение не позволяет разработчику в полной мере раскрыться на собеседовании. Все таки подрядчик лучше знает качества и способности своих сотрудников, чем вы после пары часовых интервью. Поэтому если кандидат формально не прошел ваш отбор, но подрядчик настойчиво просит дать ему шанс, не отказывайте в этом.
Взгляд со стороны клиента
Лайфхак в этой области: аккаунт, который работает от подрядчика, физически находится в офисе клиента, ходит на планирования спринтов, на груминги, ретроспективы и т.д. Этот человек понимает, чем живет продукт, какая у него культура, какие люди там работают. Произвести замену, подобрать нового участника в команду аккаунту будет легко — он глубоко погружен в проект и хорошо понимает, что ему нужно.
В нашей практике были случаи , когда мы настаивали взять разработчика, которого отклонили после интервью , на тестовый период 1-2 недели. Мы взяли половину рисков на себя, если бы разработчик провалил испытательный, то 50% стоимости оплатили бы мы . Но этого ни разу не случалось — разработчики всегда оправдывали доверие и оставались на проекте.
Еще одна рекомендация — обязательно давайте фидбэк после интервью. Подрядчик дополнит ваши требования и будет знать, что для вас особенно важно. Так увеличится вероятность, что с последующими кандидатами все будет складываться быстрее.
Александр Морозов, руководитель центра компетенций Росбанка:
Вряд ли нормальный вендор будет пытаться подсунуть джуна вместо мидла или синьора и рисковать испортить отношения, а еще и тратить силы на такой микроменджмент. Плюс, это ничем не отличается от ситуации, когда с рынка приходит человек и рассказывает, что он синьор. Риск того, что такой неквалифицированный сотрудник проскочит, несущественно отличается от варианта с рынка, и на интервью все также будет ясно видно, в том числе и попытки вендора заранее подтянуть знания специалиста под профиль запроса.
Страх: а как я подключу к проекту сразу 10 человек? У меня же все сломается. Помогите!
Онбординг аутстафф-специалистов и штатных сотрудников ничем не отличается. Им точно так же необходимо ознакомиться с регламентами, подходами, требованиям к работе, таск-трекером и т.д.
Хаос наступает, когда в ручном режиме, открываются доступы, пересылаются документы, разработчики стучатся к разным людям, чтобы добыть нужную информацию. Целая команда специалистов, поступивших в проект единовременно , действительно может создать нагрузку на тимлидов, архитекторов, менеджеров со стороны клиента.
Как не допустить?
Следует заранее подготовить документ со всей необходимой информацией — ссылки на документы, доступы, ответственные лица. (Можете использовать наш шаблон ). В списке должны быть:
- Доступы (VPN, API, репозитории, Postman, Swagger и т.д.)
- Описание структуры команды. По каким вопросам к кому стоит обращаться?
- Инструкция по настройке dev окружения проекта.
- Бэклог задач для новых разработчиков, с обозначенными приоритетами, если известны.
- ТЗ на разработку (включая UI-кит, макеты и ссылки на Figma, требования к поддержке браузеров).
- Документация на существующий функционал.
- Правила коммуникации (чат в Телеграме, почта, Google-календарь, таск-трекер, форма отчетов, принятые точки контроля — например, еженедельные созвоны). Разработчик должен понимать, где и каким способом запросить уточнения по задаче, как решаются спорные вопросы, в каком виде он должен отчитываться о проделанной работе.
- Дедлайн и этапы проекта с примерным описанием результатов по каждому этапу для корректировки сроков.
Чтобы эффективность специалиста оправдывала ожидания, а отчетность заполнялась правильно и в срок — обязательно расскажите подрядчику про свои метрики, методы оценки эффективности и систему управления проектами, еще на старте сотрудничества. Обеим сторонам легче синхронизироваться в ожиданиях, если знать правила игры.
Наш опыт показывает: Удовлетворенность разработчика в проекте увеличивается на 20% из-за правильного онбординга, так как влияет на вовлеченность специалиста.
Екатерина Снегирёва, E-commerce Content Product Owner в AliExpress:
Оптимальный вариант — это две встречи. Первая — установочная, где мы обсуждаем продукт , его ценности и будущие задачи проекта , делимся документацией, отвечаем на вопросы. После него специалисту должно стать понятно, какого рода этот проект и интересно ли ему будет им заниматься.
Вторая встреча — организационная, когда техническая команда помогает получить нужные доступы, понять, где что лежит, куда и по каким правилам коммититься, как выглядит архитектура продукта, рассказывают какие-то особенности и так далее. Если ребята работают в рамках стандартных процессов, они быстро и легко адаптируются к работе в новой команде. Замедление в начале быстро проходит, процесс ускоряется и новые бойцы вливаются в единый поток. Бывает, что внутренняя команда не спешит принять «новичков», но это меняется в процессе работы над проектом или с помощью техлида и ситуативных коммуникаций.
Страх: а что если аутстафферы будут работать слишком медленно? Что тогда делать?
Не стоит судить о новых специалистах во время настройки процессов. В начале проекта штатные сотрудники и аутстафф-команды одинаково уязвимы и не способны показать истинную производительность. Все потенциальные проблемы проявляются в первые недели работы. Опытные подрядчики об этом знают, поэтому особенно пристально следят за проектом в начале.
Взгляд со стороны клиента:
Время, после которого можно судить о сотруднике, зависит от его роли. Дизайнер или тестировщик показывает результат уже после двух спринтов, тогда как разработчику нужно больше времени. Мы готовы присматриваться к сотруднику до трех месяцев. О замене приходится просить очень редко.
Но что делать, если период адаптации остался позади, а разработчик не показывает нужных результатов?
Как не допустить?
Основное правило здесь одно — не тяните с обратной связью. Стоит поговорить с подрядчиком о том, почему не достигается нужный результат, и что идет не так. Он в свою очередь проведет аудит, поговорит с сотрудником, найдет причины недовольства. После этого вы вместе решите, что делать: заменить сотрудника или устранить причины непродуктивности.
У нас был случай, когда клиент пришел и сказал, что снимает одного разработчика с проекта. Разбираться ни в чем не хотели — «нет и все». Когда выяснили причину, оказалось, что между нашим разработчиком и другим участником команды возник конфликт, который мешал общему делу. Мы предложили переход разработчика в другую команду в рамках этого же проекта и две недели испытательного срока. В итоге разработчик провел на проекте еще четыре месяца, до самого его завершения.
Если не стоит вопрос с мотивацией и вовлеченностью, а технические скиллы на достаточном уровне, ищите другие причины неэффективности — они могут быть неочевидными с первого взгляда. Разработчиков на рынке мало, но хороших менеджеров и коммуникаторов еще меньше, особенно в условиях когда все работают удаленно. Как показывает практика, тупиковых ситуаций почти не бывает, и если реагировать вовремя, положительный эффект обязательно будет.
Вот еще несколько рекомендаций, которых помогут сохранять хороший темп и качество работы:
- Менеджер со стороны клиента обладает полным знанием о проекте и лучше других может спрогнозировать временные затраты по задачам. Задачи должны проверяться вашим менеджером, чтобы вовремя заложить риски.
- Квалификация разработчика должна соответствовать задачам. Не давайте мидлу задачи уровня техлида. Но постепенно повышать сложность задач, чтобы сотрудник показывал рост — отличная практика.
- Менеджер со стороны подрядчика должен участвовать во всех рабочих чатах.
- Убедитесь, что ваш специалист работает только на вашем проекте. У разработчика неизбежно снизится эффективность из-за совмещения проектов и постоянного переключения между задачами и контекстом.
Екатерина Снегирёва, E-commerce Content Product Owner в AliExpress:
Первый положительный признак, который я оцениваю — это открытость человека к общению, его доступность для связи и коммуникации. От этого зависит насколько легко нам будет найти общий язык в дальнейшем. От объема работы и качества кода зависит оценка эффективность работы . Техлид дает оценку, насколько результат работы внешних специалистов соответствуют нашему запросу, гайдлайнам, выполняется ли запланированный объем работы. Первые четыре двухнедельных спринта обычно дают понимание, как ребята вошли в процесс — и по их итогам мы принимаем решение, как работаем дальше.
Страх: а что если аутстафф-сотрудники не такие мотивированные, как наш родненький инхаус?
Аутстафф-сотрудники обычно стараются достигать конкретных результатов в ближайшем будущем — например, успешно завершить проект за 3-4 месяца. Поэтому нам кажется, они обычно более мотивированы, чем инхаус-команда.
Но бывает так, что для своих сотрудников заказчик оставляет интересные задачи, а аутстафферам достается то, что горит или сломалось. В таких условиях снижается мотивация и сотрудники выгорают. Но вы же не не злоупотребляете этим?
Как не допустить?
Выполняйте обещания, которые вы дали разработчикам — относитесь к ним в этом вопросе так же, как к своим сотрудникам. Все, что вы рассказываете на интервью, не должно расходиться с реальностью. Например, если вам требуется работа с большими объемами legacy-кода трехлетней давности, не стесняйтесь сказать об этом прямо — с такими задачами тоже работают, но человек должен понимать, что его ждет.
Доверяйте аутстафферам серьезные задачи и свободу. Следите за балансом между рефакторингом и разработкой фич, которые позволят разработчику становиться лучше. Труды «в стол» способны убить любую мотивацию — если ты много работал над тем, что не пошло в продакшн, это обижает и демотивирует — даже если работа была оплачена.
Даже если сотрудник увлекся проектом и сам инициирует переработки, следите за этим и не поощряйте. Ровная производительность в долгой и стабильной работе намного лучше, чем вспышки продуктивности, которые сменяются провалами в результативности и мотивации.
Александр Морозов, руководитель центра компетенций Росбанка:
Бюрократия и отсутствие человеческих разговоров создают впечатление враждебной среды для любого специалиста. Надо всегда об этом помнить и уделять внимание каждому сотруднику. На моем прошлом месте работы мы даже внедряли программу наставничества: чтобы полчаса в день утром и полчаса вечером уделять своему подопечному в виде обязательной беседы. Аутстафферы — такие же полноценные члены команды и к ним тоже нужно применять этот метод .
Лучше сразу относиться к аутстафферам, как к родным сотрудникам, ведь никогда не знаешь кто из них через год-два перейдет к тебе в штат. Еще важно помнить, что любой сотрудник за пределами компании выступает как агент бренда. Позитив или негатив, который он распространяет может влиять на репутацию компании. Доказать, что негатив появился только из-за того, что он аутстаффер будет невозможно. Да и, скорее всего, только хуже будет.
На моем опыте работы с 70-80 аутстафферами не могу припомнить, чтобы кто-то из них не был мотивирован — все относились к работе как к своей. На мой взгляд, аутстаффер плохо работает, если он плохой работник, а не из-за того, что он аутстаффер.
Страх: а что если специалисты не делают мой проект, а целыми днями играют в Доту? Я же не вижу, чем они там занимаются
Инхаус-команда дарит сладкое ощущение полного контроля над ситуацией — вот люди, которые сидят в офисе на глазах у начальника и каждый день трудятся на благо предприятия.
Но когда клиент оплачивает каждый рабочий час специалиста, который сидит в чужом офисе или даже в другом городе, появляется желание тотально контролировать рабочий процесс и расходовать средства рационально.
Контракт на аутстаффинг предполагает, что клиент берет на себя ответственность за то, чтобы загрузить разработчика и часто предусматривает оплату простоев, то есть выкуп всех рабочих часов команды в заданный промежуток времени.
Однажды мы наблюдали интересную ситуацию со стороны, когда вместе с нами в команде работал специалист от другого поставщика. Менеджер клиента забыл про этого разработчика и не давал ему задач в течение двух недель. Поставщик почему-то промолчал и попросил оплату в полном объеме. Из-за этой ситуации клиент пересмотрел правила оплаты простоев для всех нас.
Можно понять клиента, который не хочет оплачивать простой. Можно понять поставщика в чьих внутренних регламентах такая ситуация не предусмотрена. Тем не менее, как выяснилось, существуют разные варианты развития событий.
Как не допустить?
2020 год показал всем нам, что удаленка — это не больно и не страшно. Будь то Москва, Сызрань или Бали, опытные компании умеют работать с регламентами и процедурами которые контролируют продуктивность сотрудников. Стандартный формат работы для аутстаффа: команда выполняет задачи по бэклогу, который формирует заказчик. Разработчик трекает потраченное на каждую задачу время. Отчетность сдается в конце месяца, после согласования происходит оплата. Ее размер зависит от трудозатрат, то есть заказчик может посмотреть, на какую задачу сколько затрачено часов, и сопоставить это с историей коммитов (порций) кода. Все прозрачно: понятно, куда потрачено время, а разработчик не страдает от того, что Большой Брат все время следит за ним.
Никита Лебедев, Product Owner в Сбер:
Прежде чем разработчик принимает какое-то важное решение, мы синхронизируемся, обсуждаем и решаем. Нужны процессы, скрам или его модификация, дэйли, груминг, ретро — неважно, удаленные у тебя исполнители, привлек ты аутстафферов на месяц или они твои инхаус.
Измеряем эффективность — если оценили фичу в две недели, а делали месяц, то собираемся на ретро и обсуждаем, почему так произошло, какие проблемы и как это исправить.
Важно понимать, что бэклог формирует заказчик. При этом, нет ничего зазорного в том, чтобы обратиться к аккаунт-менеджеру подрядчика если у вас возникли сложности с постановкой задач или загрузкой аутстафф-команды. Вместе вы можете обсудить это и решить, что делать.
Если ваши прогнозы по загрузке не сбылись и полный объем часов не востребован, здесь есть несколько вариантов действий:
- Профилактика. Разработчик (команда) прогнозирует свою загрузку и заблаговременно информирует об этом вашего менеджера. Проактивность — наше все.
- Оплачивать часы простоя с дисконтом, чтобы разделить нагрузку пополам. Таким образом за вами сохраняется бронь команды, а поставщик закрывает свои косты, чтобы не работать в минус.
- Сокращать команду и выкупать объем, равный текущей потребности. Обычно заявки подписываются ежемесячно, что позволяет регулярно пересматривать планы и корректировать свой объем обязательств.
Денис Самбудагва, Product Manager в Delivery Club:
Если вы инхаус разрабатываете бэкенд, а фронтендом занимается внешняя команда, то надо понимать, сможете ли вы работать синхронно. В нашей практике была ситуация , когда подрядчик почти закончил приложение, а наш бэкенд сделал API только на 50%. Чтобы не расходиться в сроках и ожиданиях, важно заранее договариваться и предупреждать, если разработка задерживается.
Страх: а что если у меня украдут конфиденциальные данные и продадут конкурентам?
Ощущение того, что сохранить конфиденциальность внутри команды легче, во многом ложно. Организуя процессы правильно, можно добиться тех же результатов и на аутстаффе.
Как не допустить?
Распространяйте на аутстафферов все механизмы контроля, принятые в команде. Бюрократизируйте процесс передачи конфиденциальных данных, их хранение и утилизацию. Используйте специализированное ПО для защищенного подключения сотрудников (например, Citrix).
Для доступа к сервисам заказчика обычно используется VPN, что обеспечивает безопасное соединение с корпоративной сетью и позволяет пользоваться сервисами заказчика (Jira, Gitlab, Bitbucket и другие внутренние сервисы). В некоторых случаях для подключения к VPN используется только логин и пароль, в других — двухфакторная идентификация с помощью специального устройства (токена).
В крупных организациях, обычно работает служба безопасности и собственный софт обеспечивающий возможности удаленного доступа. В таких компаниях (например, в банках) конфиденциальности данных уделяют особое внимание. Для подрядчиков это не является чем-то критически сложным, обычно нет причин для не соблюдения регламентов безопасности клиентов. Еще один выход — оформить аустафф-разработчика на 0,1 ставку, чтобы допустить к внутренним информационным системам.
Александр Морозов, руководитель центра компетенций Росбанка:
В частных компаниях к этому относятся проще, чем в банках. У нас же этими вопросам занимается служба безопасности. Как и везде, они устанавливают Citrix, который обеспечивает безопасный доступ к внутренним приложениям..
Сохранить конфиденциальность поможет подписанный с каждым сотрудником NDA и указанные в нем суммы штрафов за разглашение информации.
А мы с вами до конца? Как сделать так, чтобы мы оставались счастливы вместе
Релиз отправился на продакшн, цикл завершен — и вот у вас появилась новая ачивка «сделать проект руками аутстафферов». Теперь у вас есть проверенный поставщик ресурсов, который понимает ваши требования и особенности. Расширяйте взаимодействие и достигайте новых результатов. Но что, если…
Страх: а что если подрядчик меня бросит? Выйдет из проекта или заберет половину команды!
Причины могут быть разными:
- Подрядчику интересны проекты с долгосрочным сотрудничеством, где можно спрогнозировать загрузку, где есть договоренность о том, сколько продлится совместная работа. Делитесь совместными планами и мыслями о будущих проектах — это повысит ваш рейтинг в глазах подрядчика.
- Иногда разработчики увольняются из агентства. Такое случается. Организуйте процесс передачи знаний — например, договоритесь о том, что некоторое время предыдущий разработчик будет консультировать нового члена команды.
- Вы хантите людей подрядчика. Не надо так. Веб-продакшны в любом случае теряют много людей, которые органически уходят на рынок на сторону клиента и в другие компании. Да и будет ли вам выгодно забрать одного разработчика в штат и лишиться еще пятерых, которые останутся у подрядчика?
- Не индексируются ставки. На очень длинных проектах ставки специалистов могут расти, так как повышаются заработные платы (осень 2020 показала, как стремительно это может происходить). Относитесь к аутстаффингу как к HR-процессу, а не как к закупке товаров. Цепочка здесь очень простая: вы не проиндексируете ставку — поставщик не сможет увеличить зарплату своему сотруднику — сотрудник уволится и вы его потеряете. Поэтому если вы планируете работу на очень долгой дистанции, обратите внимание, прописан ли этот пункт в договоре.
Культура аутстаффа пока только складывается, заказчики и подрядчики вместе строят правила эффективной работы. Но спрос на такой тип услуг растет с невероятной скоростью — а значит, мы должны как можно быстрее формировать культуру взаимодействия. В этом материале мы постарались обобщить собственный опыт, чтобы развеять страхи, избавиться от стереотипов и дать клиентам инструменты по отработке самых распространенных рисков.
Желаем удачи в выстраивании win-win-взаимодействия!
Есть что дополнить? Напишите в комментариях или в telegram , с какими страхами и рисками вы сталкивались? Какие дали бы рекомендации? Конструктивные комментарии по теме попадут в обновленную статью.