Мы нанимаем только сеньоров

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

image-loader.svg

В наши дни одна из самых больших проблем для 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 и сам периодически смотрю их сериалы, но как по мне это выглядит как пирамида на галере. Рухнет?

image-loader.svg

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

  • Типичное:

    • У нас нет ресурсов\времени для найма\обучения джуниоров.

    • У нас нет шанса допустить ошибку, ставки слишком высоки.

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

Зачем мне это надо?

Какие плюшки вы с этого как проектный менеджер получаете:

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

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

  • Улучшаете мотивацию сотрудников.

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

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

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

Всё вышеизложенное зачастую положительно сказывается: на вашей финансовой компенсации, карьерном росте и в случае outsource’a положительном отношении к вам заказчиков.

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

Поэтому давайте разберём что получает компания\бизнес:

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

  • Решение кадровых вопросов. У вас есть люди для роста и развития бизнеса. Закроете вы вопрос полностью или частично — зависит от ваших аппетитов и скорости роста бизнеса.

  • Уменьшение издержек. В 90% случаев люди с более низким тайтлом наиболее маржинальны, чем люди с более высоким. Как раз поэтому и существует понятие Seniority Pyramid’а, а не перевёрнутая пирамида, ромбик и прочее непотребство. Плюс надо считать маржинальность сотрудников, большое количество дорогих сотрудников с низкой маржинальностью — не лучшая ситуация. Для примера обратимся к одному порталу с ЗП в нашем регионе (информация взята из открытого источника, почему-то в выборке нет позиции senior, поэтому для ориентира взял через позицию — lead):

    • Js. SE ~ $690

    • Lead SE ~$3650

    Как видим ЗП отличается в 5 раз, поэтому даже учитывая разницу в rate card (очевидно, что за джуна платят меньше), маржинальность на более дорогих профессионалах ниже. Почему не нужно забивать весь проект полностью джунами или полностью сеньорами, рассмотрим чуть ниже.

Проблемы

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

  • Staffing и Seniority Pyramid’а. Одни джуны в проекте — плохо, не вывезут. Слишком матёрая и звёздная команда — на старте хорошо, в более поздних стадиях плохо, им станет скучно и скорее всего «передерутся». Мне несколько раз доводилось наблюдать со стороны когда на проекты набирались минимум сеньоры, как итог вместо разработки постоянные разборки в стиле чей код лучше и какой паттерн подходит в тот или иной ситуации, но не обсуждение бизнес фичей и их имплементация.

  • Отсутствие наставников и менторов. Как правило людям нравится обучать других, особенно если: это поощряется финансово, не отнимает очень много времени и непосредственное руководство не против.

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

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

    • Интересная ситуация с непосредственным руководством — иногда тимлиды бывают против, мотивируя тем, что упадёт производительность отдельного сотрудника, да и вообще Баба Яга против. Лечится по-разному: бывает достаточно объяснить зачем это нужно компании, проекту, сотруднику. Если человек продолжает упорствовать, можно «скрутить в бублик»©. Вы спросите: «поменять тимлида на джуна без опыта, чел, ты совсем кукухой поехал?». Теперь внимательно следим за руками — как показывает практика если Баба Яга против, то такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах — хороший маркер чтобы присмотреться к сотруднику. Поэтому по итогу: такой лид не выбирается наставником, ангажируем кого-то другого, а за лидом пристальный надзор.

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

Как строить процесс

На самом деле многое придумано до нас. Берём за основу модель обучения для людей без опыта — те же университеты, 4–5 лет нам не надо, поэтому ужимаем продолжительность под наши нужды и программу.

  • Выставляем критерии для входа (например):

  • Согласно списку критериев ранжируем людей и отсеиваем.

  • Тестовое? Я не сторонник тестовых заданий для собеседований, когда нужно писать долго и муторно до того, как позовут на собеседование. Но для людей без опыта тестовое — хороший инструмент, он позволяет:

    1. Понять, насколько человек работоспособен.

    2. Понять человеку что он будет делать и насколько это ему подходит.

  • Обучаем. Как правило занятия делятся на теорию и практику (лекции и лабы, всё как в университете).

  • Проверка. Рекомендую проверять как в процессе, так и делать финальную проверку. Например, насколько вовремя человек сдаёт практические занятия и затем выдать какое-то тестовое финальное задание над которым нужно попыхтеть некоторое время.

  • Успешно прошли все этапы? Отправляем причинять непоправимую пользу.

Дальше уже можно тюнинговать этот процесс:

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

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

  • Людей очень часто объединяют в команды и ознакамливают со SCRUM’ом для выполнения практических заданий в ходе обучения.

  • Если готовят по нескольким направлениям — Dev+QA+BA, то их миксуют вместе и получается задорная команда.

Здесь стоить учитывать основное — по максимуму автоматизируем процесс и стараемся сдвинуть затраты на кого-то другого. ◕‿↼

image-loader.svg

Отчасти тема уже затрагивалась в моём канале и многие начинают менять свой подход.

© Habrahabr.ru