В недавнем докладе я рассмотрел многое из этой статьи и предложен вариант бесконфликтного постепенного улучшения процесса найма.
Материалы доклада:
Изначально наём — проблема.
Часто говорят, что разработка не справляется с реализацией запросов бизнеса.
Но:
При хорошем анализе может оказаться, что бизнесу не нужна значительная часть реализуемого функционала.
Тут еще можно заметить, что чаще всего бизнес-стратегия экстенсивного (вместо интенсивного) роста — ошибка.
Но предположим, весь задумываемый функционал действительно нужен, и разработка не справляется с его реализацией.
Почему так? Чаще всего потому что:
Чаще всего проблемы есть в процессах взаимодействия, с навыками анализа и синтеза, если совокупно — с навыками построения и поддержки социально-технических систем.
И по опыту тут еще можно оптимизировать разработку значительно. И потом ещё запустить процесс быстрой валидации бизнес-гипотез — и оптимизировать еще значительнее.
Ключевой вопрос для самопроверки — сколько фичей в вашем продукте удаляется за год? Если нисколько, то почему? Используются ли они пользователями, приносят ли эти фичи деньги? Если нет, то почему вы платите за их поддержку?
Также наверняка:
Часто найм осуществляется оттого, что люди массово уходят. Или живут в компании очень мало.
В такой ситуации найм людей — ухудшение ситуации, потому что у руководителей укрепится ощущение, что можно всё больше набирать людей, и всё «под контролем».
При наличии всех трёх вышеописанных проблем найм новых людей также приводит к увеличению управленческой сложности в ведении команды и удорожанию работы команды.
Например, при высокой текучести сотрудников и постоянном перенайме приходится тратить раз за разом время на собеседования и адаптацию новых сотрудников. А также ухудшается бренд-имидж компании.
Предположим, что все проблемы вышеописанные решены, но разработка все же не справляется. Хочется нанять людей, но:
Если нужен «синьор», то почему полгода назад не взят «мидл» и не доучен до «синьора»? Обучение однозначно дешевле найма готового специалиста.
Если нужен «мидл», то почему полгода назад не взят «джун» и не доучен до «мидла»?
Понятно ли, что в случае с «джунами» найм и последующее обучение дешевле, а лояльность и среднее время работы такого сотрудника выше, чем в случае любых других?
Предположим, что все эти меры приняты, но нужен-таки новый специалист, которого в компании просто-таки некому учить.
Казалось бы, пора идти и нанимать с рынка, но:
У обычного разработчика в среднем от 30 до 100 контактов с коллегами-разработчиками, трудоустроенными в других компаниях.
У тимлида контактов должно быть больше. Если их меньше, ему стоит работать над нетворкингом.
Среднее время работы сотрудника в компании в индустрии составляет в лучшем случае два года.
Итого, при размере команды в 5 человек и 1 тимлид, получается от 180 до 600 контактов в прямом нетворке команды.
Посчитайте, сколько в среднем в месяц людей из этого нетворка ищет работу.
Вопрос: что мешает этих разработчиков нанимать себе? Ведь ребята из нетворка гораздо с большей вероятностью будут более лояльны. Конечно, при условии, что тимлид адекватный и текучесть у него не дикая.
Можно свести простую арифметику и посчитать цену найма с рынка, поднять статистику времени найма с рынка в прошлом и подумать, отчего же ещё не используется столь простой инструмент, как найм из нетворка?
Может, не решены проблемы 1-2-3-4? Может, тимлид у вас «играющий тренер» и не имеет возможности заниматься своей прямой обязанностью — управлением командой?
Может, компании проще тратить кучу денег на найм и адаптацию все новых членов команды при высокой текучести сотрудников? Может, от такого тимлида сотрудники постоянно уходят?
Ну и ещё можно посчитанную цену найма, зарплату рекрутера и стоимость доступа к HeadHunter использовать более грамотно — например, выдавая часть её в виде referral bonus за привод знакомых?
Чаще всего уже на этом этапе выясняется, что подбор с рынка не нужен. Ну и заодно риск найма сотрудника, который не подойдет, станет сильно ниже.
Ещё на этом этапе чаще всего становится кристально ясно, сколько вам всего в отделе нужно менять до найма кого-то.
Но опять же предположим такую маловероятную вещь, что все же нужен подбор с рынка.
И тут возникают следующие проблемы:
Тимлид пишет какой-то список «технологий, с которыми предстоит работать», отдаёт рекрутеру, и тот начинает со всех возможных каналов поиска формировать максимально большую воронку.
Понятное дело, рекрутер на этом этапе ничем не помогает тимлиду в составлении описания работы, максимум, что он сделает — добавит общую информацию о компании.
И мы видим огромные кучи одинаковых бессмысленных сообщений от рекрутеров во всех возможных каналах.
Дальше рекрутер передаёт тимлиду максимально большой список резюме, которых посчитал подходящими под «список технологий» тимлида (возможно, после некоторого «скрининга» кандидатов).
Первая фаза борьбы рекрутера с собственноручно созданными проблемами — «скрининг» кандидата. Рекрутер понимает, что собранная им куча резюме не нужна тимлиду, ведь ему нужно закрыть одну в акансию, а не 100. И рекрутер начинает придумывать, как этот список сократить.
Выбирая чаще всего наиболее бессмысленный вариант:
Рекрутер просит тимлида «составить чек-лист вопросов», иногда составляет их сам. В любом случае рекрутер, будучи неквалифицированным в специальности, на которую нанимает, не может верифицировать соответствие ответов правильности — все, что он может — совершить работу, которую может решить и скрипт — сравнить эталонный ответ на вопрос из списка и ответ кандидата.
Ещё иногда рекрутер придумывает «проверку софтскиллов». Формирует какой-то ему одному известный принцип, согласно которому человек может не подойти.
Ну и порой рекрутер творит совершеннейшую дичь — вводит дополнительные способы фильтрации по одному ему известным причинам. Нередко можно слышать про жалкие попытки психотипирования, эйджизм, а порой и использования гороскопов.
К сожалению, порочен:
Даже если предположить, что скрининг рекрутер может провести нормально, зачем он изначально собирает огромную воронку тех, кто будет отфильтрован? Зачем героически собирать огромный список, чтобы потом столь же героически его уменьшать?
А все потому, что:
Мотивация рекрутера почти всегда — закрыть позицию. Буквально единицы рекрутеров, кого я знаю, помимо закрытия вакансий отвечают еще и за адаптацию сотрудников и за их время работы в компании. Также неквалифицированные тимлиды «оценивают» рекрутеров по количеству присланных резюме.
Таким образом рекрутер с самого начала не заинтересован в том результате, который нужен тимлиду — нанять подходящего члена команды, адаптировать его максимально быстро и удостовериться, что он долгое время будет хорошо работать.
В такой схеме натурально произрастает конфликт рекрутера и тимлида — рекрутер возмущён, что тимлид «отбрасывает» присланных ему на собеседование кандидатов, тимлид негодует, что рекрутер «присылает не тех».
Таким образом, в такой схеме работы вы не только неэффективно тратите ресурсы компании, но и создаёте негативные групповые динамики.
Согласно теореме Котельникова рекрутер, являясь дополнительным звеном в схеме передачи информации от тимлида к кандидату, обязательно потеряет часть информации. То есть как бы хорошо рекрутер не «снимал» информацию с тимлида, информация неизбежно будет потеряна.
Занимаются оба какой-то ерундой, а потом удивляются, чего это среднее время жизни сотрудника такое маленькое. Ну или не удивляются, что скорее всего.
Ну а дальше, когда рекрутер прислал кучу резюме тимлиду после своего бессмысленного скрининга, тимлид начинает героически собеседовать всех, дабы «найти лучшего». И этот этап — огромная проблема сама по себе:
Чаще всего собеседование проходит в виде «экзамена», где тимлид (а то и несколько человек) «экзаменуют» кандидата на знание технологий, описанных в требованиях.
Какой смысл имеет знание в отрыве от практики — непонятно.
Выяснить, как сотрудник будет работать, удастся достоверно только на испытательном сроке.
В результате «экзаменационного» собеседования лишь чсв тимлида тешится, потенциально подходящие кандидаты (например, переволновавшиеся на собеседовании) отбрасываются.
Тимлид должен стараться решать проблемы бизнеса минимальными силами. Это — экономически эффективно вследствие более низких трат и меньшей управленческой сложности системы с меньшим количеством людей/компьютеров.
Сотрудник, которому помогли развиться и вырасти по знаниям и опыту будет более лоялен и продуктивен, а следовательно использование роста и развития вместо найма «готовых» — экономически целесообразно.
Также проектирование развития команды вынуждает тимлида больше взаимодействовать с бизнесом и понимать лучше, что нужно компании и когда.
Время закрытия позиции и цена найма при использовании нетворка — ниже. Лояльность привлеченных сотрудников — выше.
Если сотрудники не желают звать своих товарищей и знакомых — это хороший флажок тимлиду, что нужно что-то срочно менять в команде.
Вместо внедрения отдельного звена в виде рекрутера между тимлидом и кандидатами, тимлид пользуется помощью рекрутера как специалиста в составлении EVP и описания того, что предстоит делать новому сотруднику.
Стек — вторичен, задачи — первичны.
Тимлид выбирает типичные задачи, которые предстоит выполнять сотруднику, описывает их. Можно взять прямо из таск-трекера.
Также тимлиду стоит описать команду, в которой предстоит сотруднику трудиться, плюсы и минусы работы именно с ним как руководителем. Чем больше кандидат сможет понять про реальную картину того, что ему предстоит делать, тем лучше.
Цель у EVP / вакансии в максимально честном представлении условий труда. Сильно приукрашивая или описывая откровенную ложь, вы увеличиваете риск того, что кандидат выйдет на работу, ощутит диссонанс и уволится, не успев принести существенных результатов. Его увольнение будет деморализующим фактором в команде, ухудшит бренд-имидж компании и потребует очередной траты ресурсов на подбор и найм.
Если вы наврали при найме человеку из нетворка, доверие к вам будет утеряно, и этот канал подбора вы исчерпаете быстро.
Сформировав EVP, описание команды и задач, над которыми предстоит трудиться, тимлид инициирует максимально таргетированный поиск минимального (желательно одного) числа соискателей.
Чем дольше тимлид подбирает человека, тем большее время его команда простаивает без нужной компетенции.
Желание тимлида «посмотреть рынок» — желание растратить деньги компании.
Цель тимлида — максимально быстро и дешёво нанять и адаптировать человека.
Чтобы этого достичь, нужно минимальными усилиями найти минимально подходящего кандидата и нанять его.
Таким образом, тимлиду нужно понять, какой канал привлечения кандидата даст максимально быстро одного подходящего кандидата.
И нет, чаще всего headhunter — плохой выбор канала. Нетворк и около-нетворк (каналы, где присутствует тимлид) — хороший выбор канала.
Как только тимлид подобрал одного кандидата, он его собеседует.
Тимлид в паре с кандидатом садится программировать типичную рабочую задачу. Парное программирование уменьшает стресс (это не экзамен), сводит тимлида и собеседуемого специалиста на «один уровень» и позволяет понаблюдать вживую, как получится работать с кандидатом.