Как построить систему найма, когда ее у вас нет и еще и удешевить

Видели ли вы глаза HRD, когда ему говорят, что надо вырасти в два раза за полгода? В компании 200 разработчиков, а через полгода должно быть 400. А Артур Дементьев видел.

Артур — не HR. Он не будет говорить про корпоративный дух, как правильно писать вакансии и делиться пошаговым планом «Как построить систему найма за две копейки и 7 дней». Артур опишет несколько историй и поделится несколькими советами, над которыми придется задуматься. Например, о том, как можно не нанимать людей и уже на этом сэкономить.

Об авторе.

За 18 лет в IT прошел от рядового разработчика до СТО.

Уже 18 лет в IT. Начинал в 2007 с программирования микроконтроллеров. В 2009 перебрался в web, работал как в больших холдингах, так и в небольших компаниях и стартапах в таких сферах как: медиа, gamedev, e-commerce, медицине, финтех и т.д. Имеет опыт работы со сложными проектами, с большими нагрузками, ИИ и blockchain. Последние 9 лет занимается управлением команд в роли руководителя разработки. В роли СТО строил с нуля крупный российский агрегатор б/у запчастей. Руководил разработкой в крупном российском кредитном брокере Директ Кредит. Был CTO крупного проекта, работающего в сфере ЖКХ (умные дома). А также работал СТО в международном fintech проекте.

Примечание. Далее повествование идет от лица Артура.

Давайте поговорим сначала...

Есть несколько типовых сценариев.

№1. Мы что-то не успеваем.

Тогда прибегает бизнес с криками «Нам нужно запилить какую-то фичу, давай, давай, быстрей, быстрей». Поддаешься панике, пытаешься, вся команда пыжится, ожидаемо не получается. И что говорит бизнес? «Ладно, давай, набирай еще людей»

№2. Мы просто растем, например, запускаем новый продукт.

Здесь всё аналогично: «Давайте наберем людей, сейчас быстро все запустим». К сожалению, бизнес забывает, что когда у нас есть два человека — это одна связь. Когда добавляется еще один — это, как минимум, три связи. Когда людей все больше и больше — связи растут в прогрессии, как и сроки и сложность работы. Математической или геометрической — вам решать.

№3. Людьми затыкаются проблемы.

Была в моей практике такая история, когда мы не могли получить нормально ТЗ от бизнеса и такие «А давайте-ка наймем аналитика, он нам ТЗ и найдет?» Конечно, это не работает, потому что если его никто не может вытащить, то и «святая корова» не найдет решения. Такого быть не может.

В заголовке статьи есть слово «удешевить». Так вот, как удешевить процесс найма? Для начала — не нанимать. Это одна из самых умных мыслей, которые мне встречались.

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

Например, писать меньше кода.

Вот приходит к нам бизнес и говорит «Запили мне фичу». А как много, так скажем, бизнесов вообще проверяет идеи? Делают ли они MVP? Проверяют ли они идеи на фокус-группах? Мы можем написать код, выкатить в продакшн, а фича может быть вообще не стрельнет.

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

Второй способ — рефакторить.

После релиза у нас появляется техническая дока и нам нужно рефакторить. Был у меня один случай, когда нам нужно было просто добавить два поля в отчет. Вроде как простая задача, ничего сложного, но вылилась в то, что нам пришлось писать код 2 месяца. Два поля и два месяца, Карл! Ну как это вообще может быть?! Это вообще полная жесть…

Еще один способ не нанимать — работать с процессами.

Представьте, что вы маленькая компания. У вас буквально десять человек и вдруг вы начинаете расти. Понятно, что процессы нужно менять. Но что делают в индустрии? Смотрят на большие компании, которые в случае роста, набирают народ. И тогда начинается натягивание процессов большой компании на маленькую, в надежде, что вот сейчас взлетит. Только почему-то не взлетает.

А бывает, что вообще на процессы забивают. Вот представьте, что сидит нас в офисе 20 человек, а нам нужно нанять ещё 40. Но помещение не рассчитано на 60 человек. Ситуацию с помещениями все понимают, но почему-то с процессами такого не происходит, все думают, что оно как-то само разрулится и офис сам вырастет.

И последний способ — понять, почему же уходят люди?

Мало кто задается этим вопросом.

Вообще-то, для нанимающего менеджера уход человека не должен быть каким-то неожиданным событием. Это и есть его работа — знать, кто, когда и почему уволится из компании. Последние года три или четыре я знал каждого разработчика, который хотел уйти. Я знал, что он пойдет на собеседование еще до того, как его куда-то пригласят. Поэтому я мог играть на опережение: сделать контроффер, предложить более интересную работу или другую команду и т.д.

А как так делать?

У нас есть инженер, у него есть руководитель — тимлид и, по сути, именно он должен заниматься людьми. Моя парадигма в том, что любой руководитель это 10-20% процентов на инженерные задачи, а все остальное — это люди и общение с ними. Руководитель должен строить доверительные отношения и знать боли сотрудников, так, чтобы разработчик мог прийти и сказать «Я хочу попробовать такой-то язык» И получить такую возможность. Например, один раз я узнал, что сотрудник ходит в театральный кружок и понял, что из него можно вырастить тимлида. Про то, что я знаю как зовут собак моих разработчиков, можно не говорить.

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

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

Важный нюанс. Руководитель не должен мешать работу и личное. Условно говоря, тимлид не психоаналитик. Пример: был у меня хороший разработчик, с ним было все окей. Потом раз — он стал хуже писать код. Выяснилось, что приехала теща и затеяла ремонт. Естественно, настроение испортится — после работы еще работать. Как решилась проблема? Довольно просто — я предложил его в командировку отправить. Он сразу стал веселым, настроение улучшилось.

К чему я это? Руководитель знает проблемы и боли сотрудника, но в них не лезет. Руководитель просто общается с людьми и решает проблемы, чтобы им спокойнее работалось. А если вы полезете в его подкорку, начнете разбираться, то станете другом/братом/сватом. Это все плохо кончается. Вы руководитель — держите границы. Как так делать не расскажу — все познается на опыте.

Тогда и нанимать надо меньше, если у вас текучки почти нет. Но почему я сразу вам начал советовать не нанимать? Да потому что найм — это дорогое удовольствие.

Найм — это дорогая штука. Я думаю все об этом и так знают, но я повторю.

Для начала, в найм входят накладные расходы — офис, компьютеры, скрепки-бумажки и прочее.

Далее в стоимость найма входит фонд оплаты труда (ФОТ), людей, которые должны помогать этому процессу: HR, нанимающих менеджеров, деврелов и т.д.

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

Например, если тимлид не очень нацелен проводить адаптацию и новым сотрудником никто не занимается, он там сидит месяц один, то в какой-то момент он себе (или тимлиду) скажет — «Да не, фигня какая-то, а не компания, пошел я дальше». И все эти деньги, которые вы потратили на его найм, вылетают в трубу.

Приведу историю из жизни про деньги. Как-то компания, в которой я работал, получила деньги на развитие. Бизнес радостный приходит и говорит — «У нас появились деньги — нам нужно расширяться! А давайте-ка вырастем в два раза за полгода» Ну, клево, конечно…Но в два раза за полгода значит, что если вас было 200, то вам надо сделать 400. Если у вас не было такой ситуации, то HRD в этот момент выглядит вот так.

Просто HRD провел нехитрые математические расчеты и понял, что 200 человек за за полгода означает, что ему надо нанимать 2-3 человека в день! Это жесть.

К чему это приводит? Это приводит к хаосу без какой-либо стратегии. Растут все отделы: HR, потом разработчики, потом DevOps, потом QA (иногда). Все просто бегут, что-то хватают, куда-то летят в пене — просто фильм про апокалипсис. О каких-то умных действиях говорить не приходится.

Что было дальше?

Но самое прекрасное — в конце. Когда вместо 200 мы наняли 20, бизнес говорит — «Что-то это не работает, а давайте-ка откатываемся назад» и увольняет всех кого наняли до этого и HR-ов в придачу.

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

На мой взгляд, нужно решить несколько задач.

Давайте пройдемся по пунктам.

Здесь у меня, наверное, посыл к нанимающим менеджерам, потому что они больше знают, чем занимаются их команды (продукты). Может у вас есть суперхардкорная команда и там нужно более жестко рассказывать про технологии и искать более хардкорных программистов? А может у вас какой-то клиентский сервис, где надо больше общаться с людьми?

Я к тому, что мы либо собираем телегу, либо болид гоночный. И от этого многое зависит. Надо четко понимать, какие задачи будут решать сотрудники и какие у них должны быть качества.

У нас есть стек технологий — надо выбрать. Есть какая-то база данных, есть какие-то бек языки программирования, фронт и мобилка.

Как это обычно происходит? Обычно местный менеджер говорит: «Мы же пишем на Scala, давайте наймем скалиста» Все равно, что его на рынке нет, это же проблема «эйчара», не его, верно?

А на самом деле как раз с этой проблемой должны управляться нанимающие менеджеры. Им нужно залезть на рынок и поглядеть — а есть ли такие вакансии, а есть ли такие резюме, а сколько этих резюме, а сколько стоят эти люди? Потом зайти на Stack Overflow и посмотреть сколько там вопросов по технологии, есть ли репозиторий, не сдохнет ли эта технология через полгода, на котором мы собрались что-то делать. Посмотреть, что в сообществах, в чатиках Телеграмма, на том же самом Хабре почитать статейки.

И только вот после этого можно принимать какие-то решения. А не так, что «Давайте наймем такого-то разработчика, ну и что, что на рынке его нет — значит HR недорабатывает» Ну тогда сорян, в этом случае наши компетенции всё.

Теперь посчитаем роли и компетенции людей. Пусть для нашего случая их будет порядка 14 человек: архитектор, техлид фронтенда, техлид бэкенда, плюс разработчики, DBA, DevOps, QA, аналитик, PM. Это не мало, так скажем. Что мы можем сделать?

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

Поэтому здесь можно всю эту историю неплохо схлопнуть и не потребуется каких-то сумасшедших усилий.

Хорошо, мы определились кто нам нужен — теперь понять бы…

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

Есть такой фильм, называется «Moneyball». В нем рассказывается о менеджере, который пытается нанять игроков в бейсбольную команду. Там есть такой кадр, где герой говорит, что если мы будем нанимать теми же способами, что и другие команды, то никого не найдем.

Это золотой совет. Как его нам использовать? Изменить подход. Ведь можно красиво упаковать наше предложение, то есть перед тем, как вообще начинать писать вакансию, погрузиться в размышления: кто этот человек, которого мы хотим нанять, какие у него интересы, какие задачи он хочет решать, что ему интересно?

По большей части, в индустрии это мало кто делает — сесть и подумать, что эти люди хотят. Все пишут «Наши преимущества», где список идентичен списку у всех остальных конкурентов:

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

Вот пример вакансии с текстом, что мы растим людей.

После того, как мы добавили эту фразу, на вакансию стали откликаться.

Или у нас люди влияют на разработку и не пашут как винтики в системе: предлагают идеи и, соответственно, их проверяют. Или мы поощряем и оцениваем инициативу сотрудников. Вот, для примера, еще одна из наших вакансий...

Я здесь добавил фразу, что мы делаем серьезный сервис и у нас большие нагрузки. Благодаря только этой маленькой фразе на следующий день я получил 54 отклика. А что такого я сделал? Я лишь написал о том, что мы реально делаем.

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

И мне пришло 23 отклика. Один человек написал, что-то было бы клёво попробовать, но, к сожалению, он не умеет. А что в этом сообщении особенного? А то, что человек сам оценил свои знания, сам понял, что он знает, а что нет — то есть выполнил за меня кучу работы. Вот с ним, как минимум, есть резон пообщаться, потому что, скорее всего, он может нам подойти.

Конечно, в вакансии тяжело показать все дополнительные преимущества, но это можно сделать уже впоследствии, во время беседы. Просто садитесь на диван и начинаете обзванивать кандидатов. Да-да, обзванивать. На фотографии я во время одного из таких звонков.

Я понимаю, что любой нанимающий менеджер технарь и скажет — «Чего садиться-то, кого-то обзванивать» Но вот представьте, что разработчикам, каждый день и пишут и звонят рекрутеры по 100 раз. Ничего нового от них он не узнает и не услышит, никакой внятной информации не добьется. А тут звонит тимлид или руководитель отдела разработки, который может «технически» что-то рассказать. Эффект совсем другой.

И это не требует много времени. Несколько минут вполне достаточно. Зато потом вы сэкономите в разы больше времени.

Теперь чуть подробнее о мысли «кто этот человек, которого мы хотим нанять» Есть такая книжка, которую я прочитал в свое время, она о найме.

Оттуда я взял три категории продуктивных людей.

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

С ними особенно сложно. Условно, такой человек дойдет до вас только каким-то чудом — посмотреть, что за «зверушка» его позвала на собеседование. Как его проводить, если к вам уже такое предвзятое отношение, к тому же человек все знает и сам вас всему научит? Я, например, когда проводил технические собеседования, не спрашивал про паттерны. Смысл? Я просто давал задачки, которые проверяли те же самые паттерны.

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

Знаете, как обычно происходит — вот у нас есть тестовое задание, вот у нас есть список вопросов и все по нему идут. Но это так не работает. Стоит попробовать с человеком просто поговорить, понять, что он знает. Может он реально крутой аналитик? Я, например, часто узнаю, человек занимается искусственным интеллектом. «О, круто, а у нас тут есть проект, ты бы смог им позаниматься?» И все, интерес есть.

Если другим компаниям, извините меня, нас..ть, то вам не должно быть. Вы должны быть готовы поддержать, поговорить, предложить что-то интересное. Именно здесь и проявляются все ваши ваши дополнительные преимущества — вживую, так сказать. И отношение сразу другое.

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

Выставляю там оценки (после собеседования что-то может забыться, а пометки в таблице останутся)

На что можно обращать внимание?

Если хотите быть лучшим — выбирайте лучших.

Стандартные слова. Но все забывают, что тот же самый нанимающим менеджер должен отвечать за рост людей. Соответственно, он должен видеть барьеры, понимать, как их снимать и что делать, чтобы люди стали расти. Опять же, пришел к вам фронтендер, который чуть-чуть знает DevOps. Да это вообще не проблема — я его возьму и доращу. Это такой же навык, как писать код, в этом нет ничего сверхсложного.

Главное, что потом вы таким образом сможете масштабировать найм

Раз за разом я наблюдаю как компании не дают людям фидбэк. Это очень плохо.

Более того, обратную связь надо снимать в обе стороны (как в примере выше). Если вам отказывает кандидат, надо за ним бежать и уговаривать его рассказать, что ему не понравилось, а почему он к нам не хочет и т.д. Это очень важная штука и этим вообще мало кто занимается.

Понятно, что есть хедхантер и другие агрегаторы. Это все стандартно и не очень интересно.

А интересное — это нетворкинг.

Развивайте ваш нетворкинг. Это инвестиция в вас самих, потому что чем больше вы общаетесь в тех же самых чатах, тем больше у вас знакомых. Вы можете кому-то помочь — вам могут помочь.

Нужно дружить с HR.

У меня были случаи, когда я HR-ам просто бесплатно «подгонял» людей. Просто они нам не подходили и я их рекомендовал коллегам. Через какое-то время мне нужен был человек, я просто написал знакомому HR, она мне предложила человека и я не заплатил вообще ни копейки. Всем хорошо: и кандидат будет вам благодарен, что получил работу, и вам опять же могут подкинуть разработчика потом.

Не забываем о профессиональных сообществах (также в Телеграм чаще всего).

Там можно найти множество разных разработчиков и инженеров. Но если вы там не общаетесь и вкидываете вакансию, то вас просто забанят, если вас никто там даже не знает.

Поездки на конференции и митапы.

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

Пиарьтесь

Я как-то написал одну из статью на Хабре и после этого мне в личные сообщения написал человек: «А можно я у вас поработаю, может у вас есть все вакансия?» Так что это один из крутых инструментов.

Студенты

В 2016 году я пришел в ВУЗ, в котором раньше учился, и просто с порога: «Не могли бы вы дать нам студентов? Может быть вам нужна практика?» И мы договорились — мне поставляли студентов.

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

ИС — самая клевая штука, которую придумало человечество. На нем можно реально проверить человека.

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

Нюанс. Вам НЕ НУЖНО держать кандидата два-три месяца на ИС. Понять человека можно и за неделю, и за день. Более того, «готовые» разработчики и не будут сидеть на ИС три месяца. И три недели не будут. И неделю не будут. Мы не будем выгонять его на тестовую неделю, это абсурд. Всё, что у нас есть — один-два тестовых дня, когда мы можем его «опробовать». Поэтому воронка и должна быть большой.

А что делать, если у кандидата опыта мало, а азарта много? В этот момент можно сделать такие штуки.

Я, в принципе, пробовал всё.

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

Сдельная работа — что-то похожее на работу за опыт, чуть получше, но тоже работает через раз.

А вот тестовая неделя работает лучше всех. Я так однажды нанял порядка 8 человек из других областей, среди которых были менеджеры и один строитель. Просто предлагал — «Возьми больничный, приди к нам, попробуй поработать. Ты, как разработчик, еще не готов, но вот мы готовы тебя взять. Хочешь — попробуем?» И вот так люди приходили. Вполне нормальный кейс.

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

Все тестовые периоды, естественно, должны оплачиваться. Никто не запрещает сделать договор ГПХ на какое-то время. Мы предлагали кандидату взять больничный, а тестовое время оплачиваем по договору, если он не хочет сразу увольняться. Можно и без ГПХ, договориться на словах, но все должно быть честно оплачено. Если уж вы на этом этапе соврете, то 100% доверия дальше не будет.

Мало того, за ИС можно считать онбординг. И неважно — большая компания, маленькая компания, в любом месте должен быть онбординг. Условно говоря, пришел разработчик, а у вас нет документации. «Вот сядь изучи модуль — напиши документацию». Уже польза для компании — вы уже проверите, может ли он читать код. Либо сделайте ему тестовую среду, где он сможет покопаться в Git ,сделать какие-то pull request’ы и так далее. В этом нет вообще ничего сложного.

Банально, но ее нужно проводить.

Вот есть нанимающий менеджер, есть HR, и они должны вместе садиться и начинать думать. Например, к нам пришло много людей почему-то совсем по другому языку программирования, нежели тот, что нам нужен. А почему так произошло? А может вилка не та? А может канал не тот? Если мы подумаем, вместе сядем и сменим канал, то уже это может нам принести, допустим, 20 откликов вместо 2-х. Аналитикой нужна серьезно заниматься.

У нас нанимающий менеджер и HR садились вместе и приходили к какому-то консенсусу. Например, есть какая-то итерация, когда две недели у нас поток из людей. Соответственно, после мы начинаем смотреть метрики: сколько людей пришло, сколько не подошло под вилку, сколько не подошло по технологиям и так далее. Вместе сидим и об этом разговариваем. При этом у нас нет ни KPI, ни SLA, мы просто разговариваем. Я вообще не верю в KPI в найме — обычно это все ведет к колоссальному фэйлу.

Но, к сожалению, чаще всего почему-то мы все разрозненные: HR выполняет свою задачу, менеджер — свою. Это мне не очень понятно, конечно, ну да ладно.

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

Ну и нужно строить систему. Я рассказывал про все эти лайфхаки и штуки. Но их нужно делать не когда уже пришел бизнес и «Всё, растём в 2 раза». Это нужно делать сейчас. Вы должны с деврелом договориться провести какие-то митапы, сделать систему онбординга, и много-много всего. И прямо сейчас. Даже если вы, опять же, небольшая компания, что вам мешает, условно, выступать на тех же самых конференциях, что-то рассказывать, писать? Вопрос, скорее, желания.

В конце маленький лирический вывод. Я понимаю, что у нас на рынке как бы нет людей, тяжело найти и прочее. На самом деле люди есть. Я верю, что среди сотни рассмотренных кандидатов можно собрать отличную чемпионскую команду человек на 10-20, которые нам по карману.

Многие забывают, что наша задача не в том, чтобы отсмотреть 1000 человек, а нанять 10

Контакты Артура

Если хотите сэкономить время — заходите на headz.io. Мы сужаем воронку, показываем только тех кандидатов, которые подходят под ваш профиль по стеку технологий, форме занятости и заработной плате.