Я сам буду набирать свою команду для проекта.

Казалось бы, почему я должен этим заниматься? Это ответственность HR-службы, для этого она и предназначена. Но я бы хотел ускорить этот процесс и взять чуть больше контроля.

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

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

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

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

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

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

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

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

Итак, с чего начать? Конечно, с описания необходимого профиля кандидата.

Идеальное описание вакансии и как это работает

«К чёрту подробности!» (с) Нет, как раз подробности решают многое. От того, как составлено описание вакансии, зависит, насколько правильные кандидаты к вам обратятся. Кандидаты с нужными компетенциями и подтверждённым опытом в искомой области. А ещё, что не менее важно, — с правильным отношением именно к той работе, на которую они претендуют.

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

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

Например, мы как-то искали кандидата на очень конкурентную позицию фронтенд-разработчика, но никто не откликался. Мы задумались, прозвонили людей, которые просматривали вакансию, но почему-то на неё не откликались. И быстро поняли проблему: всё дело было в одной строке в описании вакансии! Поскольку мы не были уверены, в каком фреймворке должна выполняться работа, то указали три возможных варианта. Причём указали через косую черту: Angular/React/Vue — как возможные варианты. То есть это мы так думали: люди будут понимать, что это варианты. Но выяснилось, что, когда кандидаты доходили до этой строчки, они думали, что им придётся писать на всех трёх фреймворках. Именно поэтому они не хотели откликаться. Стоило нам изменить эту строку, как вечером у нас уже был первый кандидат.

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

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

Кандидат и его резюме

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

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

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

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

Лучше всего, конечно, — личный взгляд и собственное мнение. Даже 5–10-минутное интервью с потенциальным кандидатом даст вам гораздо больше информации о нём, чтобы принять решение. Мне таким образом удалось «вытащить» из плохо написанных резюме нескольких кандидатов, которые потом стали настоящими звёздами в команде.

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

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

Правильное интервью для нужного результата

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

Проводя собеседования, я выработал следующую структуру интервью с кандидатом:

• Серия вопросов от меня с короткими ответами кандидата — 5–10 минут.
• Самопрезентация кандидата — 5–10 минут (с вопросами по ходу презентации).
• Описание круга задач — 3–5 минут.
• Принятие решения о проведении технического интервью. Если с обеих сторон осталась заинтересованность, то на это выделяется 30–40 минут.

Я уверен: если действовать по этому плану, то кандидат сможет оценить серьёзность вашего подхода и, возможно, решит работать именно у вас.

Такой подход сэкономил мне достаточно много времени, поскольку около 20 % кандидатов у меня отваливалось примерно в середине встречи. Где-то я понимал, что дальше можно не продолжать, где-то они осознавали, что это не их место, и уходили.

Меня всегда интересует, как именно человек рассказывает о своём отношении к работе. Какая у него была роль на прошлом месте? Обычно все кандидаты рассказывают, в каких проектах участвовали, подробно описывают сам проект. Это важно, но мне нужно понять роль кандидата в этом проекте и как сам человек в этой роли себя видит. Спрашиваю, какую пользу он приносил проекту и как он видит идеальное окружение той роли, которая предлагается у нас. Что он должен в этом процессе получить на входе, а что — на выходе? Не все справляются с такими простыми вроде бы вопросами. Бывает, даю задачки про разные рабочие ситуации. Вот, например, мы принимали аналитиков, и была такая задача для кандидатов: «Приходит к вам заказчик и говорит: «Мне нужен там велосипед с квадратными колёсами, и чтобы он ещё мягко ездил»». Главное, что здесь нужно от аналитика, — это умение задать заказчику вопрос: «А какую проблему вы решаете?» То есть мы ищем человека, который не автоматически начинает думать, как реализовать заказ в той формулировке, которая пришла, а пытается докопаться до сути, что у заказчика «болит». Потому что на самом деле заказчик приходит к профессионалам, чтобы решить свою проблему, а не реализовать собственную идею, как её решать.



Есть три ключевых признака, которые присущи высокофункциональным членам
ИТ-команды и которые можно выявить в ходе первичного собеседования: это желание, готовность и обучаемость. Само собой, важен опыт кандидата. Хотя мы иногда берём и юниоров, понимая, что у них большие перспективы, особенно если видим в них эти ключевые качества.

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

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

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

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

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

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

Качества лидера команды определяющие успех проекта

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

Роль лидера ИТ-проекта — это руководство, контроль и мотивация членов команды. Всё, что делает лидер, должно способствовать росту её эффективности. Он распределяет нагрузку среди разработчиков, отслеживает выполнение задач и несёт ответственность за проект.



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

Даже команда, обладающая необходимыми навыками и качествами, может стать жертвой разногласий и упрямства. Это те «убийцы прогресса», которые лидеру нужно устранить. А их трудно избежать в группе очень талантливых людей. Разногласия и отсутствие сотрудничества возникают в случаях поиска «правоты», когда атмосфера в команде перестаёт быть сплачивающей. Но в ИТ-сфере формула «я прав» не всегда является искомым вариантом. Не так важно, кто прав, важно, что ведёт нас всех к общей цели. Команды, работающие без согласованных целей, испытывают трудности, поскольку эгоцентрические мотиваторы приводят к разногласиям.

Чтобы сохранить группу высокофункциональных индивидуумов, нужна общая цель. Лидеру необходимо зарядить команду энергией этой цели, которая объединяет всех. Цель — это маяк. Когда возникнут проблемы — а они непременно возникнут! — цель станет тем единственным ориентиром, который поможет всем вернуться на правильный путь.

Важным качеством лидера должна быть честность: команду нельзя обманывать. Обязательно потом всё всплывёт! Обманом легко разрушить отношение к себе, к проекту, к команде и провалить всё, что было «нажито непосильным трудом».

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