Есть несколько типов онбординга: на уровне компании, когда новичку все показывают и рассказывают про ее деятельность, особенности, структуру; на уровне HR, который может еще делать акцент на впечатление от работы; и на уровне команды. О последнем мы и поговорим, особенно о том, как поменялись требования к онбордингу при удаленной работе.
Работа до удаленки и после.
Какие есть варианты онбординга?
Оговорюсь, в этой статье я не делал акцент на разделении онбординга сеньора или джуниора. Эти процессы отличаются фокусом на технических деталях и контроле работы, но одинаково важны.
Разработчик — социальное существо и, скорее всего, интроверт. Опытный разработчик может иметь хорошие коммуникативные навыки или даже быть экстравертом. Но все равно лучше немного подтолкнуть его к общению.
Представьте команде нового коллегу, уделите больше времени неофициальной части, рассказав о хобби или другие интересные факты о новичке. Если человек замкнут и не готов делиться своими интересами, коснитесь ярких моментов с прошлой работы. Вам как руководителю он уже, скорее всего, рассказал о них на собеседовании. Это важно, в обычной жизни в офисе новичок вполне мог бы сам рассказать это коллегам в перерывах или за ланчем, при удаленной работе это сделать сложнее.
Независимо от того, насколько у вас большая компания, покажите проект с которым будет работать новичок. Сделайте акцент на то, кто какими задачами сейчас занимается. Если проект большой, а вы предложите новичку самому посмотреть и задать вопросы, он может уйти изучать неактуальные разделы или просто закопаться. Не говоря уже о том, что если у вас микросервисы, несколько мобильных приложений и сайт, новичок просто не сможет должным образом расставить приоритеты.
Нам хотелось бы оптимально использовать время и мы создаем длинные инструкции, которые отвечают на кучу вопросов. Так, может быть, можно отправить новичка “Read The Fancy Manual”? Сейчас, когда у всех дефицит социальных контактов, лучше потратить чуть больше времени на живое общение.
Организуйте встречу с бизнесом. Когда сидишь в офисе и прибегает продакт в панике, мол, не работает фото-галерея, новичок сразу поймет, что это важная/ключевая часть проекта. Без лицезрения горящего леса рядом с вами, можно забыть, что он горит. Пусть бизнес обозначит, а потом напоминает, что именно важно для развития проекта.
На удаленке сотрудники работают продуктивнее, поскольку их никто не отвлекает. Вынужденную удаленную работу пока вынесем за скобки. Но этот процесс идет стабильно и хорошо, пока у разработчика есть все нужные данные. Если данных нет, их нужно где-то получить. И тут новичок может потерять очень много времени на их поиск, потому что не сразу сориентируется, у кого их можно попросить. И вот обмен знанием, у кого спросить и где что посмотреть — это существенный простор для оптимизации работы новичка.
Постепенно новый сотрудник познакомится со всеми коллегами. И “постепенно” здесь ключевое слово. Было бы здорово иметь список в конфлюенсе с указанием, к кому и в каком случае можно обратиться. Но не стоит вываливать список из 20 имен новому сотруднику с кратким пояснением, кто и зачем ему нужен, и надеяться, что этого будет достаточно.
Я рекомендую подход напарника (buddy), его хорошо описали в докладе Lamoda. Buddy — это отдельно выделенный сотрудник команды, который будет отвечать на все вопросы по погружению в компанию. Напарник подскажет, к кому обратиться по тому или иному вопросу — не в какой отдел, а к кому конкретно. Скажет, есть ли похожий функционал или микросервис. Поможет разобраться с принятым в компании стилем общения и поведения.
При работе с продуктом возникает куча всплывающих окон и неожиданных для новичка моментов, тут же он может сразу задать вопрос и понять, что это и зачем было сделано. Даже если ментор не знает, его опыта в компании должно хватать, чтобы знать у кого спросить.
На удаленке нельзя пройти мимо и спросить как дела. Вот этот момент должен взять на себя коллега. Постоянное общение с ним компенсирует эту проблему. Если этого человека нет, его роль стандартно ложится на руководителя, который на удаленной работе загружен ничуть не меньше и у него нет времени оперативно реагировать. Выбирая таких “buddy” нужно учитывать коммуникативные навыки и желание самого человека — кто-то хочет спокойно кодить, и не стоит его в этом винить.
Уходите от общих вопросов к конкретным. На стандартный вопрос “есть ли проблемы?” вы, скорее всего, внятного ответа не получите. Стоит спросить справился ли человек с конкретным заданием, все ли ему там понятно. В этом случае вероятность качественной обратной связи выше, он может вспомнить (и не постесняется сказать), что у него был вопрос по этой теме.
Проведите технический брифинг по проекту. Разбейте его на несколько встреч. Во время первой расскажите общие моменты. На второй — про взаимодействие с другими отделами. На третьей встрече познакомьте с инфраструктурой. Еще раз проверьте документацию, обновите ее после сотрудника, когда там найдутся недоработки. Когда, а не если! Заранее подберите задачи, которые не требуют удаленного согласования. В идеале попробуйте сами набросать эту задачу и проверьте актуальность описания.
Рассказывая о проекте, вы вводите множество терминов, которые для новичка ничего не значат. Например, “Катни госю на рц”. Когда вводите новые термины, давайте новичку пояснение и дозируйте такую информацию. Если за одну встречу рассказать всю инфраструктуру сервиса, новичок скорее всего забудет почти все те понятия, с которыми не столкнулся в течение ближайших пары дней.
Старайтесь первое время давать парные задачи. Даже если задачу может сделать один человек, лучше ее разбить на подзадачи, чтобы была кооперация. Возьмем, к примеру, микросервис. Допустим, новичок делает слой общения с DB, а более опытный коллега общий каркас и общение по API. Дальше новичок напишет бизнес-логику, и задача уйдет в тестирование как цельный микросервис.
Такие задачи помогают быстрее встроиться в ритм команды, т.к. сидящий на другом конце Skype (Zoom, Hangout) коллега в случае проблем подсказывает и позволяет новичку почувствовать, что он не один. Также это оберегает нового сотрудника от ненужной переделки половины кодовой базы, если вдруг он: 1) неверно понял задачу, 2) хотел показать свои амбиции и убил на это 48 часов без сна.
Удаленка подразумевает повышенное чувство неопределенности. Качественно бороться с ним помогает план. Не девиз, все идет по плану, а сформулированный план погружения сотрудника в детали проекта. А еще план развития сотрудника. И конечно, четко описанные цели сотрудника на испытательном сроке и ожидания от новичка. Они должны быть привязаны не к задачам спринта, а к общим моментам, которые важны для компании на любом этапе разработке. Например:
Последний пример важен, тут фиксируется встреча для получения обратной связи, о чем я уже много сказал в социальной части. Ваш список будет отличаться в зависимости от приоритета команды и квалификации сотрудника. Можно прям отдельно выделить общую часть и дополнительные для junior, middle и front/back.
Наличие формализованного списка дел и требований на испытательный срок сэкономит нервы вам и вашему новому коллеге. Он позволит сотруднику показать себя с разных сторон за достаточно короткий срок, равный испытательному, и окунуться в разные области вашей работы. Если этого не сделать и дать новичку, например, мирно пилить один модуль, за 3 месяца он идеально его сделает, но может оказаться неэффективен во множестве других моментов.
У человека не должно остаться впечатление о команде, как о наборе пикселей на экране. Должно быть понимание, что происходит вокруг команды. Понимание проекта должно быть привязано к конкретным фичам, которые делали живые люди, с которыми он успел поработать и пообщаться.
У нас приняты встречи с фидбеком от других членов команды, где они делятся с руководителем опытом взаимодействия с новичком и общими впечатлениями. Для продуктивности таких встреч, более чем у половины сотрудников уже должен быть опыт общения с новым коллегой. Если они утверждают, что “работу работал, мне не мешал” то процесс онбординга стоит доработать.
Какие есть варианты онбординга?
- Бросили в воду, выплыл — наш человек, не смог — сам виноват, надо было лучше стараться и учиться плавать заранее;
- Вот задача, вот инструменты остальное походу поймешь;
- Настоящий онбординг. В первых случаях его на самом деле не было. Новичком занимаются и аккуратно погружают в устройство компании и команды.
Оговорюсь, в этой статье я не делал акцент на разделении онбординга сеньора или джуниора. Эти процессы отличаются фокусом на технических деталях и контроле работы, но одинаково важны.
Социальный аспект
Разработчик — социальное существо и, скорее всего, интроверт. Опытный разработчик может иметь хорошие коммуникативные навыки или даже быть экстравертом. Но все равно лучше немного подтолкнуть его к общению.
Знакомство с командой
Представьте команде нового коллегу, уделите больше времени неофициальной части, рассказав о хобби или другие интересные факты о новичке. Если человек замкнут и не готов делиться своими интересами, коснитесь ярких моментов с прошлой работы. Вам как руководителю он уже, скорее всего, рассказал о них на собеседовании. Это важно, в обычной жизни в офисе новичок вполне мог бы сам рассказать это коллегам в перерывах или за ланчем, при удаленной работе это сделать сложнее.
Независимо от того, насколько у вас большая компания, покажите проект с которым будет работать новичок. Сделайте акцент на то, кто какими задачами сейчас занимается. Если проект большой, а вы предложите новичку самому посмотреть и задать вопросы, он может уйти изучать неактуальные разделы или просто закопаться. Не говоря уже о том, что если у вас микросервисы, несколько мобильных приложений и сайт, новичок просто не сможет должным образом расставить приоритеты.
Нам хотелось бы оптимально использовать время и мы создаем длинные инструкции, которые отвечают на кучу вопросов. Так, может быть, можно отправить новичка “Read The Fancy Manual”? Сейчас, когда у всех дефицит социальных контактов, лучше потратить чуть больше времени на живое общение.
Организуйте встречу с бизнесом. Когда сидишь в офисе и прибегает продакт в панике, мол, не работает фото-галерея, новичок сразу поймет, что это важная/ключевая часть проекта. Без лицезрения горящего леса рядом с вами, можно забыть, что он горит. Пусть бизнес обозначит, а потом напоминает, что именно важно для развития проекта.
На удаленке сотрудники работают продуктивнее, поскольку их никто не отвлекает. Вынужденную удаленную работу пока вынесем за скобки. Но этот процесс идет стабильно и хорошо, пока у разработчика есть все нужные данные. Если данных нет, их нужно где-то получить. И тут новичок может потерять очень много времени на их поиск, потому что не сразу сориентируется, у кого их можно попросить. И вот обмен знанием, у кого спросить и где что посмотреть — это существенный простор для оптимизации работы новичка.
Постепенно новый сотрудник познакомится со всеми коллегами. И “постепенно” здесь ключевое слово. Было бы здорово иметь список в конфлюенсе с указанием, к кому и в каком случае можно обратиться. Но не стоит вываливать список из 20 имен новому сотруднику с кратким пояснением, кто и зачем ему нужен, и надеяться, что этого будет достаточно.
Я рекомендую подход напарника (buddy), его хорошо описали в докладе Lamoda. Buddy — это отдельно выделенный сотрудник команды, который будет отвечать на все вопросы по погружению в компанию. Напарник подскажет, к кому обратиться по тому или иному вопросу — не в какой отдел, а к кому конкретно. Скажет, есть ли похожий функционал или микросервис. Поможет разобраться с принятым в компании стилем общения и поведения.
При работе с продуктом возникает куча всплывающих окон и неожиданных для новичка моментов, тут же он может сразу задать вопрос и понять, что это и зачем было сделано. Даже если ментор не знает, его опыта в компании должно хватать, чтобы знать у кого спросить.
На удаленке нельзя пройти мимо и спросить как дела. Вот этот момент должен взять на себя коллега. Постоянное общение с ним компенсирует эту проблему. Если этого человека нет, его роль стандартно ложится на руководителя, который на удаленной работе загружен ничуть не меньше и у него нет времени оперативно реагировать. Выбирая таких “buddy” нужно учитывать коммуникативные навыки и желание самого человека — кто-то хочет спокойно кодить, и не стоит его в этом винить.
Уходите от общих вопросов к конкретным. На стандартный вопрос “есть ли проблемы?” вы, скорее всего, внятного ответа не получите. Стоит спросить справился ли человек с конкретным заданием, все ли ему там понятно. В этом случае вероятность качественной обратной связи выше, он может вспомнить (и не постесняется сказать), что у него был вопрос по этой теме.
Технический аспект
Проведите технический брифинг по проекту. Разбейте его на несколько встреч. Во время первой расскажите общие моменты. На второй — про взаимодействие с другими отделами. На третьей встрече познакомьте с инфраструктурой. Еще раз проверьте документацию, обновите ее после сотрудника, когда там найдутся недоработки. Когда, а не если! Заранее подберите задачи, которые не требуют удаленного согласования. В идеале попробуйте сами набросать эту задачу и проверьте актуальность описания.
Рассказывая о проекте, вы вводите множество терминов, которые для новичка ничего не значат. Например, “Катни госю на рц”. Когда вводите новые термины, давайте новичку пояснение и дозируйте такую информацию. Если за одну встречу рассказать всю инфраструктуру сервиса, новичок скорее всего забудет почти все те понятия, с которыми не столкнулся в течение ближайших пары дней.
Старайтесь первое время давать парные задачи. Даже если задачу может сделать один человек, лучше ее разбить на подзадачи, чтобы была кооперация. Возьмем, к примеру, микросервис. Допустим, новичок делает слой общения с DB, а более опытный коллега общий каркас и общение по API. Дальше новичок напишет бизнес-логику, и задача уйдет в тестирование как цельный микросервис.
Такие задачи помогают быстрее встроиться в ритм команды, т.к. сидящий на другом конце Skype (Zoom, Hangout) коллега в случае проблем подсказывает и позволяет новичку почувствовать, что он не один. Также это оберегает нового сотрудника от ненужной переделки половины кодовой базы, если вдруг он: 1) неверно понял задачу, 2) хотел показать свои амбиции и убил на это 48 часов без сна.
Удаленка подразумевает повышенное чувство неопределенности. Качественно бороться с ним помогает план. Не девиз, все идет по плану, а сформулированный план погружения сотрудника в детали проекта. А еще план развития сотрудника. И конечно, четко описанные цели сотрудника на испытательном сроке и ожидания от новичка. Они должны быть привязаны не к задачам спринта, а к общим моментам, которые важны для компании на любом этапе разработке. Например:
- Получи доступы у (имя ответственного);
- Разверни ветку задачи на тестовой среде;
- Проведи 5 ревью задач коллег;
- Ознакомься с требованиями dev-ops к выкладке;
- Пройди первую feedback встречу.
Последний пример важен, тут фиксируется встреча для получения обратной связи, о чем я уже много сказал в социальной части. Ваш список будет отличаться в зависимости от приоритета команды и квалификации сотрудника. Можно прям отдельно выделить общую часть и дополнительные для junior, middle и front/back.
Наличие формализованного списка дел и требований на испытательный срок сэкономит нервы вам и вашему новому коллеге. Он позволит сотруднику показать себя с разных сторон за достаточно короткий срок, равный испытательному, и окунуться в разные области вашей работы. Если этого не сделать и дать новичку, например, мирно пилить один модуль, за 3 месяца он идеально его сделает, но может оказаться неэффективен во множестве других моментов.
Как понять, что онбординг прошел на удаленке успешно?
У человека не должно остаться впечатление о команде, как о наборе пикселей на экране. Должно быть понимание, что происходит вокруг команды. Понимание проекта должно быть привязано к конкретным фичам, которые делали живые люди, с которыми он успел поработать и пообщаться.
У нас приняты встречи с фидбеком от других членов команды, где они делятся с руководителем опытом взаимодействия с новичком и общими впечатлениями. Для продуктивности таких встреч, более чем у половины сотрудников уже должен быть опыт общения с новым коллегой. Если они утверждают, что “работу работал, мне не мешал” то процесс онбординга стоит доработать.
Nikolyansky
Классная и понятная статья. Спасибо, Автор!