Про наем в IT написано много статей, цель этой заметки — описать принципы построения системы фильтров, которая позволит нанимать подходящих людей в компании. Прочитав заметку, читатели смогут адаптировать эти принципы под свой опыт и построить свою систему найма в компании.
Прежде чем начинать разговор о найме, задумайтесь над вопросом: “Приносит ли IT-отдел доходы компании?”. Этот вопрос напрямую влияет на то, кого мы будем нанимать.
Пример, далекий от IT — бухгалтер на предприятии не приносит денег бизнесу, он помогает избежать штрафов и проблем с законом. Обратный пример — бухгалтер-аудитор в консалтинговой компании, каждый его проект приносит прибыль компании. В первом случае добавление еще одного сотрудника-бухгалтера — это операционный расход, а во втором — инвестиция (гугли CapEx и OpEx).
Распространенная проблема — компания начинает нанимать разработчиков, а потом руководство удивляется: “А что так дорого? Может, в Саранске поищем подешевле?” Для внутреннего сайтика, где сотрудники могут посмотреть дни отпуска и расчетные листки, можно и в Саранске поискать, но это работает не всегда.
Например, в Netflix медиана зарплат инженеров $400,000 в год. Почему? Весь их бизнес — это технологии, ограничивать себе выбор инженеров — ограничивать рост бизнеса. Для них важно, чтобы результат работы человека приносил больше, чем затраты на него. Отталкивайтесь от типа расходов и нанимайте соответствующих по компетентности людей. Роль IT в компании определяет уровень кандидатов и то, где вы будете их искать.
Процесс найма — это система фильтров. Цель этой системы — отобрать толковых людей, способных выполнять работу в условиях вашей организации. Ваш потенциальный кандидат должен быть способен закрывать задачи проекта или выйти на продуктивный уровень за приемлемый для вас срок. Вот и опишите, что нужно уметь делать кандидату, и чем точнее, тем лучше. Не “опыт работы с высоконагруженными приложениями”, а “имеет опыт профилирования производительности приложений, умеет использовать системы кеширования, умеет оптимизировать SQL запросы, может спроектировать систему под высокие нагрузки”. Это и проверяйте на интервью.
Относительно технического уровня кандидатов у меня есть правило — новый кандидат должен быть результативнее 50 процентов своих будущих коллег. Иначе, нанимая новых людей, мы снижаем общий уровень компетентности в компании. Техническая компетентность — это базовый фильтр, позволяющий установить пороговый уровень для перехода на следующий этап процесса найма.
Условия труда, культура, темп работы, процессы тоже влияют на требования к кандидату. У вас громко матерятся? Это накладывает ограничения. Частые авралы с выходными на работе — это тоже предъявляет требования к кандидату. Бюрократия, или, наоборот, все на словах и так далее. Задайтесь вопросом: “Какому человеку наша среда будет комфортна?” или посмотрите на людей вокруг. Как пишут в бизнес-журналах, culture eats strategy for lunch. Да-да, это про компетенции и личные качества: стрессоустойчивость, ориентация на результат и всё такое.
Опишите список поведенческих компетенций, которые критичны для вашей среды. Примеры таких компетенций: системное мышление, ориентация на результат, выстраивание партнерских отношений. Только не верьте тому, что написано в резюме у кандидата, вам нужно проверять его поведение. Поведение меняется очень медленно: если человек конфликтный, он не станет пупсиком после перехода к вам.
Личные качества и компетенции проверяются через поведенческие вопросы. Вы обращаетесь к прошлому опыту кандидата, предполагая, что в будущем он будет вести себя примерно так же. Примеры:
— Расскажи о ситуации, когда тебе приходилось работать в условиях жестких дедлайнов. Что делал? Как справлялся со стрессом?
— Приведи пример ситуации, когда у тебя был конфликт с коллегой. Что делал, чтобы договориться?
— Расскажи про случай, когда тебе приходилось отстаивать свою точку зрения в команде. Что это была за ситуация? Какая у тебя была позиция?
Не стоит спрашивать: “А вот в такой-то ситуации как бы ты поступил?” — это вымышленная ситуация, на нее легко дать социально-приемлемый ответ. Проверяйте прошлый опыт и задавайте открытые вопросы: “Расскажи, как ты ...”.
Из поведенческих компетенций хочу особо выделить способность к обучению. Через 3–5 лет технологии, на которых вы разрабатываете, превратятся в тыкву. Языки и подходы меняются, процесс разработки становится эффективнее. Если в 2009 году доклад 10+ deployments per day от Flickr был чем-то невероятным, то сейчас можно в публичном облаке за вечер собрать continuous deployment pipeline. Если вы ищете людей на долгий срок, проверяйте на интервью их способность обучаться:
— Расскажи об опыте, когда тебе пришлось осваивать новую технологию. Что делал?
— Что изучаешь сейчас? Как определяешь для себя перспективные технологии?
Не учиться в IT не получится.
Итого, определите, через какие фильтры вы будете пропускать поток кандидатов, а дальше решите, как организовать собеседования. В моем опыте работала схема из 3-х этапов: рекрутер проверяет на предмет общей адекватности, далее техническое интервью, затем интервью по компетенциям с нанимающим менеджером. Это общий фреймворк, его можно адаптировать под конкретный случай: например, для кандидатов с релокацией проводить два технических интервью. Главное, понимайте, что и на каком этапе вы проверяете.
Поговорим о готовности проекта к расширению команды. Проблемы некоторых проектов не всегда следует решать наймом новых людей (закон Брукса). Я много раз наблюдал, как на горящий проект пытаются докинуть людей, чтобы ускорить разработку. Прежде чем сделать это, убедитесь, что добавление людей действительно поможет ускориться.
На эту тему у меня есть тест: откройте JIRA (или что у вас там), найдите следующую по плану фичу, прочитайте описание. Если вы не можете по описанию приступить к реализации, новые люди вам не помогут.
Ускорение разработки за счет увеличения команды возможно, если:
- Есть понятное описание фичей. В тексте, а не в головах.
- Начало работ не заблокировано внешними зависимостями: дизайн, локализация, требования.
- Работа может быть завершена без внешних зависимостей, то есть не зависит от других команд, архитектора, отдела эксплуатации и т.д.
Если эти условия не выполняются, вам нужно решать проблему в другом месте — там, где реально застревает работа. Читайте “Цель”, а потом ищите узкое место.
Наем — это важный бизнес-процесс в организации, его цель — обеспечивать приток кандидатов и отбирать тех, кто наиболее подходит вашей компании. Стройте систему фильтров, которая будет работать в ваших условиях. Нанимайте с осторожностью, ошибки обходятся дорого. И не пытайтесь решать проблемы горящих проектов одним только наймом.