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

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

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

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

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

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

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

Мы разобрали типичный и самый неприятный сценарий, теперь поговорим о том, что можно сделать, чтобы его избежать.

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

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

Осветив все базовые вопросы, стоит договориться с джуном о времени, когда он не должен беспокоить никого из команды. Разве что в исключительных случаях. Это может быть два-три часа в середине дня, которые считаются наиболее производительными, когда обычно делается солидная часть работы — например, с 13 до 15. Договоритесь, что вы ответите позже. Так новичок начнет усваивать внутреннюю культуру команды; к тому же, возможно, ко времени ответа он уже сможет и сам разобраться. Если вы работаете в офисе, можно договориться о «режиме концентрации»: когда вы, например, надеваете наушники, вас лучше не беспокоить.

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

Чем больше ответственности за джуна возложено именно на вас, тем важнее заранее предусмотреть возможные проблемы и вопросы. Особенно если вы официально назначены ментором. Это очень поможет вам, особенно в первые недели, наиболее важные в ходе онбординга. В это время важно время от времени пинговать джуна — можно даже поставить себе 4–5 напоминаний в течение дня: «У тебя всё окей? Вопросов нет? Если есть, сейчас я могу тебе на них ответить». Да, так вы можете потратить чуть больше времени, чем если просто ждать вопросов самому, но сможете перестраховаться от кучи проблем в будущем.

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

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

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

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

Расскажите, а какие приемы для обучения джунов практикуете вы?