Как и зачем растить и онбордить джуниор-разработчиков?

Как выстраивать взаимодействие с джунами и добиваться их плодотворной интеграции в команду? Рассказывает Руслан Мурадов, QA Lead в финтехе и эксперт курсов Skillbox по тестированию. Материал написан на основе доклада эксперта для Skillbox Code Expertes, сообщества для взаимодействия авторов, спикеров, амбассадоров и кураторов образовательных программ направления «Программирование».

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

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

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

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

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

Согласно опросам LinkedIn, большинство работодателей считает, что soft-скиллы значат при найме джуниор-разработчиков больше, чем hard-скиллы. Это обобщенная статистика по всем направлениям: 30% работодателей смотрит в первую очередь на soft-скиллы и только 8% на hard-скиллы. Я с таким подходом соглашусь. Мне кажется, что технологиям обучиться легче, чем развить мотивацию и любопытство, навыки коммуникации и обучаемости и так далее.

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

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

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

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

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

Расскажу и про другие потенциальные сложности в онбординге.

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

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

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

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

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

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

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

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

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

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

А как дела с джуниор-разработчиками обстоят в вашей команде? Какие сложности в онбординге встречаете и как их решаете?