Dream team из ничего: найм специалистов в IT

Всем привет!

Как и обещал, продолжаю публикации о менеджменте в IT. В предыдущей статье ^[1] я рассказал, что значит быть Team Leader. Но какой же тим лид без команды? Сегодня же о том, как можно набирать классных людей, не имея больших ресурсов, и когда о вас никто не знает.

Небольшая ремарка: все компании разные (об этом я писал в первой части). Я расскажу о том случае, когда вы и начальник отдела, и Team Leader в одном лице. И сами должны набирать команду. То есть это самые сложные условия. Когда в вашей компании есть отдел кадров, всё гораздо проще, но про это я тоже вставлю свои 5 копеек.

Как нанимают людей

Они не появляются из воздуха, поэтому тут всё довольно стандартно:

• поиск специалистов на рынке труда;
• рекомендации. В Европе и Америке это не очень распространено, а вот у нас это обычная практика;
• перетаскивание людей, которых вы хорошо знаете, с прошлого места работы. Этот вариант очень даже хорош, но с одним условием: вы выбираете сотрудников, отталкиваясь от профессионализма. Иначе это не работает.

Как компании нанимают людей:

• крупная и известная компания в сфере IT. Работать там — мечта многих программистов. В этом случае привлечь их особого труда не составляет;
• большая компания, где IT не основная деятельность. Сейчас таких очень много, в них нанимают инженеров для автоматизации своей работы. У этих компаний есть все ресурсы для HR: менеджеры активно пиарят свои крутые IT-отделы, привлекают специалистов всеми способами. Постепенно эта информация разлетается в профессиональных кругах, и когда человеку приходит оффер от такой компании, он соглашается;
• стартап с инвестициями. Как правило, хватает ресурсов нанять хорошее агентство по подбору кадров. Вы можете предложить хорошие условия, офис класса А в центре, различные бонусы и т.д. Больших проблем с кадрами не должно быть;
• небольшие компании, которые живут на то, что заработали (таких компаний большинство). Скорее всего у них нет денег, чтобы сразу привлечь квалифицированных инженеров. При этом офис находится в том месте, где дешевле аренда.

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

Как с этим жить

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

Самые важные принципы:

• нужен хоть какой-то опыт управления, и он не должен быть первым. Если вам предложили такую должность, а вы этим не занимались ранее, вероятность провала велика. Я понимаю, что есть соблазн быстрого развития и карьерного роста, но смысл в том, чтобы опыт оказался удачным;
• вы должны четко понимать, кого и зачем вы должны нанять, и в какое время. Если вы пишите сервис, и на это есть 4 месяца, то нет смысла сразу нанимать тестировщика и админа. В начале разработки клиентской части ещё нет, то есть тестировать нечего. И настройка серверов обычно нужна уже ближе к релизу. Возьмите лист бумаги и с левой стороны сделайте список сотрудников и их обязанностей, а с правой — функционал, который нужно реализовать. Если для кого-то нет работы, то смело вычёркивайте;
• определите вашу «аудиторию» и места, где её найти. Объективно, вам не светит нанять суперпрофессионалов, у вашей компании нет на это денег. Но это не значит, что специалисты с меньшим опытом, но которые хотят развиваться, не вырастут в профессионалов. Очень советую обращать внимание на тягу к развитию. А ещё специалисты должны расти вместе с сервисом (бизнесом), крутому профессионалу в скромном рядовом проекте может стать скучно, и он уйдёт;
• помимо hh.ru и других подобных ресурсов, есть социальные сети и просто знакомые. Публикуйте вакансии у себя на стене, просите друзей программистов репостнуть, пишите в тематические группы. Вам постучат, я сам так нанимал нескольких людей;
• предлагайте то, чего нет на рынке у других. В моём случае это была задранная планка самого проекта, то есть я изначально планировал сложный и интересный сервис: client-server приложение на сервере Symfony, react/angular на клиенте, никаких CMS и только современные технологии.

В диалоге с основателем, когда я только пришёл работать в компанию, родилась идея создания агрегатора б/у запчастей для автомобилей, чтобы в нём объединить авторазборки. Но он не мог позволить себе большие траты. Если бы планы не были такими наполеоновскими, то делал бы всё по-другому. Для разработчиков, которые жаждут опыта, такие проекты привлекательнее тем, что в них всё делается изначально правильно. Многие готовы пожертвовать крутым офисом ради ценного опыта.

Составление вакансий и подготовка к собеседованиям

Любой толковый HR скажет вам, что положительный отклик на 90% зависит от того, как вы составили вакансию. Тут всё просто: идёте на HH и смотрите вакансии, которые бы вас самих заинтересовали, и пробуете писать так же. Ни в коем случае не врите, пишите только правду. Если совсем не получается, составьте список навыков, которые актуальны для вашего проекта, и обратитесь к HR. Сэкономите время, а стоит это не очень дорого.

Начиная поиск, задействуйте все ресурсы: сайты с вакансиями, соцсети, знакомых и т.д. Обязательно купите доступ к базе данных с резюме. Да, поиск по базе отнимает уйму времени, но талантливая команда и успешный проект того стоят. Также напишите стандартные заготовки ответов и отказов.

Теперь о подготовке к собеседованиям. «Зачем? Я же провожу собеседование, пусть кандидаты готовятся!» — многие могли подумать. Но это важно, вам надо готовиться к каждой вакансии. Google в помощь при составлении списка вопросов, которые вы будете задавать при собеседовании. Список обязателен, а то забудете что-то спросить.

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

Позже я составил анкету-опросник ^[2] по важным для нас технологиям и отправлял соискателям. Она не требовала более 10 минут на заполнение, кандидаты просто ставили оценки владения напротив каждой технологии. Результаты уже давали ясное представление о соответствии специалиста нашим требованиям, в 80% даже такой анкеты было достаточно.

Важная ремарка: вы не можете во всём быть экспертом, поэтому берите консультации у профессионалов или даже зовите их на помощь на собеседование. Пусть вы потратите немного денег, но сэкономите куда больше в будущем. Также сами изучайте предмет. Например, нужен тестировщик, но вы ничего об этом не знаете. Не ленитесь и открывайте Google.

Итак, у вас есть n кандидатов, которые готовы прийти к вам на собеседование. При этом у вас и так жутко не хватает времени, поэтому придётся его экономить. Берите телефон и начинайте звонить или писать им в мессенджеры. Сначала кратко рассказывайте о компании, а потом буквально в течение 5 минут просите рассказать о своём опыте. 70% отвалятся уже на этом этапе. Или их что-то не устроит, или вас.

Как понять, что человек вам не подходит? Тут всё довольно просто: либо у него есть требуемый опыт, либо нет. Всегда можно спросить о какой-то технологии в разговоре, на ходу сложно соврать: если человек уверенно рассказывает о своём опыте, то скорее всего так и есть. Да и по голосу часто это легко определить. Ну а сказки отдельных неопытных джуниоров о разработке космических кораблей скрасят вам рабочие будни.

Как проводить собеседования

Увы, это такой процесс, где все врут. Ваша задача — найти истину. Конечно, самому лучше не врать.

Начнем с того, что не стоит делать:

• не давайте на собеседовании логические задачи, не относящиеся к работе. Соискатель не должен перевозить на лодке коз с овцами, взвешивать шарики и ехать навстречу поезду со скоростью n. Это никак не поможет вам найти хорошего программиста. Наоборот, только потратите время и упустите ценные кадры;
• избегайте объёмных тестовых заданий. Я считаю, что за 10–15 минут по простым тестам легко выяснить уровень знания основ. Если видно, что человек опытный, то можно вовсе не давать тестовое задание, не тратьте своё и его время. И собеседование — это стресс, не усугубляйте;
• не спрашивайте о тех технологиях, которых нет в проекте. Если что-то не используете, то вам это сейчас и не нужно;
• не углубляйтесь в узкую специфику. Не заостряйте внимание на каком-нибудь конкретном фреймворке или библиотеке. Это не расскажет вам о его реальных знаниях, а даст только понимание, что он работал с какими-то технологиями. Спросите лучше про OOP, patterns, SOLID и т.д. Человек, знающий основы, легко разберётся в любом фреймворке или освоит библиотеку;
• не требуйте чётких определений. Я понимаю, что для программиста важны структурированные знания, но понимание важнее знания конкретного определения;
• если в какой-то момент вы понимаете, что соискатель вам не подходит, заканчивайте собеседование. Просто скажите, что вам нужен более опытный человек и вы не хотите тратить его время. Большинство вполне адекватно это воспринимает. Нет смысла продолжать собеседование, чтобы в конце сказать «нет»;
• прежде всего оценивайте профессиональные качества. Вам нужны люди, которые будут решать задачи в проекте, вам с ними не жить. Это важнее пола, возраста, образования, прошлого места работы. Мне встречались классные разработчики, которым было за 50, и бывшие ВДВшники, освоившие программирование;
• не берите людей, если они не подходят. Особенно, если в них не видно потенциала для роста. Не делайте поблажек родственникам и друзьям, это путь в никуда;
• не спрашивайте про узкоспециальные технологии. Даже опытный инженер может не ответить, потому что не работал с ними. Конечно, если вы именно на эту технологию и ищете, он должен её знать.

А теперь, что нужно делать:

• берите коллег на собеседования. Их мнение будет только плюсом. И они в каких-то нюансах могут разбираться лучше вас. Но насильно для массовки тащить никого не надо;
• внимательно слушайте соискателя об опыте. Из этого можно много что узнать, уточнить что вам интересно, да и многие вопросы сами отпадут;
• отдавайте предпочтение тем людям, которые сами умеют думать, а не просто решают задачу. Например, в простой тестовой задаче не давайте части каких-то данных. Если человек начнёт рассуждать и спрашивать, это плюс в его копилку;
• для проверки знания паттернов не просите писать их наизусть. Лучше предложите задачку ближе к жизни. Например, сделать конструктор для студии, которая делает ремонт квартиры. Есть разные двери (металлические, деревянные, пластиковые), разные окна (пластиковые, деревянные) и т.д. Это позволит увидеть, как архитектурно будет решаться задача. Во-первых, для человека это будет проще, чем переписывать зазубренные знания, а во-вторых, вы увидите, как он подходит к решению конкретных задач;
• давайте людям задачи на размышления, желательно из реальной жизни. Просите соискателя рассуждать вслух, по мере ответов усложняйте задачи. Главное не найти решение, а выяснить подходы человека;
• задавайте понемногу вопросов из разных областей, не затягивайте собеседование. 40 минут вполне достаточно, максимум час;
• расскажите сами о проекте, спросите соискателя, что он ещё хотел бы узнать, постарайтесь заинтересовать. Тут у вас преимущество перед HR, которые обычно не в курсе проекта. Не поленитесь и выделите для этого время на собеседовании;
• рассказывайте обо всём честно. Не надо врать про технологии и обязанности. Если слишком приукрасить условия работы, то есть вероятность, что человек уйдет после первых двух недель работы;
• мотивация может быть важнее знания. Есть люди с горящими глазами. Пусть у них мало опыта или нет совсем, но есть желание развиваться. Скажите им честно, что опыта у них недостаточно, но видите в них потенциал, и вы готовы дать шанс. Я так взял 4-х людей с маленьким опытом, все они превратились в классных специалистов. Кстати, такой подход часто используют крупные компании, они из новичков растят крутые кадры. И вам это по силам;
• делайте дальновидный выбор. Если один кандидат много знает, но вы видите, что он не готов делать любую работу или пытается продавливать свои условия уже на собеседовании, а второй не так опытен, но с горящими глазами и полон энтузиазма, то берите второго. Он не испортит атмосферу коллектива, а это очень важный аспект. Если другие будут видеть, что кто-то косячит, это будет расхолаживать команду. Такими, как первый, сложно руководить, а если у вас мало опыта в управлении, то не создавайте себе дополнительных сложностей;
• если вам понравился специалист, скорее берите его. Не берите долгие паузы, позвонить на следующий день оптимально. У меня так уводили людей буквально через день;
• узнайте у соискателя о самообразовании. Это покажет, насколько он трудоспособен. Книги, конференции, онлайн-курсы, хакатоны, что угодно, это всё плюсы для него;
• спросите у кандидата, чем бы он хотел заниматься и чем бы не хотел. Если ваши интересы не совпадают, и вы возьмёте его, рано или поздно он от вас уйдёт. А вы потратите время на его обучение и развитие;
• если человек не подходит или есть другие причины для отказа, сообщите ему об этом. Сделайте пару стандартных заготовок ответов и потратьте 3 минуты на отправку. Я думаю, все ненавидят, когда им не отвечают. Не поступайте так сами. К тому же человек может вырасти и прийти к вам ещё раз;
• не знаете, кого выбрать? Просто напишите на бумаге все плюсы и минусы. Тех, кого вы не взяли, но они вам понравились, складывайте в отдельную папочку. Она вас ещё выручит и не раз;
• не бойтесь нанимать людей сильнее, чем вы. Я видел, как рубили кандидатов со словами: «Да вы видели его? Он же меня подсидит!» Зато с профессионалами вы быстрее добьётесь успеха.

Увольнение

Когда стоит увольнять? Очевидно, если сотрудник не справляется со своими обязанностями. Тут есть важный для вас момент — причины этого, и их желательно выяснить. Например, виноватым могли быть вы, если неправильно ввели его в команду. На эту тему я уже готовлю отдельный материал.

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

Стоит уволить человека, когда он постоянно косячит и не справляется с задачами вовремя. Держать его и пытаться перевоспитать — пустая трата времени. Проще уволить и временно взять его обязанности на себя. Я как-то не уволил человека, потому что некем было заменить, но потом поплатился. На нём висело много ключевых обязанностей, и он постоянно срывал сроки. Беседы и прочее не помогали, в итоге случилось два серьёзных факапа, в которых, конечно, оказался виноват я, а компания потеряла деньги.

Случаи пьянок, прогулов и прочего безобразия разбирать не буду. Увольняйте!

Также может оказаться, что человек не соответствует ценностям компании и не хочет их разделять. Это плохо для коллектива. Лодка будет раскачиваться всё сильнее, в конце концов вы можете остаться без команды.

Увольнять людей надо тоже уметь. Первые несколько раз чувствуешь себя виноватым, но с опытом это постепенно проходит. Всё должно быть четко и по делу: «Вася, ты классный, но к сожалению у нас то и то (объясняем причину), поэтому лучшим решением будет расстаться». В том же фильме MoneyBall есть очень хороший пример, как главный герой учит увольнять человека, рекомендую посмотреть.

Как изменится процесс найма, когда компания вырастет

По сути — никак, все принципы останутся теми же. Только у вас будет HR, которому вы объясните, что хотите получить, и он сможет заниматься поиском самостоятельно. HR может сам определять, какой человек хочет развиваться, а какой нет, кем тяжело управлять, а кем нет. Если вы уже CTO или руководитель направления и у вас есть Team Leader или тот, кто может им стать в перспективе, берите их на собеседования, пусть они учатся. Потом в какой то момент они смогут проводить интервью сами. Вы смотрите, иногда помогаете, затем устраиваете разбор полётов, и потом они уже сами будут заниматься наймом сотрудников к себе в команду. Но это уже про выращивание Team Leader, и об этом в другой статье.

Выводы

Многие скажут, Team Leader не должен этим заниматься. И будут правы, в идеальном мире большой компании не должен, где все процессы были отлажены другим энтузиастом. Но ответьте сами себе на вопрос: «Что вы хотите через год от компании?» Чтобы она росла, команда тоже должна развиваться вместе с ней.

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

Применяйте разные приёмы, ездите на конференции, общайтесь с людьми. Я сам так нашёл двух сотрудников. Задействуйте соцсети, общайтесь с людьми из ВУЗов, оттуда тоже можно привлечь молодых специалистов, например, через практику. Для вас открыты все двери.

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

Спасибо за внимание! В следующий раз я расскажу о том, как построить эффективную команду разработчиков.

Автор: Артур Дементьев

Источник ^[3]