Принимаем джуниора в команду: 12 советов

Перевод статьи « Onboarding a junior developer to your team? Here’s 12 tips».

Несколько недель назад мой друг Nico König спросил в Twitter о лучших практиках онбординга — приема в команду нового разработчика и, в частности, джуниора.

https://twitter.com/thenicokoenig/status/1242770350645051394

Onboarding (англ.) — вводный курс, адаптация нового сотрудника на рабочем месте. Этот процесс необходим для того, чтобы новый человек как можно быстрее вошел в курс дела и влился в команду. — Прим. ред.

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

1. Разделяйте свое мнение и лучшие практики

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

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

2. Сразу уделите время командам Git

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

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

В идеале следует также уделить время пояснению того, что именно делает каждая команда. Я поняла, как работает rebase, только через девять месяцев работы — когда один из коллег сел и объяснил мне все при помощи ручки и листа бумаги. И, раз уж вспомнили rebase — обязательно объясните его джуниору!

3. Запаситесь заданиями для новичка

Джуниор должен иметь возможность работать над чем-то. Задачи должны быть не срочными, но вместе с тем не пустяковыми. Если не можете придумать, что бы это могло быть, подумайте о вещах из категории «хорошо бы сделать, если будет время». Это могут быть стилевые улучшения, микровзаимодействия, некритичные баги или улучшения общего характера (рефакторинг, доступность, производительность).

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

4. Делайте конструктивные ревью кода

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

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

5. Практикуйте парное программирование

Сессии парного программирования должны быть регулярными (буквально отметьте какое-то постоянное время в календаре). Я рекомендую практиковать парное программирование как минимум дважды в неделю. У вас может быть отдельный набор задач, над которыми вы будете работать вместе с джуниором, или же можно переключаться между отдельными задачами.

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

6. Работайте в паре не только над кодом

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

Как вы тестируете собственный код? Как приступаете к работе над новым проектом? А как насчет менеджмента времени? Планирования презентаций? Для джуниора все эти знания имеют ценность.

7. Всегда будьте доступны для вопросов

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

Джесс Митчелл в Twitter сделал хорошее замечание относительно тона ответов:

«Что касается ответов на вопросы, очень важен неосуждающий тон. Джуниорам и так трудно, не нужно увеличивать их ношу. Прочувствуйте, как отличается ответ «Отличный вопрос! Давай-ка посмотрим!..» от «Странно, что ты этого не знаешь». Часто к подобному тону скатываются даже разработчики, имеющие, в общем, самые лучшие намерения».

8. Найдите для джуниора товарища или наставника

У вас в команде должен быть человек (не менеджер), который будет, собственно, заниматься онбордингом джуниора. Новичку должно быть комфортно говорить с этим человеком откровенно и обсуждать возникающие проблемы.

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

9. Узнайте, как ваш джуниор лучше всего усваивает информацию

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

10. Уважайте время джуниора

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

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

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

11. Регулярно давайте обратную связь

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

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

12. Показывайте пример скромности

Если чего-то не знаете — честно признавайте это и ищите ответ вместе с джуниором. Регулярно предлагайте новичку тоже давать вам обратную связь, может, даже несколькими способами (иногда лично, иногда в письменном виде).

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

1 комментарий к “Принимаем джуниора в команду: 12 советов”

  1. Антон

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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх