Менеджмент

Адаптация новых сотрудников: что нужно знать DevOps-компаниям?

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

Чтобы с этим бороться, специалисты разработали процесс адаптации. Такая практика существует с 1970-х годов. При этом, по данным Harvard Business Review, 22% компаний вообще не имеют процессов адаптации и онбординга. Более трёх четвертей из тех, у кого эти методы есть, они не налажены должным образом. Результат: компании теряют ресурсы (время, финансы), пока новый сотрудник пытается понять, какие перед ним стоят задачи, к кому обращаться по разным вопросам.

С чего начать процесс адаптации нового сотрудника в офисе и на удалёнке? Отличается ли онбординг DevOps-инженеров и людей из других отраслей? Об этом говорили со специалистами компании NetForce Ukraine: Павел Завада — CEO, Александр Барахтянский — CTO и Ева Фурсова — HR. 

ТОП ошибок: как не нужно проводить процесс адаптации

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

Александр Барахтянский, CTO в NetForce Ukraine

Пошаговая инструкция онбординга IT-специалиста

Шаг 1. Знакомство

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

Итак, план действий такой:

• Знакомство с инструментами и ПО. Чтобы сократить процесс обучения и сделать первые дни нового сотрудника более эффективными, убедитесь, что они знают инструменты (типа Jira), которые будут использовать. В идеале нужно предоставить новичкам подробные инструкции или организовать специальную встречу с инструктором. Если вы используете инфраструктуру Atlassian, подумайте об пространстве Confluence для таких руководств.
• Знакомство с корпоративной культурой. Все компании в чём-то уникальны. Есть своя атмосфера и уровень знакомства между сотрудниками. Есть рекомендации по эскалации проблем, которые ваша команда органически превратила в уникальную корпоративную культуру. Поэтому рекомендуется создать Wiki для сотрудников в Confluence, где будут описаны самые основные правила работы в компании. От “Slack только для рабочих вопросов”, до “каждая четвёртая пятница месяца — пивная веб-встреча с коллегами”.
• Знакомство с коллегами. Для начала, представьте будущего руководителя новому сотруднику. Это идеально делать ещё на этапе собеседования. Представить остальную команду нужно уже в первый рабочий день. Если проводите адаптацию удалённому разработчику или DevOps-инженеру, создайте общий колл с командой. Так коллеги перестанут быть “просто именами в корпоративном чате”.

Шаг 2. Настройка рабочего места

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

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

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

Шаг 3. Техническая документация

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

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

Вот чек-лист для удалённых разработчиков ПО:

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

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

Полезно включить файл Docker в рабочую сборку вашего проекта. Если речь идёт об DevOps-специалистах, то здесь нужно говорить об Kubernetes.

Шаг 4. Сопровождение HR и тимлида

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

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

Ева Фурсова, HR в NetForce Ukraine

Вне зависимости от того, кто у новичка PM или тимлид, процесс онбординга должен быть заранее спланирован, организован и распределён по ролям. Тимлид (а возможно PM), в отличие от HR, будет коммуницировать с новеньким по его конкретным задачам и целям. Ему важно быть открытым, рассказать больше о проекте, инструментах, а также быть готовым дать конструктивную обратную связь. 

Итог

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