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

Kate

Administrator
Команда форума
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


43471370acc89089688c2669e3cc126e.png

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

Может да, а может и нет, время покажет. Но проблемы выгорания и быстрого ухода сотрудников из 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, то их миксуют вместе и получается задорная команда.
Здесь стоить учитывать основное - по максимуму автоматизируем процесс и стараемся сдвинуть затраты на кого-то другого. ◕‿↼

5cb849382b8e12289d6511b00b907f51.png


 
Сверху