Сверстать всех наверх: онбординг новых сотрудников

Как адаптировать нового сотрудника компании с момента его выхода на работу и до осознания того, что он стал полноценным членом коллектива, понимающим местные культурные и профессиональные ценности? Об этом рассказал direction lead в Lamoda Александр Афенов в своем докладе на TeamLead Conf 2020. За десять лет стажа в IT он неоднократно собирал команды с нуля, и вывел для себя набор полезных в онбординге практик.

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

Что входит понятие онбординга?

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

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

Новый сотрудник вышел на работу

Как правило, онбординг нового сотрудника начинается с ожиданий, которые к нему предъявляют. 

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

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

На самом деле, это, конечно, фантазии. Возникает вопрос: кто покажет новичку, как все устроено и зачем все это делается? 

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

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

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

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

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

BIG BRO

В Lamoda набили много шишек в этом вопросе. Раньше в компании функционировала система, которая называлась BIG BRO. 

В ней могли принять участие люди, проработавшие в компании более полугода. Предполагалось, что они будут добавляться в пул «больших братьев/сестер». И когда появится новый сотрудник, в первый же день его подхватит кто-то из участников системы, выпьет с ним кофе с тортиком и расскажет о базовых вещах. 

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

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

Да и что можно узнать от человека из другого департамента, кроме совсем уж базовых вещей, таких как местоположение туалета и рассказа о том, где можно получить зарплатную карту?

Buddy внутри команды/подразделения

По инициативе IT-рекрутмента и HR в Lamoda запустили новую систему.

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

Buddy готов отвечать на все возникающие вопросы, регулярно встречаться со своим подопечным, обедать с ним: то есть он старается быть полезным максимально неформально. Время, потраченное на онбординг, фиксируется и учитывается в capacity спринта. 

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

В итоге участвующие в онбординге сотрудники общаются на регулярной основе и стараются своевременно подхватывать возникающие проблемы.

А у самого buddy существует не только идеологическая мотивация (он может вырастить нового классного члена команды!), но и постепенно появляются разные «плюшки», финансовые (участие в программе учитывается при performance review) и не только.

С чего начать?

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

#SYMFONY #PHP7

#AGILE #GIT #KAFKA

#SOLID #POSTGRESQL

#tlConf. JS

Но есть там и информация о том, чем занимается компания.

Аспект #1: нехватка знаний о бизнесе

Кто представляет, например, чем занимается Lamoda? Раньше все доклады спикеры из этой компании начинали с рассказа о том, что это интернет-магазин, сервис-провайдер и т.д. Сейчас Lamoda довольно известна в IT индустрии. Но детали бизнеса, его цели, боли и задачи, успехи и провалы совершенно не очевидны. Нюансы того, что нужно автоматизировать, новый сотрудник на старте не знает. Это первый момент, который хочется пофиксить.

Способы решения

induction

В Lamoda в первые две недели работы сотрудника приглашают на большую встречу, которая называется induction. Раньше такие встречи занимали целый день, но в настоящее время их сделали более эффективными. На них приходят все новые сотрудники, независимо от того, в какой департамент они вошли — IT, бухгалтерия, data analytics, и так далее.

 Цель встречи: объяснить, что делает бизнес и зачем + обрисовать цели и орг. структуру.

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

Интересно, что вопрос «кто все эти люди?» зачастую актуален и для матерых сотрудников.

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

После общей встречи, новый сотрудник начинает потихоньку разбираться в процессах, проходящих внутри компании. У него меняется характер вопросов: хочется больше конкретики о том, что он будет делать, и чем дышит конкретный IT.

IT onboarding

Следующий этап онбординга — встреча, на которой можно узнать про про специфику своей отрасли. Она меньше по масштабу, потому что туда приходят только те, кто устроился именно в IT. Это могут быть PM, продакты, QA, разработчики. В общем, все-все-все. 

Цель встречи: рассказать про технический стек, команды, процессы, культуру и так далее.

Там идет речь о деталях в IT. Именно на этой встрече новый сотрудник узнает о том, каким образом IT работает с точки зрения процессов, железок, к кому и по каким вопросам можно обращаться, какова история департамента (это бывает важно), нюансы, связанные с разработкой и инфраструктурой. Обычно подобная встреча занимает 40-60 минут, за которые стараются максимально подробно осветить все вышеперечисленные вопросы.

it gathering

Следующий этап: встреча, ориентированная не только на новых сотрудников, которая называется it gathering.

Ее цель: конкретика + появление пока что абстрактного чувства загадочной причастности.

Для этого собирается все IT — по желанию, это происходит офлайн, в конкретном помещении, или онлайн (все подключаются к трансляции). Идея встречи в том, чтобы раз в квартал рассказать IT о том, что произошло в компании за это время: что получилось, что запустили, что поменялось организационно и в плане техники, и каков план на следующий квартал.

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

Везут на склад

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

Также у человека есть возможность съездить на фотостудию и посмотреть, каким образом генерируется контент для сайта, как он обрабатывается и заливается. Главное правило — не отвлекать моделей.

Торговый представитель

Еще один интересный момент, который регулярно практикуется — это возможность побыть торговым представителем. Внутри компании есть поговорка: «Не курьер и не водитель, а торговый представитель». И можно побыть именно таким человеком: сесть в машину Lamoda и, вместе с водителем, съездить в квартиру покупателя, передать ему вещи, принять оплату и т.д. Это важная составляющая бизнеса, к автоматизации которой так или иначе прикладывают руку большинство сотрудников IT. Поэтому очень полезно посмотреть на это и потрогать руками.

Аспект #2: но когда, Карл?

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

Дело в том, что как минимум на момент испытательного срока, если говорить о разработчиках и QA, всерьез можно рассчитывать только на половину рабочего времени.

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

Q&A every day

Есть еще одна интересная практика, которая помогает хорошо ускорить и погрузить нового сотрудника в процессы, бизнес и технику. 

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

Тимлиду пришла в голову идея перейти с этим сотрудником на специфический формат встреч, который оправдал себя.

Особенности такого формата встреч в том, что они:

• Проводятся в начале дня;

• Не смешиваются с другими темами;

• Не заменяют 1-to-1.

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

Регулярность – источник благодати

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

Многие забывают, что встречи один на один не обязательно должны проходить так: тимлид сел, выгрузил человеку обратную связь, рассказал новости и ушел. Будет здорово, если эти встречи станут работать в обе стороны, потому что для тимлида приход нового человека — это свежий взгляд на происходящее в команде. 

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

Допустим, однажды новый QA сказал, что в компании существует совершенно бесполезная оценка в часах, и можно попробовать использовать story points. На своей прошлой работе он был scrum-мастером, и предложил рассказать, как лучше всего наладить процесс.

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

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

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

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

Тем временем 

С человеком происходят все эти прекрасные активности: у него есть buddy, регулярные встречи personal meeting и так далее. Но у него появляются другие важные вопросы: 

• Чего от меня ждут?

• Как быстро я должен стать шерстяным волчарой?

• Каковы условия прохождения испытательного срока?

• Кто все эти люди?

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

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

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

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

Трекинг прогресса

Это простейший чек-лист, который ведется в Confluence. Можно вести его где угодно, лишь бы он не потерялся. Идея в том, что на старте в чек-листе перечислено все, что нужно освоить человеку в процессе онбординга.  В том числе, в трекинге указано:

• Что нужно освоить;

• В каких активностях поучаствовать;

• Какие доступы получить;

• Какие задачи необходимо выполнить за испытательный срок.

Это позволит судить о том, насколько человек справляется и насколько он уместен на своем грейде.

На какой период рассчитан список?

Этот срок может быть любым. ¯\_(ツ)_/¯

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

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

Здорово, если задачи, которые ставятся новому сотруднику на испытательный срок, можно охарактеризовать примерно так:

• В задаче понятен DOD (Definition of Done);

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

• Не будет лежать мертвым грузом;

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

• Выполнима.

Часто задачи, которые ставят перед новыми сотрудниками, оказываются недописанными, не прошедшими банальную техническую аналитику, и шансов на их успешное выполнение немного или нет вообще. 

Был такой кейс: хотели обновить проект на первом Zend до PHP 7.4, а они не совместимы. 

Задача должна быть хорошо подготовлена и не заблокирована другими командами. Если человек начал ее делать, у него должен быть шанс на ее завершение и доведения до production.

Помните про обязанности?

Еще один интересный момент по поводу подбора задач на испытательный срок, который здорово  выстрелил в Lamoda. Пришел сеньор, который начал задавать кучу вопросов, показал, что у него все хорошо с софт-скиллами. Стало очевидно, что он очень хорош. Исходя из того, как он общался, как он сделал свои самые первые задачи, казалось, что ему можно доверить больше и дать то, что обычно поручают более опытным сотрудникам, давно работающим в компании. В этом случае это был техлидство небольшого, но важного бизнесового проекта.

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

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

О таких кейсах не стоит забывать, нужно  внимательно смотреть на людей и кастомизировать задачи. 

Финал испытательного срока

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

Сроки: как успеть?

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

Возвращаемся к истории с чек-листом. Этот список регулярно актуализируется на каждой  1-to-1 встрече раз в неделю-две: в чек-листе отмечаются каждый новый шаг, полученные доступы, выполненные задачи. Они фиксируются с датой, когда произошли апдейты. В итоге у новых сотрудников есть ощущение постоянного движения вперед, а в компании есть понимание того, с какой скоростью онбордятся люди, и все ли у них хорошо.

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

Полезно не забывать про саппорт

Во время испытательного срока не стоит забывать про саппорт. Раньше в Lamoda совершали колоссальную ошибку: никогда не давали саппорт людям, которые не отработали испытательный срок. Это приводило к тому, что у человека 11 февраля закончился испытательный срок, и 12 он услышал: «Кстати, еще у нас есть саппорт! Держи!». 

То есть весь испытательный срок новичок не видел, что такая активность есть в его должностных обязанностях, он с ней не сталкивался, а сразу после его работа стала кардинально отличаться от того, что происходило раньше.Это не очень хорошая практика.

Но главное, что когда новый сотрудник берет простые кейсы из саппорта (а он есть во всех production-системах) на испытательном сроке, он лучше осваивает работу системы, смотрит на нее с разных сторон.

Side bonus: проверка документации на прочность

Еще один забавный бонус от испытательного срока: взгляд со стороны на то, что можно понять по той документации, которая у вас есть. Зачастую, ничего или совсем немного. 

Один из сотрудников Lamoda после того, как отработал свой испытательный срок, написал классную статью «Что я бы рассказал самому себе о проекте три месяца назад», и уже из одного только названия можно было сделать вывод, что в процессе онбординга хватало дыр.

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

Итоги

Что должно произойти для того, чтобы понять, подходит ли новичок компании, и как сделать, чтобы его адаптация была как можно более мягкой?

Чтобы это произошло, новый сотрудник должен пройти следующие этапы: 

• Понять, что и зачем делается в компании, узнать о бизнесе, планах и целях, приобрести правильную мотивацию;

• Посмотреть на заказчика, и получить задачу, которая действительно кому-то нужна;

• Усвоить основы культуры команды и компании;

• Пощупать продукт и посмотреть, как он работает;

• Начать выполнять задачи, освоив основные инструменты, технику и процессы; 

• Выполнить нужные задачи;

• Научиться доводить фичи до production;

• Показать свои сильные и слабые стороны, получить фидбэк от бизнеса, команды и тимлида;

• Получить поддержку от buddy, регулярно участвовать во встречах;

• Сделать выводы о том, насколько ему комфортно, подходят ли ему проект и коллектив;

• Принять решение о том, хочет ли остаться и быть частью команды,

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

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