Как и зачем нанимать Junior-разработчиков в команду?
В этой статье я хочу поделиться с вами тем, от чего многие компании бегут. Это найм специалистов с отсутствием опыта или с небольшим опытом. Проще говоря — джунов.
Надо отметить, что эту тему не раз поднимали на Хабре, так что я настоятельно рекомендую ознакомиться с мнениями других специалистов: 1. Если вы не нанимаете джунов, то не заслуживаете сеньоров. 2. Воспитываем Джуниора.
Проблематика
В чём же постановка задачи в найме Junior-разработчиков? Рассмотрим типичные проблемы найма:
Опытного программиста можно искать довольно долго Давайте честно: подавляющее большинство компаний далеки от понятия «работа мечты» (везде есть набор минусов). Да и не везде кандидату могут сделать предложение, от которого он не сможет отказаться. Как правило, приходится решать задачу поиска оптимального 3-стороннего сочетания между требованиями, бюджетом и специалистами на рынке. Очевидно, что поиск может затянуться. Да и мало найти специалиста — его ещё нужно удержать. Ни для кого не секрет, что толковые программисты выбирают работу, а не наоборот. Поэтому придётся конкурировать. Всё это приводит к тому, что иногда найм растягивается до 6-12 месяцев. А за это время джун спокойно себе вырастает до хорошего middle-специалиста!
Хороший программист — дорогое удовольствие И это не только вопрос найма. Через год почти наверняка встанет вопрос о пересмотре заработной платы. И если его отклонить, то программист скоренько отправится на поиски. А если технологии, которые используются, современные и востребованные, то предполагаемое изменение в зарплате будет довольно ощутимым. Более того, не во всех компаниях есть бюджет на найм нескольких программистов.
Программист-рок-звезда Да, это отдельная история и проблематика. Можно нанять опытного разработчика, но его поведение будет всегда вызывать конфликты. Есть тип программистов, которые считают своё мнение истиной в последней инстанции, что будет часто мешать в принятии решений. Мы помним, что код без бизнес-составляющей не стоит ни копейки, а значит, всегда нужно будет искать компромиссы, на которые «рок-звезды» могут не пойти.
Каковы плюсы?
Конечно же, найм джуниоров — это не панацея для перечисленных проблем. Для их решения потребуется комплексный подход. Однако найм младших разработчиков может помочь в снятии остроты проблемы. Это не означает, что надо, сломя голову, нанимать всех. К работе с младшими программистами нужно быть подготовленными, чтобы действительно получить от этого пользу. Какую именно? Сейчас перечислим:
Джуниоров много Рынок переполнен ими: вчерашние студенты, «самоучки», выпускники курсов. Выбор действительно огромен. И можно отыскать толковых людей, готовых к быстрому росту и развитию.
Джуниоры стоят совсем недорого На этапе найма младший разработчик обойдётся Вам в 1,5-2 раза дешевле того же middle-специалиста. И это поможет получить резерв в бюджете команды, который ещё точно пригодится.
Джуниора можно нанять быстрее, потому что см. пункт 1 Только оставляйте время в своём графике для многочисленных интервью.
Человек, выросший в команде, будет ей лоялен Это не значит, что можно не повышать ему зарплату и в очередной раз не отдавать паспорт. Но, как правило, такой специалист мягче отнесётся к каким-либо дискомфортным событиям и не будет спешить убегать в другую компанию.
Можно ещё долго перечислять достоинства найма младших программистов, но это бессмысленно. Почему-то компании всё ещё продолжают искать опытных разработчиков. Это связано с тем, что в найме младших разработчиков есть далеко не только плюсы. Вам предстоит решить очень много вопросов и проблем, чтобы получить ожидаемый профит от найма младшего специалиста.
Итак, вы решили нанимать Junior-разработчиков…
1. Знакомство с продуктом
Готовьтесь к этому заранее. Вы не сможете работать с ним «по бразильской системе», тупо бросив в код. Он не сможет самостоятельно разобраться с кодом, понять тонкости архитектуры, да и просто собрать себе окружение. Первым шагом здесь часто устраивают практику «живых тренингов», когда опытный разработчик садится вместе с джуном и объясняет ему, что и как устроено. Довольно быстро на поверхность всплывают минусы данного подхода. Во-первых, это требует довольно много времени, так как объём вводной информации довольно большой. Во-вторых, энергии нужно больше, так как опыта у джуна меньше — он потребует объяснений каких-то элементарных на взгляд опытного программиста процессов. В итоге сессии объяснений случаются всё реже, а джун отправляется в свободное плавание до первого косяка, удаляющего данные с прода. Не надо так делать :-)
Можно предложить куратора, который будет постоянно стоять над душой у джуна и проверять его. Вероятно, даже за какую-то плюшку. Но это тоже ресурсозатратная история. Поэтому лучше всего здесь работает стандартизация. Рецепт в следующем:
1) выделите процессы и знания, которые потребуются джуниору в первые 1-2 месяца работы. Это такие вещи, как получение рабочей среды, введение в используемую кодовую базу (как работает загрузка классов, сборка проекта, внедрение зависимостей и т. п.);
2) опишите эти вещи в wiki. Например, в виде чек-листов или схем. Скорее всего, поначалу это будет даваться тяжело, но с каждой новой итерацией найма вы сможете собирать фидбэк и оттачивать документы;
3) внедрите недостающие процессы автоматизации. Звучит громко, но ведь автоматизировать сборку виртуальной машины довольно легко. Вы потратите на это считанные часы, которые потом с лихвой будут экономиться на старте работы;
4) опишите п. 3 в документации.
Стандартные процессы контролировать гораздо легче. С одной стороны, вам не надо будет каждый раз устраивать многочасовую лекцию об одном и том же, с другой — джуниоры смогут задавать вопросы, касающиеся непосредственно прикладных задач.
2. Прокачка персонажа
Капитан Очевидность заявляет, что джуниоры приходят в компанию совсем не для того, чтобы до старости верстать формочки. Они хотят вырасти. И если через какое-то время этого не случается, то джуниоры уходят в другие компании. Задача команды заключается в обеспечении прозрачности роста. И касается это не только команды, но и всей компании. Крайне часто фирмы считают, что повышение заработной платы — это экстраординарное событие, говорить о котором нельзя, а уж просить — тем более.
Интересный факт: программисты (любого уровня) сваливают из таких компаний гораздо чаще. Поэтому тимлидер должен чётко и без компромиссов согласовывать условия пересмотра позиций младшего разработчика в случае его роста. Иначе смысл в найме резко теряется.
В сторону джуниора же должен быть направлен план развития. Он может быть нестандартным — отталкиваться от конкретного сотрудника. Но нужно показать условия игры и обозначить, при каких условиях джуниор может рассчитывать на рост. Не надо писать здесь что-то в духе «участие в проектах» или «количество закрытых задач». Метрики здесь будут сложнее. В проекте можно поучаствовать, спустя рукава, а задачи можно закрывать пачками, но не принося ценности продукту.
Сравните требования к джуниору и к миддлу, которого вы пытаетесь найти. Покажите джуниору описание вакансии, но дайте понять, что для повышения нужно будет пройти стандартное собеседование, которое покажет, что он вырос. А вот предпосылками к этому собеседованию уже могут быть вышеупомянутые метрики, которые подскажут, пора или не пора повышать джуна.
3. Кнуты и пряники
ОК, джуниор начинает брать первые таски, и через какое-то время первые из них доедут до состояния готовности. Здесь важен качественный code review. Причём чем больше правил написания кода у вас в команде формализовано, тем лучше. Дело в том, что джуниоры могут и будут воспринимать критику слишком резко. Очень часто они либо прут в агрессию («да всё тут нормально в коде, чё придираешься?!»), либо думают, что их сейчас уволят («я перенёс строку не там — мне конец!»). Всё это от того, что джуниор ещё не чувствует себя уверенно и не понимает допустимости определенного уровня проблем. Более того, они ещё не понимают всей пользы критики, не умея обращать её в пользу для себя.
Из этого отнюдь не следует факт того, что с джуниора надо сдувать пылинки. Но критику надо делать максимально конструктивной, убирая резкие вещи, привычные в команде сильных программистов (вы ведь тоже жестите «шутками за 300?»). В обосновании своей позиции вам поспособствуют не только опыт и выдержка, но и ссылка на документацию и общепринятые практики. Это поможет и джуниору увидеть, что по установленным правилам играет вся команда, а не только новобранцы. Разумеется, из этого следует равнозначная критика кода на ревью как опытных разработчиков, так и джуниров, чтобы не вышло ситуации с кодом, который отклонили у джуниора, но приняли, скажем, у миддла.
Не стоит при этом забывать и про компромиссы, так как не весь код, который уходит в Production, идеален (остаёмся честны сами с собой!). Показывайте джуниору, когда такие вещи допустимы. И когда можно пропустить компромиссное решение в прод с последующим исправлением.
Не забывайте давать позитивную обратную связь. И делайте это не только на встречах один на один, но и в повседневной работе. Нужно хвалить за хорошие решения, новую изученную и применённую технологию. Человек должен быть замотивирован вами, и эта мотивация не должна быть наигранной. Оцените успех трезво и объективно. Ведь джуниоры будут стараться внедрять всё, что нашли в умных книжках. Одним только ограничением на внедрение можно убить их запал. Показывайте, что и где из изящных решений можно внедрять.
При всей выгоде найма Junior-разработчиков нужно помнить о том, что кто-то всё таки должен следить за их работой и ростом. Поэтому плохим решением будет собрать команду целиком из джуниоров, навесив их на одного опытного специалиста. Всё закончится плачевно даже для проекта средней руки. По моему опыту соотношение может быть таким: 1-2 джуниора на 1 миддла-сеньора. Больше будет хуже, так как у старшего специалиста не будет хватать времени, а контроль будет рассеиваться.
Многие начинающие разработчики молоды, а это вполне может привести к их непониманию графика работы в компании. Они могут опаздывать, а порой и не являться на работу по каким-то совершенно сумасбродным причинам, оставаясь при этом всё теми же подающими надежды в профессиональном плане людьми. Стоит ли сразу расставаться с ними? Однозначно нет. Для начала ответьте себе честно на вопрос: «А зачем вам график работы?». Неверным ответом будет: «Чтобы следить за сотрудниками». График работы должен обеспечивать предсказуемость. Таким образом, если у вас в работе внедрён Scrum, то ежедневные стендапы должны случаться утром в одно и то же время. И опоздание будет говорить о неуважении рабочего времени команды. И это уже более весомый аргумент, к которому можно обращаться в спорах — он имеет прямое влияние на продуктивность работы в отличие от опоздания на 15 минут.
TL;DR или «Почему вам не нужны Junior-разработчики»
- Джунов надо готовить. Нужно иметь чёткий лист прохождения, хотя бы на первый месяц. Вам не нужны Junior-ы, если вы не можете формализовать базовые процессы. Нужно не врать себе и чётко знать, как будет расти джун, как будет градироваться его зарплата в зависимости от скилов. Вам не нужны Junior-ы, если вы не знаете, как будете их растить.
- Джуны не понимают график. А зачем вам график? Вам не нужны Junior-ы, если вы не знаете, зачем он вам.
- За джуном надо правильно следить (в хорошем смысле этого слова). Вам не нужны Junior-ы, если курировать их работу некому.
- Джуны плохо переносят критику. Будьте аккуратны. Вам не нужны Junior-ы, если вы сторонник дедовщины.
