Ви, напевно, знаєте про “синдром новачка”. Це відчуття нищівної тривоги, яке турбує співробітника на новому місці роботи. Занепокоєння може бути викликане чим завгодно: від нових знайомств і до нових обов’язків. Такі проблеми виникають не тільки в офісних співробітників, а й у тих, хто працює віддалено.
Щоб із цим боротися, фахівці розробили процес адаптації. Така практика існує з 1970-х років. При цьому, за даними Harvard Business Review, 22% компаній взагалі не мають процесів адаптації та онбордингу. Понад три чверті з тих, у кого ці методи є, вони не налагоджені належним чином. Результат: компанії втрачають ресурси (час, фінанси), допоки новий співробітник намагається зрозуміти, які перед ним стоять завдання, до кого звертатися з різних питань.
З чого почати процес адаптації нового співробітника в офісі та віддалено? Чи відрізняється онбординг DevOps-інженерів та людей з інших галузей? Про це говорили зі спеціалістами компанії NetForce Ukraine: Павло Завада — CEO, Олександр Барахтянський — CTO та Єва Фурсова — HR.
ТОП помилок: як не потрібно проводити процес адаптації
- Довго та детально. Не рідкість, коли у великих проєктах процес онбордингу триває більше як тиждень, і лише після цього розпочинається етап відкриття доступів. У цей час розповідають про відділи та посади співробітників, із більшою частиною з яких DevOps-спеціаліст не перетинатиметься в роботі. Від слова зовсім.
Щоб онбординг тривав 2 тижні, для цього повинні бути вагомі підстави.
Павло Завада, CEO в NetForce Ukraine
Квізи скрізь. Ідея з короткими тестами після важливих тем із корпоративної Wiki — хороша. Так роботодавець зможе зрозуміти, чи засвоїв новий співробітник важливу інформацію. Але це не повинно переростати в опитувальник на 10 сторінок після кожної другорядної теми.
- Відсутність наставника. Загалом не важливо, хто стане наставником для нового спеціаліста: HR, PM або інший колега за проєктом. Головне, щоби він був.
- Відразу в роботу. Навіть самому ТОП-овому спеціалісту потрібен час на адаптацію. Щонайменше, щоб отримати відповіді на організаційні питання. Оптимальний варіант — спеціально відведений час вивчення документації по проєкту. Одразу в роботу — не найкращий варіант.
Я працював у компанії, де онбординг триває 2 тижні. У перший: проводять вебінари про організацію (її структуру, продукти). У другий: надають доступи та проєктну документацію. У великих компаніях це тривалий, але виправданий процес.
Олександр Барахтянський, CTO у NetForce Ukraine
Покрокова інструкція щодо адаптації ІТ-фахівця
Крок 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, буде комунікувати з новачком про його конкретні завдання та цілі. Йому важливо бути відкритим, розповісти більше про проєкт, інструменти, а також бути готовим дати конструктивний зворотний зв’язок.
Підсумок
Якщо ви хочете використовувати свої ресурси повною мірою і працювати з кращими талантами, що є на ринку, вам потрібен налагоджений процес адаптації. Тільки тоді можна знизити плинність кадрів та побачити синергію роботи співробітників. І хоча немає загальної системи адаптації, яка працювала б у всіх випадках, ви можете використовувати ці рекомендації, щоб створити свою власну модель.