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

Веб-студия Reactive основана в Перми в 2001 году. 500+ ИТ-проектов в коммерческом и государственном секторе. Сайты, сервисы, автоматизации, фирменные стили.

Сергей Калагин, руководитель проектов в Reactive:

Серьёзная ИТ-контора заключила крупный контракт на разработку информационной системы. Срок до конца текущего года. Проходят месяцы предварительной оценки работ компания понимает, что для реализации проекта в срок текущих кадров не хватит. Кто-то, конечно, говорит, что должны успеть. Но люди с опытом предупреждают, что всё на тоненького и нужно начинать искать дополнительные ресурсы. Пока утверждают новую штатку и озадачивают HR, пролетает ещё месяц. Менеджеры шерстят предложения ИТ-агентств и студий думают нанять временных специалистов по схеме аутстаффинга. Руководство говорит: Дорого, ищите дальше или делайте сами. Месяц. Еще месяц. Полгода. Становится очевидно, что сроки сорвут, и тогда штрафы обойдутся куда дороже, чем сторонние специалисты. Компания обращается к нам за аутстаффом.

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

Доволен клиент счастлива студия. Больше лояльных заказчиков, разработчики не скучают между вкусными проектами, есть о чём написать на habr и vc. И тут начинается чехарда.

Алексей Волков, один из двух основателей и управляющий студии разработки DigitalWand

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

DigitalWand лучший аутсорс-продакшн в России по версии Tagline основана в 2015 году партнёрами из Москвы и Краснодара. 500+ проектов для 200+ клиентов: Лаборатория Касперского, ГК ПИК, Deloitte, МETRO, и другие. Специализируется на PHP и Python стеке на бэкенде и React, vue.js, вёрстке на фронтенде. 40 сотрудников.

DigitalWandникогда не хотели заниматься только аутстаффингом, хотя всё с него и началось:

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

Стратегически, однако, Алексей на этом бизнес не строит:

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

С другой стороны, и у самих разработчиков при такой схеме есть предел роста:

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

Роман Штых, директор компании Fullstack Development разработчиков из Томска

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

Fullstack Development работает с 2013 года. Из 50 сотрудников больше 40 разработчики. Штат разбросан по России. До трети оборота компании заказы из Индии, Европы и США. Frontend-специализация Typescript+React+Redux. Backend Haskell. Доля аутстаффа в обороте до 40%.

Продажа почасового труда и дляFSDне была стратегическим приоритетом:

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

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

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

Минчане Appservice развивают сразу оба направления.

Валерий Семилетов, директор Appservice

Аутстаффинг у нас половина оборота, изначально одно из направлений бизнеса. Я никогда не переживал, что предоставляю сотрудников под управление другого менеджера. Этого боятся, когда страшно потерять человека, и он уйдёт в другую команду. Но тут надо другим заинтересовывать сотрудника: если человек не хочет у тебя работать, ты его не удержишь это ИТ. Я не боюсь давать контакты напрямую, потому что сотрудников привлекаю не ограничениями, а плюшками. Большой клиент не уведёт сотрудника это удар по репутации, а в остальном просто работайте ребята, и всё будет хорошо.

Appservice белорусская компания выходцев из ИТ-отдела Raiffeisen Group. Технологии: Back-end Python, PHP и Java, JS; Frontend React, Angular, JS, HTML, CSS; Mobile Swift, Kotlin, React Native.

Аутстафф-разработчиков привлекают в компанию и зарубежные проекты Appserviceработает в основном с ЕС, США и Россией:

Мы изначально так ориентировались. Внутренний рынок Белоруссии маленький, он не в тренде. Из США и ЕС заказы получаем через партнёров диджитал агентства без своего офиса разработки. Помогает и линкедин, и конференции, и фейсбук.

Прицел на Запад подтверждаетРоман Штых:

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

А вот другой сценарий: Reactive сначала был потребителем заёмного труда, затем стал поставщиком. РассказываетСергей Калагин:

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

Со временем внешних аутстафф-сотрудников становилось больше.

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

Два года назад, когда такой способ работы стал для Реактива необходимой нормой, ребята открыли своё аутстафф-направление.

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

Для Реактива аутстафф не только дополнительный доход: работа по такой схеме заставляет улучшать и внутреннюю систему подбора и развития сотрудников. Обучение скиллам базовым или продвинутым, в зависимости от грейда специалиста притягивает в студию способных программистов, и гарантирует аутстафф-клиентам, что с ними работают люди с актуальными знаниями и опытом. Программы обучения, развития и менторинга мощный инструмент компаний-разработчиков.Роман Штых о системе подготовки кандидатов в Fullstack Development:

Разработчики нужны всегда. Найти готовых с нужным уровнем трудно. В 2016 году мы решили сделать бесплатнуюпрограмму, чтобы человек в ней был заряжен на рост, и потом приходил уже уверенным в себе джуниором. Она открыта для всех на сайте, длится 6-8 месяцев и состоит из пяти заданий. Разбираешься в коде, верстаешь сайт, собираешь единый проект и отправляешь на ревью разработчикам. Если всё ок, то собеседование, трудоустройство.

Такая программа со временем становится общим плодом компании и соискателей:

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

Пройти такую программу под силу не всем: 20 000 записались, закончили 50. Но это те, у кого есть мотивация и дисциплина лучшие, интересные, перспективные. Сразу после программы специалисты уже решают джуниорские задачи. Есть пример выпускника, который меньше чем за год вырос до миддла. Меняем людям жизни и открываем яркие таланты - говорит Роман:

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

DigitalWand отбирает сотрудников не менее строго.Алексей Волков:

Критерии людей, которых мы пускаем внутрь, чётко разграничены по таблице грейдов. Кандидат заполняет бланк со скиллами и проходит техническое интервью: я проверяю его таблицу, соотношу данные с реальностью. Как правило, это негативный сценарий. Хороший вариант когда я прошу: Расскажи про интересный проект, спрашиваю: Что тебе нравится в твоей работе?, и человек азартно рассказывает не остановить. Завязывается свободный неформальный диалог с углублением в технические детали это уже не допрос, как на уроке в школе. Без увлечённости в нашей сфере плохо: недавно расстались с джуном, который пришёл в программирование только потому, что здесь много денег. А когда приходят ребята-идеалисты, пусть и малоопытные, но им важно, интересно, огонёк в глазах, то стараемся заметить и поймать такого человека.

Нанял развивай. ПродолжаетАлексей:

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

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

Всерьёз прокачивают сотрудников и в FSD.Роман:

По итогам входной программы на собеседовании сотрудник сдаёт на первого джуна. Сдал добро пожаловать на карту развития Developers roadmap описание того, что должен знать разраб на каждом грейде: 3 джуниора, несколько мидлов, сеньор. Чёткие вопросы и технологии, по которым оценивается сотрудник. Если ты джуниор первого уровня и собираешься сдавать на второй, то изучаешь темы этого грейда, и сдаёшь их более опытным программистам. Мы верим, что лучшее обучение когда обучаешь другого. Примерный срок каждой аттестации планируем уже при трудоустройстве. Это непросто работать с мотивацией, поддерживать культуру саморазвития: чувак, мол, нужно сдавать. А софт-скиллам не обучаем: они должны быть по дефолту, это видно на собеседовании.

Технические компетенции Экспекто патронум и Алохомора программиста. Но без дисциплины как без волшебной палочки они мало чего стоят. При удалённой почасовой, да ещё и аутстафф работе трекинг времени и онлайн контроль специалиста приходятся к месту.Роман Штых о том, как с этим обходятся в Fullstack Development, и как к этому относятся разработчики:

Противоречий с сотрудниками не было. Оплата почасовая: натрекал 120 часов, столько и оплатим. Клиенты платят по той же схеме time & material. Работаем по тайм-трекеру clockify. За экраном компьютера разработчика не следим. Раньше был скриншот монитор, но быстро отказались: всё равно работали на доверии. Один раз только было такое, что чувак натрекал 30 часов и ничего не сделал мы тут же расстались. На входе стараемся валидировать ребят, чтобы по культуре подходили. Если токсичные и нечестные, то не берём.

В DigitalWand доходит и до просмотра экрана, но и здесь таких случаев единицы, - говоритАлексей Волков:

Для новых сотрудников используем hubstaff: сервис записывает экран, считает активность мыши и клавиатуры. Без этого не работаем. Когда понимаем, что с сотрудником совсем всё плохо, то туда лезем. На заре компании, пока не выработали жёсткие критерии соискателей, брали проблемных людей. Была ситуация: человек настроил скрипт и ушёл по своим делам. На экране сменяли друг друга окна с браузером и кодом, казалось, что кто-то кликает мышью и жмёт на клавиши. Мониторинг позволил с таким волшебником быстро распрощаться.

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

Как управляют удалёнными сотрудниками в Appservice комментируетВалерий Семилетов:

Мы поняли, что скрининг монитора не дает эффекта. При этом часто демотивирует сотрудника. Как будто мы ему не доверяем.

В поисках модели управления удалённой работой студия пришла к таким выводам:

1. Нужно вести четкий и последовательный учет задач.

2. Желательно декомпозировать задачи таким образом, чтобы их выполнение не занимало более одного дня.

3. На дейли-митингах проводить контроль выполнения задач вчерашнего дня, и определять задачи на текущий день.

4. Держать в запасе задачи на два-три дня на каждого человека.

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

Благодарим руководителей представленных компаний за время и помощь в составлении материала. Отдельная благодарностьВалерию Семилетову: все это время в Минске проходят протесты, ситуация напряженная, была объявлена национальная забастовка.

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

Так что, кому тяжело, держитесь, желаем мира!.

Reactive. Made in Ural.

Как избежать недопонимания между сотрудниками и добиться лучших результатов в работе в нашем переводе статьи специалиста международной ИТ-компанииShakuro.

Аутсорсинг уже давно стал повседневной практикой на рынке труда. Вы можете с лёгкостью найти потенциального сотрудника в любой точке мира. Это явление ярче всего проявляется в ИТ-индустрии. Для работников этой отрасли лимит знаний и технических навыков устанавливает только их собственное желание становиться лучше.

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

Существует три полярности, возникающих при оценке проблемы:

• Проблема требует технического/творческого подхода

• Проблема решаема/не решаема

• Проблема произошла из-за недопонимания/небрежности

Характер того, как человек взглянет на проблему, будет носит чёткий отпечаток его культуры. И так как у каждого этот отпечаток разный, эти отличия могут встать на пути у перспективного аутстаффинга. Давайте разберём этот вопрос подробнее.

Нанимайте людей, а не просто сотрудников

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

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

В этом случае вы нанимаете сотрудников, руководствуясь не только их навыками, но и множеством других факторов как:

• Национальная принадлежность

• Культурная принадлежность

• Религиозная принадлежность

• Социальные стандарты

• Стереотипы

Национальная принадлежность

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

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

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

Тщательно изучите национальные особенности клиента при помощи метода 360 градусов. Избегайте предубеждений и учитывайте специфику их культуры независимо от их географического положения.

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

Культурная принадлежность

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

Наша компания работает в сфере ИТ. Это значит, что вся наша культура строиться вокруг компьютерных технологий, программирования и интернета. Весь наш язык построен вокруг этих тем.

Быть в курсе всех трендов в мире технологий это полдела. Чтобы оставаться востребованным на рынке труда, нужно также оттачивать свои технические навыки. Когда мы проводим собеседование у кандидатов на должность UI/UX дизайнера, тимлид всегда интересуется увлечениями соискателя. Это помогает выявить его культурные и художественные склонности.

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

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

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

Всё-таки люди дорожат своими интересами и готовы с радостью рассказать вам о них, если вы проявите интерес.

Религия

Почему это вообще должно иметь значение? Всё просто: религия является одним из факторов, составляющих мировоззрение человека. Она способна повлиять на принятие решений. Ключевым фактором здесь служит вера. Это не просто убежденность в существовании высших сил это набор принципов и правил, которые отражаются в каждом принятом решении.

Нам повезло, что мы выросли в многоконфессиональной стране и смогли ознакомиться с разными религиями: Христианством, Буддизмом и Иудаизмом.

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

Социальные стандарты

Мир многообразен не только в этническом, культурном и религиозном плане. Отличаются и социальные стандарты. Говорят: Сытый голодному не товарищ, получается, если разница в уровне жизни слишком велика, то на свете нет возможности достичь взаимопонимания?

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

Для наших аффилированных структур мы инвестируем в качественное оборудование, скрупулезно отбираем кандидатов и воспитываем в наших сотрудниках наилучшие профессиональные качества.

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

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

Стереотипы

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

Любой менеджер с зарубежным опытом работы может часами рассказывать забавные истории о том, как ведут бизнес в разных странах. Одну из таких историй поведал нам один из наших сотрудников:

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

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

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

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

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

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

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

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

Послесловие

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

Однако вы можете перенять некоторые национальные и культурные особенности ваших иностранных коллег и в целом вести себя уважительно по отношению к ним и их особенностям.

Наши рекомендации по установлению наилучших взаимоотношений с аутстафферами:

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

• Не полагайтесь на интуицию. Разбирайте и уточняйте каждую мелочь.

• Мотивируйте сотрудников изучать культуру тех, с кем и на кого они работают. Помогайте им в этом.

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

Привет! Я Глеб Корсунов, директор по развитию Holyweb. Мы разрабатываем корпоративные системы и сервисы для IT-холдингов, ритейла, медиаплатформ и edtech-продукты.

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

Чтобы 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 в Сбер

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

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

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

Если ваши прогнозы по загрузке не сбылись и полный объем часов не востребован, здесь есть несколько вариантов действий:

1. Профилактика. Разработчик (команда) прогнозирует свою загрузку и заблаговременно информирует об этом вашего менеджера. Проактивность наше все.

2. Оплачивать часы простоя с дисконтом, чтобы разделить нагрузку пополам. Таким образом за вами сохраняется бронь команды, а поставщик закрывает свои косты, чтобы не работать в минус.

3. Сокращать команду и выкупать объем, равный текущей потребности. Обычно заявки подписываются ежемесячно, что позволяет регулярно пересматривать планы и корректировать свой объем обязательств.

Денис Самбудагва, Product Manager в Delivery Club

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

Страх: а что если у меня украдут конфиденциальные данные и продадут конкурентам?

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

Как не допустить?

Распространяйте на аутстафферов все механизмы контроля, принятые в команде. Бюрократизируйте процесс передачи конфиденциальных данных, их хранение и утилизацию. Используйте специализированное ПО для защищенного подключения сотрудников (например, Citrix).

Для доступа к сервисам заказчика обычно используется VPN, что обеспечивает безопасное соединение с корпоративной сетью и позволяет пользоваться сервисами заказчика (Jira, Gitlab, Bitbucket и другие внутренние сервисы). В некоторых случаях для подключения к VPN используется только логин и пароль, в других двухфакторная идентификация с помощью специального устройства (токена).

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

Александр Морозов, руководитель центра компетенций Росбанка

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

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

А мы с вами до конца? Как сделать так, чтобы мы оставались счастливы вместе

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

Страх: а что если подрядчик меня бросит? Выйдет из проекта или заберет половину команды!

Причины могут быть разными:

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

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

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

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

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

Желаем удачи в выстраивании win-win-взаимодействия!

Есть что дополнить? Напишите в комментариях или мне в telegram, с какими страхами и рисками вы сталкивались? Какие дали бы рекомендации? Конструктивные комментарии по теме попадут в обновленную статью.

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

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

Компании Holyweb, которая специализируется на аутстаффинге ИТ-персонала, стало интересно, что стоит за этими цифрами. Они решили задать вопросы непосредственно тому, кто принимает такие решения руководителю разработки на стороне клиента.

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

Стоит ли бояться, что подрядчик выйдет из проекта или заберет половину команды?

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

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

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

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

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

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

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

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

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

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

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

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

Как доверять, но проверять?

Универсальный совет выделите сотрудника, который следит за загрузкой специалистов и администрирует всю работу аутстафф-команды.

Но, честно говоря, не думаю, что стоит внедрять специальные практики для контроля над внешними сотрудниками. Есть ключевые параметры цена, качество кода и скорость работы. Меня, как заказчика, волнует, сколько денег я потратил и что за них получил.

Если для эффективной работы программисту нужно играть на балалайке или в Dota пожалуйста. Оценивать мы будем результат.

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

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

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

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

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

Когда можно делать первые выводы об эффективности аутстафферов? Первый месяц работы самый важный?

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

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

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

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

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

Мы проводим полноценное техническое интервью такое же, как для сотрудников Mail.ru Cloud Solutions, которых берем в штат. Обязательно уделяем внимание софт-скилам разработчика и его кругозору. Кроме того, устраиваем собеседование с руководителем команды и продуктовым менеджером.

Этапы отбора не отличаются для аустафферов и членов инхаус-команды, ведь требования и для тех, и для других у нас одинаковые.

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

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

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

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

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

Про возраст

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

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

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

Про опыт

В разных странах практикуется такое явление, как Gap Year. То есть год после школы и перед следующим учебным заведением ты тратишь на то, чтобы посмотреть свет. Бывшие школьники путешествуют, набираются опыта, размышляют о своем будущем.

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

Ну и всё это на фоне роста основных скиллов.

Если говорить конкретнее, то у нас есть заказчики из финтеха, есть просто технологические компании, есть ecommerce с посещалкой в несколько миллионов. Сомнительных проектов у нас просто нет, мы не беремся за сайты Свидетелей Иеговы, как тутписали в комментах:)

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

Михаил, QA-специалист Holyweb

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

Про стабильность

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

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

Понятно, что работу ты найдешь, и даже, возможно, с запросами я сеньор, 2 года опыта, дайте 250К и личный вертолет. Хотя эйчарам лучше бы насторожиться.

Поэтому аутстафф-компания (по сути сервисная) от такого защищает. Отвалился один проект перешли в другой.

Даниил, React-разработчик Holyweb

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

Про деньги

Ага, вы продаете джунов как мидлов, платите им 30К, остальное в карман! примерно так часто пишут про аутстаффинг.

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

К слову, в одном из предыдущих материалов мы рассказывали, как клиенту работать с таким форматом и разбирали распространенные кейсы.

Про комфорт разработчика

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

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

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

Геннадий, PHP / Node.js разработчик Holyweb

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

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

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

Итого за 2,5 года не было таких случаев, когда бы разработчик хлопал дверью и уходил, потому что ему было некомфортно работать.

Про нелюбовь к релокейтам

Вопрос из самого начала: а зачем разработчику работать с вами, когда он может пойти сразу к конечному работодателю? Тут стоит сказать, что мы работаемC13Cтолько на удаленке. Разработчики с нами, мы с заказчиком. В то время как многие работодатели продолжают предлагать релокейт как обязательное требование: это их привычный формат работы. И это несмотря на то, что за весну-2020 все должны были привыкнуть к дистанционной работе.

Суть в том, что иногда разработчики просто не хотят переезжать в Москву, на Кипр, в Мачу-Пикчу или куда угодно еще. В силу разных причин. В то же время разработчик из региона, доросший до мидла, обычно начинает искать работу вне своего города: потому что местные компании в большинстве случаев не хотят или не могут платить соразмерно запросам. Остается удаленка.

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

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

Про ООО НДА

Еще одно популярное сомнение звучит так: у вас, наверное, всё под NDA, что я напишу в резюме?. На самом деле, это надуманная проблема работодатели почти никогда не смотрят на названия проектов, в которых вы участвовали, им важна ваша роль в этих проектах и конкретные решенные задачи. Ну и наличие Большой Важной Компании в резюме сейчас не говорит примерно ни о чем: все работодатели понимают, что такие пылесосят резюме как угорелые и потом выплевывают обратно на рынок кадров откровенно слабых специалистов с перегретыми ожиданиями по зарплате и раздутым ЧСВ. Конечно, это не правило, но такое бывает часто.

Мы знаем, как работать с резюме и помогаем каждому сотруднику его оформить, структурировать, подсветить нужный опыт. Добиваемся того, чтобы CV соответствовало стандартам рынка, как российского, так и мирового мы тоже в этом заинтересованы, не только сами разработчики.

Про софт скиллы

У нас была такая история. Команда закончила длительный проект, всё успешно, ребята опытные. Мы договорились со следующим заказчиком, назначили время интервью.

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

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

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

Про то, как мы собеседуем клиентов

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

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

Более того, эти требования к клиенту могут меняться в зависимости от потребностей команды. Например, у нас был случай, когда разработчику Vue.js накидывали задачи по верстке. Это, конечно, было не тем, что он хотел делать и он нам об этом рассказал. В итоге мы нашли компромисс с заказчиком и разработчик стал получать задачи по Vue.

Петр, React-разработчик Holyweb

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

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

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

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

Дэннис, React-разработчик Holyweb

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

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

Итого, что дает программисту работа аутстаффером:

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

2. Прокачка опыта в собеседованиях. У нас наработаны разные практики прохождения технических интервью, мы учим, как подавать себя. И реальные собеседования бывают раз в несколько месяцев.

3. Резюме. Разработчики получают опыт, который могут положить в свой CV и одновременно учатся правильно его оформлять.

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

5. Можно развиваться как горизонтально, так и вертикально. Кому-то нравится расширять стек или специалист просто находится в поиске лучшей специализации для себя, кому-то больше по душе копать вглубь. В аутстафф-компании можно развиваться так, как хочется.

6. Отношение к аутстафферу в команде проекта ровно то же, что и к своим разработчикам это просто выяснено на нашем опыте.

Понимаем, что у вас все равно остались вопросы так что пишите в комментариях или мне в Telegram.

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

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

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

Хороший вопрос. Думаю, множество разных определений существует. Интеграция в клиентские команды это определенная часть деятельности компаний, которые осознают себя как сервисные. Есть компании, которые создают какой-то продукт, пытаются его вывести на рынок, поддерживать и развивать. А бывают компании, как Distillery, которые обнаруживают (если у них есть достаточно сил для этого), что они сервисная компания, то есть занимаются обслуживанием интересов других организаций, которые, например, развивают свой продукт.

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

А второй вид услуг это то, о чем мы сейчас говорим. Есть более элегантное определение staff augmentation. Мы сейчас живем в постиндустриальную эпоху, киберпанк к нам уже мчится на всех парах, и становится очевидно, что аугментации могут быть разных видов. И, как оказалось, аугментировать можно еще и инженеров в свои команды. Как вид сервиса это отдельная услуга, и она заключается в том, что мы находим по требованиям клиента лучших людей для того чтобы интегрировать их в процессы клиента, где эти люди будут добиваться целей, поставленных компанией-клиентом перед собой.

Есть какие-то особенности вашего подхода?

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

В какой-то мере эту деятельность вообще можно сравнить с консалтингом. В нашем понимании staff augmentation и консалтинг находятся друг от друга находятся максимально близко. Есть большие консалтинговые компании, мы все их знаем, это Ernst & Young, KPMG, собственно, you name it, большая четверка. У них это только песчинка на целом пляже их услуг, но, тем не менее, они примерно этим же и занимаются. И для нас целевое состояние это стать на рынке той компанией, к которой приходят за экспертизой, а не просто за людьми. Задача Distillery приносить свой опыт и помогать улучшать те процессы, которые уже существуют у клиента.

Интересно, какова мотивация человека, который приходит работать именно в фирму, которая которая предоставляет услуги staff augmentation?

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

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

А часто бывает, что клиенты в итоге переманивают к себе вашего разработчика?

Безусловно, это явление существует. Когда мы были молодыми и неопытными, около 10 лет назад, были такие случаи. И после них, конечно, пришлось очень серьезно переработать контракты с клиентами, внести туда пункты о непереманивании, которые несут в себе санкции. Сейчас клиентские организации берут обязательство не переманивать сотрудников, которые работают на них не только во время работы, но еще некоторое время после того, как мы заканчиваем с ними контракт. Прописаны определенные санкции, штрафы, которые мы будем иметь возможность с них получить, если это случится. Однако я не склонен считать этот пункт серьезной угрозой для тех, кто отчаянно хочет чего-то его можно преодолеть. По сути, ты можешь заплатить штраф, нарушив правила Я думаю, что есть компании, для которых это нормально: кучу денег отвалить, но зато получить супер-классного специалиста. Но главная причина, почему этого не происходит, почему исчезающе редки такие случаи потому что мы уже работаем на том уровне, с такими, что называется well-established, компаниями, которым такая игра попросту не интересна. И поэтому, к счастью, мы уже таких случаев не фиксируем довольно давно.

Я прочитал, что Distillery начиналась в России, и в какой-то момент она вышла на рынок США. И сейчас на рынке США вы занимаете какие-то существенные позиции. А кто и кого через вас нанимает? Российские фирмы российских разработчиков, американские американских, или, что ожидаемо, много русских людей работает сейчас через вас с фирмами в США?

Да, в 2012 мы открыли в США представительство. Сейчас там все продажи сосредоточены, весь маркетинг. И все это время мы выстраивали очень простую модель: фронт-офис находится в Штатах, а инженерные офисы в России и постсоветском пространстве. У нас всегда был фокус на то, что мы ищем американских клиентов и сажаем на них наших русских родных инженеров. Сейчас эта парадигма несколько изменилась, потому что чуть больше года назад у нас появились инжиниринговые центры также в Латинской Америке и Мексике. Сейчас и в Мехико-Сити, и в Кордобе у нас есть офисы, и они совокупно уже за год пробили потолок в 100 человек. Поэтому там растет альтернатива российским инженерам мы сами ее взрастили.

Это отражается на спросе на российских инженеров, но мы начали работать с энтерпрайзом уже здесь, в России. Мы собираемся развиваться в направлении Европы: сейчас это стало сложнее, но в 2021 году мы планируем уже полноценно открыть представительство в Великобритании. В 2020 году у нас в России уже появились довольно значимые enterprise-заказчики (прежде всего в банковской сфере), для которых мы тоже предоставляем людей, нанимаем людей. Поэтому сейчас у нас диверсифицирован поток. Но долгое время это действительно были американские проекты, на которых работали русские инженеры.

К Вам люди трудоустраиваются по российскому законодательству?

Да.

А фактически с заказчиками вы сотрудничали на основе законов США?

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

Некоторые считают, что в России у staff augmentation достаточно сложный правовой статус. Вы сталкивались проблемами в этом плане?

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

А вы к себе берете самозанятых или у вас полноценный прием на работу?

Мы сотрудничаем с людьми, которых можно назвать самозанятыми или фрилансерами. К сожалению по законодательству мы не можем сделать это основным видом сотрудничества это вызывает вопросы, особенно у налоговой. Основной вид взаимодействия с людьми это, конечно, полное оформление по ТК РФ.

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

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

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

То есть вы выступаете в роли менеджера сотрудника?

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

Не перегружен ли человек, который работает в staff augmentation проекте, количеством управленческих контактов, с которыми нужно что-то согласовывать? Есть заказчики, есть начальство из материнской компании

Очень хороший вопрос. Как мы стараемся решить эту дилемму? Прежде всего, за счет того, что сужаем количество контактов, необходимых человеку для нормального функционирования, до плюс-минус одного. У нас есть бытовая часть: например, за развитие отвечает руководитель отдела к нему пойти, получить какой-то курс или программу развития Но если мы говорим о проекте, то здесь довольно все просто и линейно: нас есть специально обученный человек, задача которого присматривать за тем, что происходит на проектах. У нас он называется client success manager. Его задача убеждаться, что все хорошо, всего хватает всем людям, которые работают на вверенных ему проектах, и у них нет никаких проблем. А если есть, то любой человек из команды может прийти и попросить помощи. Помощь может быть любой: от каких-то внутренних проблем до проблем со взаимодействием с клиентом. И CSM обязан сформулировать запрос, поговорить с представителем руководства фирмы-клиента, попробовать решить эту проблему за этого человека, чтобы он не тратил свое продуктивное время на какие-то посторонние вещи.

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

А какой средний возраст у разработчиков, которые с вами сотрудничают?

Сейчас этот возраст довольно сильно колеблется: индустрия растет, много молодых людей приходит, при этом старый актив взрослеет, матереет. Сейчас, наверное, это окно стало очень широким. Условно, коридор от 23-24 до 37-40 лет. Раньше это было сложно представить, средний возраст был 25-32 лет. Сейчас снижается возраст тех, кто приходит, и возраст тех, кто уже чего-то добивается. Дядюшка Боб Мартин сказал когда-то, что у нас индустрия 25-летних сеньоров сейчас эту цифру можно снизить до 23. К нам часто приходят люди с университетской скамьи, которые уже в процессе обучения стараются строить карьеру.