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