Исправляем ошибки при поиске джуна

Ожидания техлида

Давайте разберемся, кто создает описания вакансий. Их создают техлиды. Основная проблема в том, что каждый техлид хочет видеть в соискателе самого себя. То есть берет свой опыт, отнимает от него 5-6 лет, берет свой багаж технологий, отнимает от него то, что за эти 5-6 лет совершенно устарело, и вуаля — готовы требования к кандидату.

Получается нереалистичный портрет: перспективный джун с опытом работы не менее 10-12 лет, со знанием PHP, JavaScript, .NET, Python и с желанием выучить GoLang. После этого добавляется английский, знание процессов и методологий гибкой разработки. И как вишенка на тортике — «большим плюсом будет» — опыт работы с BigData, опыт в создании нейронных сетей и т. д. Так гордо вырисовывается пунктиром портрет вашего техлида, помолодевшего на 5 лет и не отягощенного знаниями COM, VisualBasic и WinForms.

Когда рекрутер получает такую заявку, можно предположить, что волосы у него на голове встают дыбом. Потому что, если и есть такой человек, то это — Толик из R&D, который составил описание требований и который уже работает у нас.

Потом рекрутер бежит к проектному менеджеру, к которому будущий джун пойдет работать. И менеджер уверенно заявляет рекрутерам: «Такие люди есть, и их много, вы просто плохо ищете».

Зреет напряжение в команде

Теперь мы перемещаемся на два-три месяца вперед. Поиск кандидатов не принес желаемых результатов. Проектный менеджер давит на рекрутеров, потому что они плохо ищут. Всем рекрутинговым агентствам были обещаны большие бонусы. Техлид, который составлял вакансию, рассказывает, что в его время и народ был смышленее, и деревья выше. А проектная команда или овертаймит, или ставит многие проектные активности на паузу.

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

Что нужно сделать?

Надо разбираться, что мы делаем не так. Как можно выйти из тупика, который не выгоден никому. В этой ситуации все находятся в проигрыше: перспективный кандидат не может найти работу, разработчики не могут удовлетворить всех потребностей заказчика, команда не может нормально функционировать, так как у ее членов совершенно нет времени. Конечно, можно пойти по пути «сильных» людей и обвинять в своих несчастьях кого-то третьего или списать все на конъюнктуру рынка, но мы не будем так делать и разберемся, что команда делает не так.

Исправляем ошибки

1. Нужно описывать не того, кого хочется нанять, а обязанности, которые будет исполнять тот или иной работник. Если нам нужен формошлеп, то не стоит писать в требованиях «большим плюсом будет знание теории нейронных сетей». Нет, я не предлагаю снизить планку. Но планка прохода должна быть снижена до приемлемой величины, и задирать ее не имеет смысла — можно потерять очень хороших перспективных кандидатов.
2. Необходимо организовать разговор между проектным менеджером и техлидом. Техлид должен осознать, что если не будет нового джуна, то ему придется делать все самому. И сам он не успеет сделать всего намеченного, потому что у него есть семья или личная жизнь, хобби и планы на отпуск. Да, он может описать своего идеального кандидата. И рекрутеры могут параллельно с низким приоритетом искать этого супермена. Но полагаться на такую позицию нельзя ни в коем случае, так как ее закрытие — дело случая. А все, что связано со случайностями, а не четким процессом, нам в бизнесе не подходит.
3. Необходимо поговорить с рекрутерами. Может, ищут не по тем критериям? Может, стоит показать пару-тройку страниц LinkedIn, по всем параметрам подходящим под требования? Может, стоит рассказать, кого еще мы можем рассмотреть, чтобы расширить поле поиска. Разработчикам нужно осознать, что IT-рекрутеры, какие бы толковые они ни были, не обладают тем бэкграундом, который позволил бы им расставить допуски в поиске кандидата.
4. Необходимо мыслить стратегически. Может, стоит взять кандидата на вырост? Может, кому-то стоит дать шанс? В некоторых случаях можно пойти на минимальный риск. Если вы видите, что человек адекватен, ему интересен ваш проект и он полон желания работать, то почему бы и нет. Попробуйте, по крайней мере, у вас всегда есть в запасе испытательный срок. Да этим не стоит злоупотреблять, но и пренебрегать этой возможностью тоже не стоит.

Выводы:

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

Больше об искусстве поиска и удержания сотрудников рассказывают на онлайн обучении HR.