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

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

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

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

Почему джуны — это хорошая инвестиция

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

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

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

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

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

Экономика джуниор-специалиста

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

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

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

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

Проблема №1. Не все джуны тянут

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

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

• Слабые менторы. Не каждому дано обучать коллег. Кому-то это просто неинтересно, у кого-то слабые софт-скиллы. А софт-скиллы здесь очень важны. Ментор — это не просто тот, кто помогает с кодом. Это еще и психолог, который должен слышать, понимать и поддерживать.
  
  Как развивать эмпатию — рассказывали в статьях и постах.

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

Проблема №2. Джуны — это дополнительные затраты

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

• вы получаете ракету: сотрудник быстро растет и становится полноценной боевой единицей;

• вы получаете надежного специалиста с хорошей базой: сотрудник показывает стабильный и умеренный рост, растет в своем темпе;

• вы «прогораете»: вам приходится отказаться от услуг джуна, потому что он совсем не справляется.

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

Проблема №3. Джунов некому учить

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

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

Памятка: что важно при работе с джунами

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

• настроенный процесс онбординга;

• индивидуальный план развития (ИПР);

• постепенное увеличение сложности задач и ответственности;

• регулярные One-to-one;

• предоставление положительной и конструктивной обратной связи;

• признание достижений сотрудника.

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

Онбординг

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

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

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

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

Индивидуальный план развития (ИПР)

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

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

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

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

4. Даем список литературы, которая поможет сотруднику прокачать хард- и софт-скиллы. Конечно, тестов на знание этих книг мы не проводим, но ознакомиться с ними точно не помешает.

Постепенный рост нагрузки

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

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

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

Регулярные One-to-one

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

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

Вот несколько тем, которые можно обсудить:

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

Джун тоже должен давать обратную связь

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

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

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

2. Озвучивать четкие цели и задачи. Как я писал выше, сложность задач нужно повышать постепенно. В начале дробите большие задачи на маленькие и простые. Это поможет джуну лучше понять проект и обязанности.

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

4. Поддерживать развитие. Здесь важны ИПР и ментор, про которые я уже говорил. Постепенно джуну нужно давать всё более сложные задачи — как бы бросать вызов. Так новичок будет чувствовать, что прогрессирует.

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

6. Не давить и поддерживать сотрудника. Повторюсь: не надо с первых дней перегружать сотрудника. И всегда поддерживайте его, даже если результаты его работы не идеальны или требует переработки.

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

Суммируем всё, что узнали

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

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

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

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

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

Что еще почитать

• Гайд. Работаем со стажерами в промышленных масштабах: набираем, учим, выпускаем на реальные проекты за 4 месяца

• Стоит ли идти в тимлиды? История о том, как меня повысили и что я теперь об этом думаю

• Как не сжечь команду дотла, или Почему Work-life balance — задача руководителя