Что такое онбординг? Это система адаптации нового сотрудника (не важно какого грейда) в компании и на проекте. За свой 8 летний опыт в Тестировании ПО я поработал в разных компаниях, больших и маленьких, в стартапах и в корпорациях. Так вот везде система онбординга кардинально отличается, а где-то ее нет вовсе. Я расскажу о своем опыте и «лекарстве», как привить систему адаптации у вас в коллективе.

До правильной и крутой системы онбординга, я поработал по системам:

• «Привет, вот твое рабочее место, вот пул задач — начинай разбираться, если что спрашивай». Еще есть куча доки актуальной и не очень. Ты в процессе прохождения исп. срока просто сходу выполняешь все задачи спринта, участвуешь во всех активностях команды.

• «Так — здесь пул тест-кейсов, тут у нас автотесты крутятся, но что-то упало попробуй разобраться. Мы тебя не гоним, время есть, надо понять что сломалось». Похожая система, как в первом случае - с места в карьер.

• «Привет. У нас классная система онбординга, все плавно и по этапам. У тебя будет ментор (правда не с твоего проекта), чек-лист к испытательному сроку». Звучит классно, правда? Дьявол кроется в деталях. Да, ты получаешь ментора, но это человек из другой команды, там может быть даже стэк другой. Далее, ревью каждый месяц — проводит Head of QA, который совершенно не в теме того, что у тебя происходит на проекте. Однако он + еще сторонние qa дают тебе фидбэк. Система - полная дичь. Ты идешь к ментору с вопросами, а получаешь недовольство. Хэд тебя хвалит, а команда не довольна. Ради опыта - норм, но на практике система дырявая

• Система онбординга…кхм, какого онбординга? Вот твоя команда\команды, надо чтобы все ехало и крутилось — занимайся. По крупицам собираешь инфу, много общаешься, за испытательный срок делаешь больше, чем в других компаниях за полгода)). Челлендж на любителя

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

В чем соль?

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

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

Что нужно для составления чек-листа? Ответ прост: погруженный сотрудник в проект и немного фантазии, а именно:

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

2. Предоставление ментора. О менторе можно написать отдельную статью, кто он? Зачем он нужен? И кто может стать ментором? Это важный этап в онбординге сотрудника, ведь в первое время ментор — лицо компании / команды для новенького. 

3. Предоставление доступов. Бывает вариант, что доступы получаются «из поколения в поколение» без четкого алгоритма и знаний об их получении. Тут на помощь должен прийти ментор, который подскажет как их получить. Что делать, если уже все забыли как их получать и к кому обращаться новенькому за доступами? На стадии создания проекта необходимо закладывать базу знаний или жизненную карточку проекта, где будет подробная инструкция для всего необходимого чтобы приступить к работе.

4. База знаний. Говоря о тестировании, то в данном документе должно быть минимальное руководство о том, как зайти в проект, какие ПО необходимо установить и как, где получить доступы и кто ответственный за них и т.д. Важно поддерживать этот документ в актуальном состоянии, ведь за период разработки может смениться не одна команда, и через несколько «поколений» никто уже не вспомнит о том, кто и за что был ответственный и вообще тот сотрудник уже уволился.

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

Статья разработана совместно с @Darksol89