Джуниоры

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



Рассказывать будет Серёжа Попов, CEO Лига А. и директор по талантам в HTML Academy. В Лига А. работа с джуниорами поставлена на поток: половина фронтендеров компании это выпускники HTML Academy. Выпускники приходят в компанию на стажировку, где им помогают развиваться, а 95% тех, кто после стажировки ищет другую работу трудоустраивается.

Серёжа уже больше 3 лет выполняет роль наставника для джуниор-фронтендеров и научился работать с ними так, чтобы новички быстро росли до крутых специалистов и приносили пользу компании. Нюансами, принципами, правилами и секретами работы, он поделился в докладе на TeamLead Conf 2020, а мы расшифровали.


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

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

Зачем нужны джуниоры

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

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

Если простую задачу ценой в 1000 рублей выполняет человек со ставкой 2500 рублей в час что-то пошло не так. Поэтому здесь не обойтись без джуниоров они сокращают стоимость производства (продуктов, ПО).

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

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

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

Чтобы столько не ждать, опытным путем в Лига А. выработали инструкцию, как помогать джуниору расти в компании, так, чтобы не было мучительно больно. В инструкции несколько этапов, первый из которых подготовка.

Подготовка к джуниору

Чтобы подготовиться, убедитесь, что у вас есть сформированные задачи и ментор.

Сформированные задачи важны (или понимание, как их сформировать), потому что джуниор это работник. Он не талисман, который ходит по офису и всех подбадривает, а сотрудник, который должен работать и выполнять задачи.

Джуниор может выполнять что-то простое:

• правки;
  
• модификации готовых компонент;
  
• создание простых компонент;
  
• работать по инструкции или документации.
  

Ребята, которые попадают к нам, делают простые вещи: вносят правки или собирают страницы по UI-kit. Потом растут и выполняют задачи сложнее, например, пишут простую логику.

Когда джуниор будет работать над задачами, ему нужен ментор наставник. В 2018 году я участвовал в ПК FrontendConf. Один из хороших докладов, который не прошел в программу из-за высокой конкуренции, назывался Что делать, если мне подложили джуна? Это то чувство, которое возникает у мидла, когда на него пытаются скинуть наставничество. Когда менторство навязывают против воли сотрудника никто не будет доволен. Важно заранее все обсудить и назначить человека, который будет готов к нагрузке.

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

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

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

Для джуниора должна быть работа и человек, который ее контролирует.

Отбор

Второй и самый важный этап, который все недооценивают. На этом этапе придётся научиться многим вещам:

• привлекать поток джуниоров;
  

• просеивать поток до собеседования;
  
• собеседовать;
  
• отсеивать тестовым заданием;
  
• выбирать кандидатов.
  

Привлечение

Есть три способа: своими силами, силами образовательных площадок и с помощью своей школы.

Своими силами: размещайте вакансии на специализированных площадках вроде hh.ru или Хабр Карьера. Осознанно подойдите к составлению вакансии от неё зависит сколько нерелевантных откликов вы получите (а получите обязательно).

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

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

Своя школа. Например, так делает Яндекс у них своя школа ШРИ Яндекса. Открывать свою школу эффективный путь получения хороших начинающих специалистов. Но долгий, дорогой и сложный:

• придётся разработать образовательную программу;
  
• подготовить онлайн-платформу (или найти помещение, если это не онлайн-школа);
  
• записывать видео;
  
• тратить часы разработчиков;
  
• вкладываться в маркетинг.
  

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

Отсев потока

После появления вакансии на площадках с работой, вы получите сотни откликов. Но вы не будете брать на работу всех, нужно как-то их отсеивать. Например, когда в Лига А. мы опубликовали вакансию Начинающий Верстальщик, то получили 164 отклика. Из них до собеседования дошло 10 человек, а вышло на работу 2.

8 человек из 10 не дойдет до собеседования.

Это усредненная статистика: по нашему опыту, по вакансиям Центра Карьеры HTML Academy и по статистике других работодателей. Вас тоже ждёт такая воронка, если не хотите брать на работу всех подряд.

Будьте готовы просеивать подготовьте себя и команду к тому, что будет много заявок, но низкая конверсия (как у нас или ещё ниже). У вас должно быть на это время, ресурсы и моральная готовность. После публикации вакансии поток заявок будет нескончаем в какой-то момент придётся обрубить поток.

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

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

Не ждите идеального резюме.

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

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

Собеседования

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

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

Брать побольше людей придётся и для того, чтобы у вас был выбор. Но выбирать вам придется не между Ламборджини и Феррари, а между Ладой и Москвичом.

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

Именно по этой причине не приходите на собеседование всем отделом. Вы успеете посмотреть на человека, когда он выйдет на работу. Даже мидлов и сеньоров напрягает, когда на собеседование приходит 10 человек из CTO, CMO, CPO и старших разработчиков, а для джуниора это ад. Поэтому лучший формат один на один. Проведите хотя бы первое собеседование в таком формате.

Зовите больше кандидатов, но меньше коллег.

Не давайте тестовое задание на собеседовании. Мы в Лига А. собираем истории от джуниоров о том, как у них проходит трудоустройство. Один из случаев: новичок пришел на собеседование, а интервьюер даёт ноутбук и говорит:

Сверстай по PSD.

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

Но не отказывайтесь от технических вопросов: спросите, что такое HTML, CSS, как работает JavaScript, что такое браузер:) Но только если видите, что человека не трясет и он не упал в обморок.

Смотрите на развитие и адекватность. Узнайте, как он учился и как узнает новую информацию. Если человек расскажет о важных для сообщества подкастах, митапах, конференциях, блогах, каналах на YouTube это то, что нужно. Если отвечает: Я диплом получил, зачем мне ещё учиться?, то до свидания.

Желание обучаться одна из ценностей компании, по которым мы также отбираем кандидатов. Ещё одна ценность горящие глаза. Горящие глаза подскажут, что человек готов работать. Не сам он горит, а только глаза. Сам он гореть будет, когда устроится на работу.

Тестовое задание

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

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

Трое из четырех джуниоров не возьмутся за сложное тестовое задание.

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

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

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

Ставьте сроки из расчёта 2 к 1. Джуниоры выполняют работу примерно в 2 раза медленнее. Если даёте тестовое задание на 2 часа, рассчитывайте, что джуниор выполнит его за 4.

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

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

Некоторые талантливые джуны после 2-3 коротких и гневных фидбеков перестают искать работу. Но это не проблема кандидатов это проблема работодателя. Ведь это закономерно: работодатель пишет неправильную вакансию, неверно оценивает кандидатов и дает неправильное тестовое задание, а потом срывается на джуниоре, потому что тот не удовлетворяет требованиям мидла Зачем?

Выбор кандидата

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

Но не берите несколько человек с расчётом на то, что в конце останется только один. Это не игра на выживание.

Берите на перспективу. Джуниор не выдаёт результат здесь и сейчас. Рассчитывайте на то, что он будет приносить пользу через полгода.

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

Хороший способ не нервничать чем-то заняться: почитать о корпоративной культуре, познакомиться с продуктами, изучить code style. Дайте задание до выхода этими и другими способами подготовиться к работе.

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

Испытательный срок. Первые два месяца новичок работает на 200% своих возможностей, а дальше устаёт и раскрывает свои истинные таланты. Поэтому прописывайте время испытательного срока в три месяца это оптимально.

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

Через две закрытые вакансии вы научитесь отбирать джуниоров.

Работа

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

Онбординг

Не бросайте в мясорубку. Как избавиться от джуниора? Кидаете в него в первый день боевую задачу, например, развернуть окружение, и уходите. У него начинается паника. Приходите через неделю за результатом, а у вас мёртвый джуниор (если он еще не уволился) и невыполненная задача.

Не оставляйте одного. Моя первая работа разработчиком в большой компании проходила в Veeam Software. Тогда мне не нравилось, что меня таскали на дурацкие планёрки: полно народу, все что-то говорят, какие-то странные люди по Skype разговаривают на английском, ничего не понятно, что происходит. Но сейчас я понимаю, что это помогло мне окрепнуть, окунуться в рабочий процесс и стать частью коллектива.

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

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

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

Процесс работы

Прошла неделя, две джуниор окреп и привык. Что изменилось в нашем подходе?

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

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

• Берите на все командные и рабочие мероприятия даже в качестве слушателя.
  
• Возьмите джуна в релиз пусть сидит и смотрит, как все бегают в огне. На третий релиз он начнет помогать.
  
• Учите работать в команде. Джуниоры умеют писать код и работать с системой контроля версий, но не в команде. Будьте к этому готовы, учитывайте это и помогайте наладить взаимодействию.
  
• Не позволяйте команде обижать джунов. Если у вас есть джуниор, значит он нужен. Следите, чтобы другие разработчики не грубили и не отказывали в помощи.
  
• Не позволяйте джунам обижать команду. Когда джуниор не принимает правила работы, вступает в конфликты и споры со старшими специалистами, говорит:Я Дартаньян, а вы нет, и работа с ним превращается в ад меняйте. За дверью стоит очередь из таких же.
  
• Не доверяйте. Настраивайте безопасное окружение, отдельные ветки, запрет на коммит в мастер все на уровне системы, а не на честное слово.
  

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

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

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

В то же время, не беспокойте джуниора слишком часто. Джуниоры работают медленнее в 1,5-2 раза медленнее, по статистике Лига А., HTML Academy и других проектов на выборке в 500 джунов. Учитывайте это при постановке задач и планировании. Если джуниор будет систематически не успевать за вашими сроками, это будет его демотивировать.

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

Как вы посмели провести код-ревью моего кода! Я не привык к тому, что мне указывают на мои ошибки!

Это выдержка из рабочего чата от разгневанного джуниора. Джуниоры не привыкли к разбору их кода, в отличии от опытных разработчиков.

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

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

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

Мотивация

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

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

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

Никто не хочет быть вечным джуном.

Не держите джуна долго в статусе начинающего специалиста, растите внутри компании. Через 3-6 месяцев новичок вырастает в крепкого специалиста.

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

Что дальше?

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

Не бойтесь джуниоров и процесса их поиска. У них есть плюсы.

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

Джунов много.

Будет из кого выбрать. У вас не будет моей ситуации, когда 4 кадровых агентства искали мне сеньора 2,5 года. С джунами проще: заходите в метро, берете первого попавшегося человека это готовый фронтендер-джуниор.

Приготовьтесь к тому, что джуниоры будут:

• бесить;
  
• задавать тупые вопросы;
  
• остро реагировать на критику;
  
• медленно работать;
  
• подвергать сомнению ваше доверие к ним;
  
• бесить.
  

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

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

Вторую TeamLead Conf в этом году мы снова проведем в Москве, 16 и 17 ноября. Это будет очная встреча со всеми атрибутами: спикерами на сцене, кулуарным общением, митапами-воркшопами и кофебрейками.

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

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

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

Страх, страх и еще раз страх

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

Точно такой же стереотип существует и в области разработки программного обеспечения. Сформулировать его можно так:

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

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

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

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

Я считаю, что программирование это история о созидании, о творчестве.

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

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

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

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

Но как не убить в джуне энтузиазм, любопытство и стремление к саморазвитию? Как помочь новичку развиваться, а не делать из него мальчика (или девочку) принеси-подай? Как не испортить джуна?

Давайте новичку настоящие и актуальные задачи

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

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

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

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

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

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

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

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

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

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

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

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

Практикуем парное программирование

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

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

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

В целом, это очень позитивная практика, потому что она содержит элементы обучения в процессе написания рабочего кода и, кроме того, позволяет выявить фундаментальные проблемы и пробелы в знаниях, которые без парного программирования джун смог бы скрывать месяцами. Ведь никому из нас не нужен Google-программист, так?

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

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

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

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

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

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

Относитесь к джуну, как к равному

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

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

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

Однако в профессиональном плане он пока подросток и это играет злую шутку: к взрослому человеку начинают относиться, как к неразумному ребенку. Снимают с него ответственность, осторожничают, опекают.

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

Так и отношение к джуну, как к разработчику, а не как к бесполезному питомцу или ребенку, подтолкнет его к профессиональному росту, осмотрительности и аккуратности.

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

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

А ведь именно это нам и нужно, потому что через внимательность, старательность и желание стать профессионалом, из джунов и вырастают лучшие члены команды.

Итог

Тут я просто тезисно перечислю основные идеи из текста выше, для вашего удобства.

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

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

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

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

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

P.S.

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