Что такое онбординг?
Это система адаптации нового сотрудника (не важно какого грейда) в компании и на проекте. За свой 8 летний опыт в Тестировании ПО я поработал в разных компаниях, больших и маленьких, в стартапах и в корпорациях. Так вот везде система онбординга кардинально отличается, а где-то ее нет вовсе. Я расскажу о своем опыте и “лекарстве”, как привить систему адаптации у вас в коллективе.
До правильной и крутой системы онбординга, я поработал по системам:
- “Привет, вот твое рабочее место, вот пул задач - начинай разбираться, если что спрашивай”. Еще есть куча доки актуальной и не очень. Ты в процессе прохождения исп. срока просто сходу выполняешь все задачи спринта, участвуешь во всех активностях команды.
- “Так - здесь пул тест-кейсов, тут у нас автотесты крутятся, но что-то упало попробуй разобраться. Мы тебя не гоним, время есть, надо понять что сломалось”. Похожая система, как в первом случае - с места в карьер.
- “Привет. У нас классная система онбординга, все плавно и по этапам. У тебя будет ментор (правда не с твоего проекта), чек-лист к испытательному сроку”. Звучит классно, правда? Дьявол кроется в деталях. Да, ты получаешь ментора, но это человек из другой команды, там может быть даже стэк другой. Далее, ревью каждый месяц - проводит Head of QA, который совершенно не в теме того, что у тебя происходит на проекте. Однако он + еще сторонние qa дают тебе фидбэк. Система - полная дичь. Ты идешь к ментору с вопросами, а получаешь недовольство. Хэд тебя хвалит, а команда не довольна. Ради опыта - норм, но на практике система дырявая
- Система онбординга…кхм, какого онбординга? Вот твоя команда\команды, надо чтобы все ехало и крутилось - занимайся. По крупицам собираешь инфу, много общаешься, за испытательный срок делаешь больше, чем в других компаниях за полгода)). Челлендж на любителя
Фух. Вроде все расписал, были еще парочку, но они плюс-минус похожи друг на друга. Я начинал свой карьерный путь в 2014 году, может тогда еще не знали про классные практики и не было такого количества митапов. Но полтора года назад я испытал на себе и потом принял участие в апдейте самой удобной и прозрачной системе адаптации.
В чем соль?
Онбординг представляет из себя разделенный на временные периоды чек-лист. 1 неделя, 2 неделя, 3 неделя, месяц, второй и т.д. Например 1-неделя. Все идет от простого к сложному а-ля: получи доступ, поставь обязательный софт, получи наставника и т.д.
Чтобы избежать негативной обратной связи и улучшить эффективность новоиспеченного сотрудника, рассмотрим вариант с чек-листом и основными действиями в этот временной период.
Что нужно для составления чек-листа?
Ответ прост: погруженный сотрудник в проект и немного фантазии, а именно:
- Необходимо в первые дни ознакомить новенького с командой и проектом. Важно понимать, что переваривать информацию обо всех сотрудниках на проекте дано не каждому: кто чем занимается, за что отвечает и какой у него стек. Поэтому лучший способ, на мой взгляд, познакомить нового сотрудника с командой, помимо обычного знакомства - через задачи. Так он будет сам коммуницировать и в первые дни сможет приступить выполнять таски.
- Предоставление ментора. О менторе можно написать отдельную статью, кто он? Зачем он нужен? И кто может стать ментором? Это важный этап в онбординге сотрудника, ведь в первое время ментор - лицо компании/команды для новенького.
- Предоставление доступов. Бывает вариант, что доступы получаются “из поколения в поколение” без четкого алгоритма и знаний об их получении. Тут на помощь должен прийти ментор, который подскажет как их получить. Что делать, если уже все забыли как их получать и к кому обращаться новенькому за доступами? На стадии создания проекта необходимо закладывать базу знаний или жизненную карточку проекта, где будет подробная инструкция для всего необходимого чтобы приступить к работе.
- База знаний. Говоря о тестировании, то в данном документе должно быть минимальное руководство о том, как зайти в проект, какие ПО необходимо установить и как, где получить доступы и кто ответственный за них и т.д. Важно поддерживать этот документ в актуальном состоянии, ведь за период разработки может смениться не одна команда, и через несколько “поколений” никто уже не вспомнит о том, кто и за что был ответственный и вообще тот сотрудник уже уволился.
Итоги
Эффективная система адаптации на проекте выведет сотрудника на уровень производительности в кратчайшие сроки, в независимости от сложности проекта.
С помощью адаптационного чек-листа вы сможете сформировать во истину настоящую Dream team.