Мы нанимаем только сеньоров
We don«t hire junior developers or interns…if you don«t get a puppy, you don«t have to clean up its messes.
~Netflix
В наши дни одна из самых больших проблем для IT специалиста — начать профессиональную карьеру. Многие из нас прошли путь «первого трудоустройства» и не знаю как вы, а мне довелось услышать такую фразу от рекрутера: «вот когда ты будешь сеньор с зарплатой от $1000 тогда и приходи».
В Российской Империи дворянство решало подобный вопрос весьма прозаично. Детей записывали в армию с самого рождения, поэтому, когда приходило время нести бремя военной службы, детишки уже служили в чинах.
16 лет спустя
Пройдя путь в кровавом энтерпрайзе от джуниора до руководителя проектов в 60(+) человек, я хочу изложить своё видение на вопрос о найме сотрудников без опыта и тех нюансах, с которыми сталкивается наниматель. Сознательно опущу ряд деталей, иначе эта статья рискует разрастись в огромное чтиво, а зовут меня не Фредерик Брукс.
Ай нет
Начнём с отговорок, которыми унижают себя менеджеры и компании:
Мы нанимаем топ рынка. Не тешьте себя иллюзиями, возможно вы нанимаете хороших и отличных специалистов, но проблемы найма топа уже обсуждались не раз и не два. (блог Joel Spolski)
Bring on strong people who already have a good amount of experience who can fully own an area themselves and pay them much better than their competitors would (at least in salary terms). (Netflix) — Политика компании — нанять топ людей чтобы они сами маслали вёслами. Я с уважением отношусь к компании Netflix и сам периодически смотрю их сериалы, но как по мне это выглядит как пирамида на галере. Рухнет?
Может да, а может и нет, время покажет. Но проблемы выгорания и быстрого ухода сотрудников из Netflix уже обсуждались.
Типичное:
У нас нет ресурсов\времени для найма\обучения джуниоров.
У нас нет шанса допустить ошибку, ставки слишком высоки.
Нам необходимо сделать базовый продукт до того, как нанимать людей без опыта.
Зачем мне это надо?
Какие плюшки вы с этого как проектный менеджер получаете:
Положительную репутацию со стороны сотрудников. Вы не морозите людей вечно, а в случае необходимости ротируете их в разумные сроки.
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, и подготовка кадров помогает справляться с кадровым голодом.
Улучшаете мотивацию сотрудников.
Ваши сотрудники понимают, что есть механизм ротаций и когда освобождается та или иная позиция, высока вероятность что эту позицию займёт кто-то из существующих и эффективных сотрудников. Это решение для вас как для руководителя обойдётся дешевле в сравнении с внешним наймом кота в мешке. Как-нибудь отдельно мы проговорим за Succession Planning.
Инженеры занимаются задачами, соответствующими их уровню. Очень часты ситуации, когда нанимают сеньора и дают ему примитивную, монотонную работу, которая никак не применяет и не развивает его навыки. Думаете долго такой человек у вас проработает? Наймите лучше джуна.
Эффективно решаете проектные проблемы. У вас есть пул людей, поэтому вы в противоположность вашим коллегам решаете ваши проблемы самостоятельно, а не вечно ноете и срываете сроки, разводя лапками.
Всё вышеизложенное зачастую положительно сказывается: на вашей финансовой компенсации, карьерном росте и в случае outsource’a положительном отношении к вам заказчиков.
Здесь важно отметить, что вам понадобится поддержка руководства и его заинтересованность в вопросе найма людей без опыта.
Поэтому давайте разберём что получает компания\бизнес:
Положительная репутация. На самом деле это огромный плюс в репутацию компании — найм людей без опыта. Сотрудники, которых компания взрастила или наняла без опыта в самом начале карьерного пути, намного лояльнее относятся к компании, чем нанятые и опытные сотрудники.
Решение кадровых вопросов. У вас есть люди для роста и развития бизнеса. Закроете вы вопрос полностью или частично — зависит от ваших аппетитов и скорости роста бизнеса.
Уменьшение издержек. В 90% случаев люди с более низким тайтлом наиболее маржинальны, чем люди с более высоким. Как раз поэтому и существует понятие Seniority Pyramid’а, а не перевёрнутая пирамида, ромбик и прочее непотребство. Плюс надо считать маржинальность сотрудников, большое количество дорогих сотрудников с низкой маржинальностью — не лучшая ситуация. Для примера обратимся к одному порталу с ЗП в нашем регионе (информация взята из открытого источника, почему-то в выборке нет позиции senior, поэтому для ориентира взял через позицию — lead):
Js. SE ~ $690
Lead SE ~$3650
Как видим ЗП отличается в 5 раз, поэтому даже учитывая разницу в rate card (очевидно, что за джуна платят меньше), маржинальность на более дорогих профессионалах ниже. Почему не нужно забивать весь проект полностью джунами или полностью сеньорами, рассмотрим чуть ниже.
Проблемы
Утилизация. Людей без опыта сложнее утилизировать. Зачастую сталкиваются с ситуацией, где все хотят сеньоров с вот такущим списком знаний и умений. Никто не знает зачем, но очень надо.
Staffing и Seniority Pyramid’а. Одни джуны в проекте — плохо, не вывезут. Слишком матёрая и звёздная команда — на старте хорошо, в более поздних стадиях плохо, им станет скучно и скорее всего «передерутся». Мне несколько раз доводилось наблюдать со стороны когда на проекты набирались минимум сеньоры, как итог вместо разработки постоянные разборки в стиле чей код лучше и какой паттерн подходит в тот или иной ситуации, но не обсуждение бизнес фичей и их имплементация.
Отсутствие наставников и менторов. Как правило людям нравится обучать других, особенно если: это поощряется финансово, не отнимает очень много времени и непосредственное руководство не против.
Финансовую составляющую решить, как правило не представляет проблемы: есть различные, прекрасные инструменты квартальных\полугодовых\годовых бонусов, можно найти и другие способы, оглянитесь по сторонам их множество.
Время наставников — с этим сложнее, нужно подбирать людей, которым это интересно или которые хотят строить карьеру. Это является прекрасным способом для карьерного развития — столько раз объяснял, что сам всё понял© -, но не стоит заставлять людей или активно забирать их личное время — выгорят и уйдут.
Интересная ситуация с непосредственным руководством — иногда тимлиды бывают против, мотивируя тем, что упадёт производительность отдельного сотрудника, да и вообще Баба Яга против. Лечится по-разному: бывает достаточно объяснить зачем это нужно компании, проекту, сотруднику. Если человек продолжает упорствовать, можно «скрутить в бублик»©. Вы спросите: «поменять тимлида на джуна без опыта, чел, ты совсем кукухой поехал?». Теперь внимательно следим за руками — как показывает практика если Баба Яга против, то такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах — хороший маркер чтобы присмотреться к сотруднику. Поэтому по итогу: такой лид не выбирается наставником, ангажируем кого-то другого, а за лидом пристальный надзор.
Не переусердствовать. Этот пункт упоминается выше, но подчеркну его ещё раз. Не заставляйте насильно людей и не навязывайте им наставничество. У человека должен быть отклик в душе, заинтересованность чтобы этим заниматься. Предлагайте, мотивируйте.
Как строить процесс
На самом деле многое придумано до нас. Берём за основу модель обучения для людей без опыта — те же университеты, 4–5 лет нам не надо, поэтому ужимаем продолжительность под наши нужды и программу.
Выставляем критерии для входа (например):
Согласно списку критериев ранжируем людей и отсеиваем.
Тестовое? Я не сторонник тестовых заданий для собеседований, когда нужно писать долго и муторно до того, как позовут на собеседование. Но для людей без опыта тестовое — хороший инструмент, он позволяет:
Понять, насколько человек работоспособен.
Понять человеку что он будет делать и насколько это ему подходит.
Обучаем. Как правило занятия делятся на теорию и практику (лекции и лабы, всё как в университете).
Проверка. Рекомендую проверять как в процессе, так и делать финальную проверку. Например, насколько вовремя человек сдаёт практические занятия и затем выдать какое-то тестовое финальное задание над которым нужно попыхтеть некоторое время.
Успешно прошли все этапы? Отправляем причинять непоправимую пользу.
Дальше уже можно тюнинговать этот процесс:
Иногда делают несколько циклов обучения. Например, человек обучается писать код, потом его доучивают под определённый проект, такой удлинённый onboarding. И обе эти фазы они похожи, различаются: программы и наставники.
Знаю, что есть компании, которые используют различные сервисы для изначального отбора или вместо входного тестового — тот же codewars. Кто-то активно сотрудничает с различными платными и не очень обучающими курсами и вытягивает людей оттуда с минимальной доводкой, кто-то организует свои собственные курсы и готовит людей от и до.
Людей очень часто объединяют в команды и ознакамливают со SCRUM’ом для выполнения практических заданий в ходе обучения.
Если готовят по нескольким направлениям — Dev+QA+BA, то их миксуют вместе и получается задорная команда.
Здесь стоить учитывать основное — по максимуму автоматизируем процесс и стараемся сдвинуть затраты на кого-то другого. ◕‿↼
Отчасти тема уже затрагивалась в моём канале и многие начинают менять свой подход.
