(Тут будет довольно много упрощения, но без этого не обойтись, если не хочется пересказывать несколько учебников)

Вакансии могут быть индивидуальными, неиндивидуальными и впрок. В зависимости от типа вакансии требования к кандидату сильно разнятся.

• Индивидуальная: нам нужен человек на такую-то должность, чтобы он занимался тем-то и тем-то. Человек найден – вакансия закрылась. Например, мы ищем одного дизайнера в отдел маркетинга и знаем, что объем работы на одного человека точно найдется. Как правило, это работа для специалиста с определенным опытом (в индустрии или с технологией или с рынком). Генералистов так тоже можно искать, но это долгий процесс.
• Неиндивидуальная: мы всегда ищем умных разработчиков. У нас много задач, которые надо сделать, но мы не очень торопимся их делать, т.к. отрывать имеющегося сотрудника от работы не хотим. Это подход Google, когда ищутся люди, отвечающие определенным критериям, но изначально непонятно, на каких проектах они будут работать. Как правило, это работа для генералиста, который когда-то был специалистом. Наряду с профессиональными умениями крайне полезна широта опыта в плане разных бизнес-вертикалей (телеком, финансы и трэвел, как у меня, например).
• Впрок: нам пока не нужен кто-то конкретный, но нам необходимо иметь список кандидатов, которым мы сразу позвоним, как только у нас появится вакансия: кто-то уйдет или мы решим начать новый продукт, для которого будут нужны новые ресурсы. Впрок могут быть нужны как генералисты, так и специалисты, но вообще, хорошего специалиста легче найти через биржи или рекрутеров, чем хорошего генералиста. Это вдвойне правда, если требуется кандидат с опытом в индустрии: таких людей можно искать и полгода, и год.

Если проанализировать разницу между вышеприведенными типами вакансий, можно примерно набросать для себя костяк вакансии, чтобы её понял и кандидат (который noBS кандидат, конечно 🙂 ). В хорошей вакансии должны быть прописаны:

• Срок, когда нужно закрыть вакансию. Для обычных вакансий это будет “как можно быстрее” или “до 1 июля 2015 года“. Для неиндивидуальных это будет “ищем всегда“. Для вакансий “впрок” это будет “заявите о своем интересе“. Многие компании сильно недооценивают вакансии “впрок”, хотя наличие пула кандидатов для начала одного-двух-десяти новых проектов порой является единственным, что отделяет инновационные компании от простых.
• Требования к кандидату. Это огромная простыня, коснемся её позже.
• Описание рабочих обязанностей и проекта. Для вакансий, в которых понятно, чем будет заниматься человек, крайне интересно описать проект и/или сферу ответственности. “Вы будете писать код подключения новых авиакомпаний и онлайн-агентств в проекты aviasales.ru и jetradar.com” – самый минимум, что нужно написать. Хуже – засунуть эту информацию в описание вакансии: “Разработчик на Ruby для подключения гейтов”. Вообще плохо – если понятно, чем будет заниматься человек, но рассказать ему об этом только на интервью. Если есть возможность “продать” проект человеку раньше интервью – что тут плохого? А что плохого в том, что человек пройдет мимо вакансии, если через месяц он, узнав, чем ему придется заниматься, выпрыгнет за борт? Для вакансий “впрок” и неиндивидуальных надо заниматься красивым корпоративным маркетингом и рассказывать о том, что это такое – работать в этой компании, как выглядит один день из жизни сотрудника и т.п. Также предельно важно указать, является ли работа проектной, операционной или их смесью.
• Описание контекста работы. Это продолжает предыдущий пункт: если человеку описать, с кем он будет работать и какие артефакты генерировать (например, если от операциониста требуется артефакт “вклад в стратегию” – кандидату надо очень сильно задуматься над тем, хорошо ли работодатель подумал, и не попадет ли он в позицию responsibility without authority. Если человек экстраверт, а ему предлагают общаться только внутри своей команды, – это может сильно его демотивировать. Если человек занимается рынком, а ему не дают возможность общаться с коллегами, отвечающими за другие рынки, – это тоже огромная торпеда и т.п.
• Метрики. Считается, что если работодатель может заранее сформулировать KPI сотрудника, то процесс управления людьми построен прекрасно. В этом утверждении много правды, но много предположений, в т.ч. излюбленное мною обычно неверное предположение о том, что результат работы компании можно проследить до вклада каждого сотрудника, у которого эти результаты в KPI.
• Вилка зарплаты. Как и любой вопрос, связанный с деньгами, он неоднозначный, но можно решить его процессуальной честностью. Каждому типу должности соответствует список вещей, которые сотрудник должен выполнять и, результаты, за которые он несет ответственность. Классификация таких типов должностей – серьезная работа со стороны HR, но это необходимый процесс. Каждой категории ставится вилка зарплат. Например, senior разработчик имеет ставку от $X до $x+400 в месяц. Классификации разные, но я придерживаюсь четырех:
  • EMPL – для сотрудников без ответственности за управление другими людьми
  • LEAD – EMPL + управление командой
  • SPEC – это EMPL + экспертные знания + ответственность за деньги и, возможно, стратегию.
  • EXEC – это LEAD + ответственность за деньги и стратегию.
• Таким образом, Junior Developer будет, скажем, уровня EMPL5, просто Developer будет уровня EMPL6, Senior Developer – уровня EMPL7. Тимлиды бывают тоже разного уровня, менеджеры – тоже и т.п. Смысл подобных уровней (у нас в Aviasales они называются “жёрдочками”) в том, чтобы не недоплатить человеку, стОящему больше, и в том, чтобы не переплатить за более простые задачи. Поэтому мы всегда не скрываем уровень зарплаты, нанимая людей на работу.

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

• Гибкость работодателя. Если я прошу “А” – я хочу получить “А”. Когда этим подходом пользуются нанимающие менеджеры – это понятно и объяснимо. Когда этим же подходом руководствуется прокладка между кандидатом и менеджером (это НЕ синоним терминов “рекрутер” или “HR менеджер”), это зло. Гибкость может выражаться в степени необходимости точного совпадения запрашиваемого получаемому. Обычно степень гибкости выше для новых проектов и ниже для замены ушедшего сотрудника или для операционной работы.
• Уровень знаний. Знание предметной области, инструментов, языков программирования и т.п.
• Уровень опыта. Какие из знаний применял и для чего. Это позволяет избежать криикуемой мною концепции “один год, повторенный 10 раз”. Здесь же – что сделал и в какой ипостаси. 80% кандидатов врут про опыт, поэтому разбивка его на проекты с рассказом о том, что делал в каждом проекте, позволяет не завираться сильно.
• Уровень руководства. Кем рулил, кто рулил тобой, какие stakeholders были в проектах. 80% кандидатов привирают свою важность хотя бы на одну ступеньку повыше (не просто разработчик, а еще и тимлид или хотя бы senior разработчик; не product development manager, а product manager и т.п.). Поэтому цените тех, кто не привирает: они уверены в себе.
• Уровень ответственности. За что отвечал: за свой код, за команду, за продукт, за канал продаж, за рынок, за клиентов, за вертикаль, за работоспособность бизнеса, за получение инвестиций и т.п. Один из моих излюбленных вопросов с подвохом: “А что ты делал как руководитель, чтобы достичь всего того, за что ты был ответственным?”. Злой вопрос, рекомендую.
• Лично мне наплевать на пол, возраст, семейное положение, фотографию, национальность и т.п. Меня в первую очередь беспокоит, чтобы человек сработался в коллективе и принял нашу философию контролируемого сумасшествия; к сожалению, это отфильтровывает большое количество кандидатов, обстоятельства которых не совместимы с нашими.

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

Продолжение следует.

Filed under: Job and Office