Все идет по плану: лайфхаки загруженного куратора для эффективного онбординга новичка
Как адаптировать новичка и не выгореть дотла?
Привет! Меня зовут Дарья, я тимлид группы тестирования отдела разработки биллинговой системы в компании Bercut, которая входит в группу компаний Ростелеком. За семь лет работы в сфере тестирования я и сама проходила планы адаптаций, и многократно занималась курированием новичков. При этом всегда сталкивалась с одной и той же проблемой: неловко по 100 раз на дню отвлекать куратора вопросами, но еще хуже — быть тем самым куратором, которого отвлекают по 100 раз на дню!
В этой публикации я поделюсь опытом выстраивания процесса адаптации новых сотрудников у себя в команде. Расскажу об этапах построения процесса адаптации, дам полезные чек-листы и подведу итоги нашей работы.
Bercut разрабатывает и развивает IT-решения для операторов цифровых услуг и мобильных сервисов. Решения Bercut позволили создать и улучшить сотни продуктов для Tele2 и других партнеров с общей абонентской базой более 310 млн абонентов. И когда новичок приходит в Bercut, он сталкивается с гигантским количеством информации, которую нужно изучить и начать применять. Помимо общих знаний по тестированию, требуется знание биллинговой системы, которая строилась десятилетиями.
Переход на удаленный формат работы в 2020 году побудил нас искать пути выстраивания процесса адаптации в команде. Ведь в офисе всегда видно, чем занят новый сотрудник: проще уточнить, как проходит обучение, отвлечься и ответить на вопросы. А на удаленке коммуникация стала осуществляться через конференцсвязь и чаты. В мессенджерах ответы не получалось давать быстро, а конф-коллы накладывались друг на друга, так как их количество возросло в несколько раз. Процесс адаптации нужно было срочно чинить и улучшать, а значит — все структурировать, и далее зафиксировать!
Во время создания нового формата адаптации сотрудников были выделены основные задачи, которые нужно было решить в первую очередь:
1. Выстроить процесс назначения куратора.
2. Составить полноценный план адаптации.
3. Структурировать важную для новичка информацию.
Вроде как это — база, ничего необычного и нового нет, но! Ранее все происходило в формате живых встреч, постановка задач была устной и неформальной, а теперь стало необходимым подстроить процесс под новые условия работы. Далее подробнее раскрою каждый пункт из вышеперечисленных.
Первое — куратор.
У любого новичка должен быть свой закрепленный куратор, к которому он может обратиться по любому вопросу. Куратор помогает сотруднику влиться в коллектив, транслируя особенности работы в команде. Это необходимо, потому что на этапах адаптации взаимодействие с командой минимальное, особенно при работе в режиме удаленки.
В первый день адаптации новичка куратору важно проговорить, какие способы связи будут удобны для дальнейшего взаимодействия, договориться о частоте и времени конф-коллов. Например, у нас в команде между куратором и новичком есть договоренность о созвонах по полчаса утром, на которых мы обсуждаем вопросы и сложности, возникшие при прохождении адаптации. В течение дня новичок отвлекает куратора только стоповыми проблемами.
Второе — план адаптации.
В первый день работы новичка мы должны выдать ему план адаптации. Хороший план и четкое понимание новичком того, что от него ожидают и за какой срок — половина успеха. План должен быть последовательным и рассчитанным на определенный период; его удобно составлять в виде таблицы (см. Таблица 1).
Таблица 1
В плане необходимо прописать задачи, распределенные на период адаптации. Задачи — конкретные, с измеримым результатом, достижимые, реалистичные, привязанные к определенной дате исполнения (мы же все любим SMART, да?).
Ответы на вопросы о настройке рабочего окружения, необходимых доступах, а также информацию для погружения в наш продукт — всё это мы также включаем в план адаптации.
Пример основных пунктов из нашего шаблона плана адаптации, с конкретикой/задачами-подзадачами:
1. Запрос доступов, установка необходимых программ.
1.1. Список доступов.
Пояснение: тут стоить прописать все доступы (с ссылками на ресурсы), которые должен запросить сотрудник в первый день. Указать, где и как запрашивать доступ. Можно описать и регламент того, какой процесс выдачи доступов принят в команде/компании, обозначить ресурс, где создаются заявки и их формат, контакты IT-отдела;
1.2. Установка ПО.
Пояснение: в этом подпункте прописываем всё программное обеспечение, требуемое для настройки рабочего окружения. Обязательно указываем версии и ссылки на ресурсы для скачивания необходимого ПО. Хорошим бонусом будет инструкция или ссылка на гайд по установке.
2. Изучение общей информации о процессах в компании.
2.1. Сайт компании, информация по трудовой дисциплине, карта процессов, должностная инструкция, регламент по реакции на инциденты и др.;
Пояснение: приводим список общих документов компании, указываем ссылки, где эти документы найти.
3. Обязательные для прохождения курсы или мероприятия для новичков (если таковые есть).
3.1. Митапы, welcome-встречи и др.
Пояснение: указать мероприятия, курсы, необходимые для изучения и посещения, прописать срок/дату и ФИО организатора, если этим занимается не сам куратор.
4. Знакомство с продуктом.
4.1. Выделенный этап изучения продукта.
Пояснение: если продукт большой/сложный и требуется много времени на его изучение, формируем список задач и группируем их в блоки. По каждой задаче детализировано описываем шаги и ожидаемый результат, срок выполнения. Также не лишним будет добавить, где искать информацию, необходимую для решения задачи.
Например, этап «Первичное создание элементов системы Bercut» — в рамках данного этапа выделена задача, условно, «Создание птички» (см. Таблица 2). Для решения этой задачи необходимо изучить специальный гайд, выполнить вход в приложение, провести ряд настроек характеристик будущей птички и, наконец, создать саму птичку. Если нет гайда, то в помощь новичку стоит описать минимальные настройки. Если нет времени для полноценного описания со скриншотами и примерами, можно записать видео, как мы объясняем настройку одному из новичков, и далее распространять видео на других новичков.
Таблица 2
Третье — собрать все важные источники информации на одной странице (полезно не только для новичков, но и всей команде). По сути, это единый скоуп ссылок, версий устанавливаемых ПО, сборник самых важных регламентов, которые могут быть разбросаны по разным источникам. Чек-лист того, что стоит организовать таким образом:
1. Внутренний сайт компании;
2. Ссылка на веб-версию корпоративной почты;
3. Настройка подключения VPN;
4. Регламент запроса доступа к ресурсам;
5. Список обязательных доступов и ссылки на эти ресурсы, например, доступ в GIT с ссылкой;
6. Программное обеспечение для настройки рабочего окружения с указанием версий и ссылками для скачивания;
7. Список проблем, часто возникающих при установке ПО, лайфхаки по установке;
8. Ссылки на тестовые и релизные сборки продуктов;
9. Список ссылок на все регламенты, принятые в команде. Конечно, если регламентов нет, то стоит провести работу по их созданию. Вот пример полезных регламентов для команды тестирования: регламент по работе с заявками, регламент по оформлению заявок, регламент по описанию тест-кейсов в системе хранения методик тестирования, регламент проверки проекта перед отгрузкой релиза;
10. Ссылка на базу знаний команды;
11. Ссылки на доски с задачами, например, Kanban, Agile доска в Jira;
12. Полезные фильтры для поиска задач, например в Jira;
13. Ссылка на планы отгрузки релизов или таблицу с версиями систем;
14. Ссылка на систему учета трудозатрат и регламент по их учету и внесению;
15. Ссылка на источник хранения документации, на гайды настроек, технические проекты и пр.;
16. Ссылка на источник хранения методик тестирования, отчетов о тестировании, тест-планов;
17. Ссылка на систему планирования отпуска;
18. Список каналов коммуникаций, принятых в команде, перечень важных чатов;
19. Контакты представителей IT-отдела на случай, если возникнут вопросы с доступами, удаленным подключением и др.
Важно не оставлять собранную информацию в первоначальном виде: так как всегда будут возникать новые вопросы, указанные пункты придется уточнять, при выпуске новых версий ПО — заменять версии, добавлять новые регламенты. Собранная информация будет полезной, если держать ее в актуальном виде, поэтому периодически её нужно просматривать и редактировать.
Что мы получили, проработав все озвученные пункты у себя в команде?
Обновление процессов заняло у нас меньше недели. Первые новички, проходившие план адаптации, помогали нам отлаживать процесс — находились вопросы, которые мы забыли отразить, а также неточные формулировки в постановке задач.
Но вот что мы заметили сразу: снизилось время настройки рабочего окружения новичком, уменьшилось количество проблем и вопросов из-за отсутствия доступов к требуемым ресурсам. Теперь понятно, чем занимается сотрудник в конкретный день и какое время требуется для выполнения плана адаптации. Новичку стали ясны задачи и требования, стоящие перед ним во время адаптационного периода. Итог: меньше отвлечений на базовые вопросы куратору → больше времени на разбор сложных вопросов о продукте.
После завершения адаптации мы стали собирать обратную связь от новых сотрудников. Так мы замечаем нюансы, на которые раньше не обращали внимание, и продолжаем работать над развитием процесса адаптации в команде. Например, получив такую обратную связь, мы поняли, что необходимо добавить небольшой тест для проверки знаний по пройденному плану адаптации. А сейчас думаем, как эффективнее погружать новичка в автоматизацию тестирования, так как приходится работать с уже готовой тестовой обвязкой, сформированными стандартами разработки автотестов.
Процесс адаптации важен для погружения новых сотрудников в рабочую среду команды. Делаем сами и рекомендуем вам — постоянно его пересматривать, развивать и совершенствовать.
