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

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

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

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

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

1. Выстроить процесс назначения куратора.

2. Составить полноценный план адаптации.

3. Структурировать важную для новичка информацию.

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

Первое – куратор.

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

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

Второе — план адаптации.

В первый день работы новичка мы должны выдать ему план адаптации. Хороший план и четкое понимание новичком того, что от него ожидают и за какой срок — половина успеха. План должен быть последовательным и рассчитанным на определенный период; его удобно составлять в виде таблицы (см. Таблица 1).

В плане необходимо прописать задачи, распределенные на период адаптации. Задачи – конкретные, с измеримым результатом, достижимые, реалистичные, привязанные к определенной дате исполнения (мы же все любим SMART, да?).

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

Пример основных пунктов из нашего шаблона плана адаптации, с конкретикой/задачами-подзадачами:  

1. Запрос доступов, установка необходимых программ.

1.1. Список доступов.

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

1.2. Установка ПО.

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

2. Изучение общей информации о процессах в компании.

2.1. Сайт компании, информация по трудовой дисциплине, карта процессов, должностная инструкция, регламент по реакции на инциденты и др.;

Пояснение: приводим список общих документов компании, указываем ссылки, где эти документы найти.

3. Обязательные для прохождения курсы или мероприятия для новичков (если таковые есть).

3.1. Митапы, welcome-встречи и др.

Пояснение: указать мероприятия, курсы, необходимые для изучения и посещения, прописать срок/дату и ФИО организатора, если этим занимается не сам куратор.

4. Знакомство с продуктом.

4.1. Выделенный этап изучения продукта.

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

Например, этап «Первичное создание элементов системы Bercut» - в рамках данного этапа выделена задача, условно, «Создание птички» (см. Таблица 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-отдела на случай, если возникнут вопросы с доступами, удаленным подключением и др.

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

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

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

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

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

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