Почему мы охотно нанимаем джунов и советуем всем делать то же самое

Всем привет! Меня зовут Артем Валевич, я тимлид в AGIMA. Хочу рассказать о нашем опыте работы с джуниор-разработчиками. Вообще на рынке к ним принято относиться с опаской. Есть стереотип, что они приносят мало пользы, зато требуют много вложений. Что ж, это отчасти правда, спорить бессмысленно. Но мы ребята рисковые, решили пробовать — и в итоге остались довольны. В этой статье объясню нашу логику и немного расскажу о том, как мы готовим джунов к великим свершениям.

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

Но эта, казалось бы, очевидная мысль совсем не очевидна. Большинство компаний не хотят нанимать джунов. Согласно статистике Хабр Карьеры, только 5% айтишных вакансий — это вакансии для джунов. Для сравнения: 50% — для мидлов, 31% — для сеньоров, 8% — для лидов. И даже на стажеров спрос выше — их ищут 6% работодателей.

Мы тоже активно работаем со стажерами, но и к джунам относимся с интересом. Ниже развею несколько мифов о работе с ними и расскажу, как (и зачем) мы их обучаем.

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

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

Но, конечно, это не единственный плюс. Мы видим еще несколько однозначных преимуществ:

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

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

Примерно к 4–5 месяцу линии графика пересекаются. То есть через полгода джун начинает полностью себя окупать или даже приносить первую прибыль. А уже через год затраты стремятся к нулю. Важно понимать, что полностью они никогда не исчезнут, так как мы продолжаем вкладываться в развитие специалиста. Но дивиденды от его работы всё-таки несравнимо выше.

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

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

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

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

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

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

Разберем каждый пункт отдельно.

Первое, что нужно сделать, — отладить процесс онбординга в компании. Нам в этом сильно помогают так называемые чек-листы онбординга. По сути, это список задач, которые тимлид должен закрыть, чтобы новому человеку в его команде было комфортно. И само наличие чек-листа гарантирует, что ничего важного он не забудет.

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

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

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

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

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

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

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

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

Чтобы они не были формальными, к ним также нужно готовиться — например, накидывать вопросы, которые позволят сотруднику разговориться и проанализировать свои результаты. Главное — не задавать их по списку как на опросе общественного мнения, а мотивировать собеседника на диалог.Вот несколько тем, которые можно обсудить:

Проводить One-to-one лучше не чаще одного раза в две недели. Ответы нужно тщательно анализировать. И конечно, важно реагировать на сказанное: если сотрудник признался, что не успевает усваивать новую информацию, нужно дать ему больше времени, и т. п.

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

Как мотивировать его быть откровенным:

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

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