Как сделать ставку на джунов и не прогадать? Выстраиваем кадровую технологию от обучения

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

Я 15 лет создаю и формирую отделы: проджект-менеджеров, Q/A, Scrum, инхаус-команды и команды внешней коммерческой разработки. Это мой основной интерес, хобби и работа. Но отделы — это не только люди, а еще процессы, окружение и множество других аспектов. И я оптимизирую эти процессы, в том числе развития сотрудников.

Главная проблема: сеньоров на всех не хватает

Как решать кадровый вопрос, как масштабировать команду?

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

Почему обучение — это инвестиция?

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

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

Отстройка процесса — навсегда

К вашим задачам добавляется еще одна деятельность — воспитание новых членов команды. Зачем? Если вы связываете будущее с компанией, то вам нужны:

  • кадры,
  • управляемость роста,
  • развитие вдолгую.

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

Джун VS Сеньор 0:1

Три главных качества, которые делают сеньора сеньором:

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

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

Джун VS Сеньор 1:1

  • Мотивация расти. Как правило джун мотивирован как можно быстрее всему научиться и получить опыт, чтобы зарабатывать больше денег и участвовать в крутых проектах. Это можно и нужно использовать для ускорения его роста.
  • Готовность меняться. Если сеньор попадает к вам в компанию и не подходит под ваши ценности, ему сложно перестроиться. С новичками все проще: если у вас есть представление, какими должны быть джуны на каждом грейде, вам будет легче воспитать их в вашей системе ценностей и инструментов.

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

Выстраиваем учебный процесс

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

Без чего нельзя формировать процесс прокачки джунов?

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

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

Сколько ждать?

  • Встраивание джуна в рабочие процессы занимает 1-3 месяца.
  • Выращивание до миддла — 6–18 месяцев. Но гарантий быть не может: в «развитии» много параметров, темп развития зависит от сотрудника, от задач, которые он выполняет, от условий вокруг.
  • Миддл → сеньор — 1,5–3 года. Но это примерные цифры без каких-либо гарантий. Если повезет, то миддл может стать начинающим сеньором за этот срок.

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

Оптимизация

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

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

Найм сотрудников

На входе в процесс обучение у нас, как правило, найм сотрудников. И первое, что вы должны сделать — внимательно посмотреть на текст вакансии, которую размещаете. Обычно требования к кандидату в них однотипные: «опыт от…», алфавитный указатель личных качеств и бесконечно длинный список технологий, которые должен знать и практиковать соискатель. Если мы нацелены на джунов — это только отпугнёт тех, кто старается адекватно оценить свои силы.

Гораздо лучше:

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

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

На собеседовании важно оценить:

  • Личные качества. Они развиваются сложнее и дольше хард-скилов. Научить дизайнера-новичка работать с Figma проще, чем научить человека учиться или отучить его хамить заказчикам и коллегам в ситуации, когда он стрессует. В конце-концов, хард-скилы — это ваша программа обучения, а личные качества — важное условие на входе.
  • Базовые знания об IT и сфере деятельности. Особенно здорово, когда человек прошел базовые курсы от Яндекса, Нетологии и т. д. — то есть он сам делает усилия, чтобы становиться лучше. В случае с фронтедером можно зайти на Git, посмотреть его тестовые задания.
  • Живой интерес новичка. Ему придётся много разбираться и узнавать нового — такое лучше получается у любопытных.
  • Немаловажный аспект — понравился ли человек конкретно вам, верите ли вы, что сможете вырастить из него специалиста. Вам лично придется вкладываться в него от трех месяцев до трех лет, а может быть и всегда, если он станет вашим соратником.

Прокачиваем знания

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

  • Small talk об IT. Самое простое и эффективное — завести привычку болтать с коллегами на айтишные темы, про новые технологии, которые появились, читать твиттеры лучших JS-разработчиков и обсуждать между собой, что нравится и не нравится. Благодаря общению на профессиональные темы у джунов складывается мировоззрение, что быть в курсе происходящего в профессии — это нормально. Джун тоже будет читать всякие полезные штуки и узнавать новое.
  • Поощрять в команде эксперименты, поиск оптимальных решений. Не бояться тратить время и силы на ответ «а что, если…». Особенно круто, когда эксперименты имеют практическую ценность и хотя бы часть из них доходит до практического внедрения. Анализ проблем, поиск оптимальных решений, проведение экспериментов — всё это существенно повышает скорость развития как команды, так и отдельных её участников.
  • У нас в JetStyle разработчики и дизайнеры периодически делятся своими новыми знаниями. Мы проводим небольшие митапы, на которых любой сотрудник может выступить с докладом. В ходе подготовки докладчик еще лучше разбирается в теме, потому что одно дело воспользоваться новыми инструментами, а другое — объяснить про них другим. Это очень полезно с точки зрения шаринга знаний: новички поняли, где и что можно почитать, а старшие коллеги запомнили, к кому в случае чего можно обратиться.

Реальный опыт

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

Что этому способствует:

  • Аджайл и гибкие методологии — лучшая среда для получения опыта. В итерационной разработке: сначала идет обсуждение того, что нужно сделать, потом выполняется работа, затем демонстрация результата заказчику, а после обсуждение, что получилось. Сам по себе цикл позволяет выжимать существенно больше опыта из каждой ситуации, поскольку есть гипотеза-эксперимент-рефлексия-корректировка. Плюс помогает коллективное обсуждение, потому джун видит действия других, может спросить про их мотивы и логику принятия решений. А остальные смотрят, что происходит у джуна и могут вовремя помочь с проблемами, над которыми он сидит слишком долго. Это сильно отличается от линейных процессов, когда джун берёт задачу, выполняет её и отправляет куда-то в пучину таск-трекеров и систем контроля версий. Мало обратной связи, мало информации — это увеличивает страх сделать что-то не так. Особенно глупо, когда джун что-то сделал, сеньор не стал разбираться в пулл-реквесте, а просто всё переписал сам и релизнул. В таком случае весь опыт сводится к ощущению «я пока ничего не понимаю, за меня все переделывают».
  • Самостоятельность от постановки до деплоя. Мы стараемся настроить систему непрерывной интеграции на всех продолжительных проектах. Это позволяет делать относительно безболезненный релиз изменений, оставляя возможность быстро откатиться на предыдущую версию, если что-то пошло не так. А значит мы можем допустить к деплою всех разработчиков, включая новичков. С точки зрения психологии, возможность выполнить задачу и доставить ее до прода очень важна. Одно дело написать код, отправить пул-реквест, закрыть задачу в Jira и пойти делать следующую. Другое — обсудить постановку, выполнить задачу, получить фидбэк от лида, исправить замечания, самостоятельно релизнуть на прод, а потом увидеть, как сделанное тобой улучшение живет своей жизнью. Это другой уровень мотивации: ты не просто написал кусочек кода, а прошел целый путь. Это другой уровень ответственности, потому что, если случилась неудача — это ты релизнул что-то плохое, это неприятно, ведь многие увидят. А если релизнул достижение, можно себе его присвоить.
  • Участие в демо. У нас все новички участвуют в общении с заказчиками. Мы считаем, что джуны должны видеть плоды своих трудов, реакцию заказчика. Если она положительная, они могут гордиться собой, если отрицательная, они понимают, что их действия имеют конкретные последствия. Фидбэк — ключевая часть обучения, без него непонятно, делаешь ты правильно или нет.

Наставники и процессы

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

Мы постепенно выделили следующие выгоды для практикующих наставников:

  • Точка карьерного роста. Человек, который умеет обучать, — это другой уровень специалиста. И вообще, сеньор без таких навыков — скорее исключение, чем правило.
  • Повод самому лучше разобраться. Когда человек объясняет другому, он вынужден посмотреть на привычные инструменты взглядом джуна и попытаться понять, как это можно объяснить. Объясняя, мы сами лучше понимаем, как все устроено.
  • Прокачка навыков управления. Сеньор тем сильнее, чем больше рутинной работы может сделать руками подопечных. Это один из естественных способов повышения собственной эффективности для компании.
  • Ценность для команды и компании. Количество задач и заказчиков растет, поэтому ценится умение обучить новых членов команды.

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

Как мы ищем и обучаем джунов

  • Открываем вакансию под наставника или под проект.
  • Выбираем толковых и заинтересованных, даже если у них нет опыта в компании. Смотрим, что они уже попробовали из бесплатных курсов, принимали ли участие в pet-projects.
  • Вводим в курс дел и обсуждение проектов. У нас 8–10 проектов идут параллельно: делаем так, чтобы все были в курсе, кто и что делает: это дает повод поболтать, узнать, к кому можно обращаться.
  • Больше самостоятельности без потери контроля. Наставники не должны надолго упускать из вида новичков, вдруг они застрянут, потеряют темп развития и мотивацию. Но нужно найти способы контроля, которые не будут лишать джуна самостоятельности. Например, практики аджайла с ежедневными митапами позволяют контролировать ненавязчиво.
  • Помощь в трудных ситуациях.
  • Разделять и достижения, и ошибки. Ретроспективы, демо с заказчиками, вся обратная связь попадает в новичка, и он понимает, что все не понарошку, что он имеет отношение к результату. На ошибках джуны учатся.
  • Часть команды — часть корабля!

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

Артем Аксенов
Scrum-мастер JetStyle

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

А если вы хотите у нас работать или поговорить про процессы обучения сотрудников, пишите на почту [email protected].

0
23 комментария
Написать комментарий...
Святослав Жиличев

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

Ответить
Развернуть ветку
Ann Tatyankina

будем ждать кейс, интересно почитать про практику и про результаты

Ответить
Развернуть ветку
Vladimir Alekseev
Сеньор сам может разобраться в бизнес-процессах заказчика

Какое заблуждение!
Но в целом норм

Ответить
Развернуть ветку
Igor Kirsanov

Не каждый сеньор в последнее время настоящий сеньор.

Ответить
Развернуть ветку
Vladimir Alekseev

как и миддл

Ответить
Развернуть ветку
tass neposeda

И это боль, да :)

Ответить
Развернуть ветку
Святослав Жиличев

Разделение на Джун/Мидл/Сеньер впринципе очень абстрактная вещь. И в каждой компании могут быть свои требования. И как по мне сеньора от мидла отличает именно умение/возможность разбираться в бизнес стороне продукта.

Ответить
Развернуть ветку
Вера Гагарина

Вы тут поосторожней: недавно одни написали про джунов, дак их потом еще неделю хуесосили :) Так сказать — не попали в ожидание аудитории :)

Ответить
Развернуть ветку
Никита Хисматов

Ну вы скажете! Тот высер не каждому под силу повторить ))

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
tass neposeda

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

Ответить
Развернуть ветку
Igor Kirsanov

Скажите, как у вас построен процесс самой работы, что сеньору нужно такое количество джунов и главное зачем, если по статье он может в течении нескольких минут сам(а) все сделать? Хотелось бы больше информации.

Ответить
Развернуть ветку
tass neposeda

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

У нас итерационный процесс, когда мы вначале стараемся максимально быстро сделать как-то работающий основной флоу, чтобы вместе с заказчиком проверить продуктовые гипотезы (типа MVP). В этот момент по сути уточняются ключевые свойства системы и действительно сеньору нужно быть максимально включённым. Далее, бэклог начинает наполняться новыми фичами и доработками старых фич. и среди задач появляется изрядное количество тех, которые находятся в зоне развития джуна, а сеньора отвлекают от "движения вперёд".
Безусловно, каждую из них, сеньор поправит сильно быстрее. Но зачем, если джун сможет сделать это сам, обучиться и освободить сеньора от рутины, которую он уже "сто раз делал".

Ответить
Развернуть ветку
Igor Kirsanov

Получается, по вакансии набирается допустим 50-60 человек, отбор проходит 8-10, далее какой-то отсев происходит уже в процессе работы?

Ответить
Развернуть ветку
tass neposeda

:) неееее, такое только у Грега Хауса в 4м сезоне бывает :) У нас не настолько "поточное производство". в среднем одномоментно у нас 1-3 джуна. И да, испытательный срок у нас правда испытательный. Если человек не развивается и подвис - мы всегда стараемся разобраться, что его фрустрирует - бывает что дело совсем не в нём, а мы упустили какие-то нюансы. В общем пытаемся поправить ситуацию. Но бывает, что это повод расстаться. 

Ответить
Развернуть ветку
tass neposeda

Уточнение - сейчас количественно речь идёт про одну команду продуктовой разработки, а не про весь джет

Ответить
Развернуть ветку
Ann Tatyankina

я прям сходила в хантфлоу и посмотрела статистику)

вот, например, позиция junior frontend разработчик 
- средний срок закрытия — 17 дней,
- но при этом и обрабатываем мы порядка 100-120 откликов изначальных (то есть у нас входящий поток довольно хороший),
- одновременно много джуниоров не бывает в конкретной команде разработки, от 1 до 3 — они же под конкретных людей берутся, это важно
- и да, как написал Артем, для нас испытательный срок — не фикция, он действительно есть и нужен

в общем, мы довольно сильно фильтруем на входе

Ответить
Развернуть ветку
Ann Tatyankina

мы просто поделились своим опытом по выстраиванию команды. кто какие выводы сделает — тут уж дело читателей

Ответить
Развернуть ветку
Valentin Dombrovsky

Питонистов нанимаете? А то у нас есть группа выпускников (и регулярно появляются новые). 

Ответить
Развернуть ветку
Ann Tatyankina

нанимаем)
можете написать мне на [email protected]

Ответить
Развернуть ветку
Икс Маска

Ваш опыт очень относителен :))). Бегло глянул ваш сайт, основная ваша специализация – это маркетинг. Поэтому у вас получается, чтобы «старшие специалисты помогали новичкам и прокачивали их в профессии». Маркетологи – это особая каста «специалистов» :)

Мне интересно, например, как у вас получится «прокачать», а потом «удержать» сеньора Technical Team Lead или Full-stack Developer? И как вы аргументируете Full-stack-сеньору со ставкой 120$ в час, что он должен бесплатно «прокачивать» навыки новичков?

Ответить
Развернуть ветку
tass neposeda

Хороший вопрос. Есть понятие ownership, которое описывает отношение кого-то к процессам, команде, продукту. Вот мы делаем ставку на то, чтобы все члены команды были заинтересованы в развитии вместе с командой.
Мне кажется, что нормальный сеньор в какой-то момент приходит к выводу, что его способ масштабирования - делегирование своим подопечным.

В целом, при таком подходе просто увидеть, что мотивация не только в отношении деньги к часу. Тогда польза от прокачки новичков становится понятной.

Ответить
Развернуть ветку
Ann Tatyankina

это история ровно про команду разработки, про фронтов и бэков.
и мы специализируемся на цифровых продуктах и сервисах. на разработке и дизайне, маркетинг в том числе, но это не основная наша специализация)

Ответить
Развернуть ветку
20 комментариев
Раскрывать всегда