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

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 лет нам не надо, поэтому ужимаем продолжительность под наши нужды и программу.

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

  • Нужно ли нам наличие каких-то базовых знаний?

  • Насколько нам важна быстрая обучаемость?

  • И т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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