Как мы спасли от выгорания нанимающих аналитиков в X5 Tech
Меня зовут Антон Денисов, я руководитель аналитиков больших данных в X5 Tech. В этой статье расскажу, с какими сложностями сталкиваются нанимающие менеджеры в сфере Data Science в условиях интенсивного процесса найма сотрудников, а также продемонстрирую, к какому виду мы привели процесс собеседований и найма аналитиков больших данных в X5 Tech.
Проблема высокой нагрузки нанимающего менеджера
Приведу некоторые численные оценки. Средняя продолжительность работы сотрудника в одной компании в сфере IT составляет 3.6 года [источник]. Предположим, что аналогичная цифра и в Data Science, тогда при штате в 50 человек текучка составит около 14 человек в год.
Давайте попробуем прикинуть, сколько времени понадобится, чтобы нанять такое количество сотрудников.
Ранее мы описывали процесс найма в нашей компании, в нём присутствуют 3 этапа интервью: два технических этапа и встреча с командой. Статистика найма в X5 Tech свидетельствует, что конверсия из готовых общаться кандидатов в нанятых сотрудников составляет около 5%. Другими словами, для найма 14 аналитиков больших данных необходимо около 220 часов, т. е. примерно шесть недель рабочего времени. И это только для того, чтобы поддержать численность штата в текущем состоянии, и не учитывая время на предварительное изучение анкет кандидатов! А ведь есть ещё и развивающиеся инициативы, под которые тоже нужно искать людей.
Нанимающие менеджеры, обычно, являются лидерами компетенции, их время стоит дорого и у них много других задач, помимо найма. Монотонно повторяющийся процесс в скором времени становится утомительным, что в конечном итоге может привести если не к снижению качества взаимодействия на всех этапах найма, то к выгоранию.
Распределение нагрузки по штатным сотрудникам
Для снижения чрезмерной нагрузки на нанимающего менеджера мы решили вовлекать сотрудников, начиная с уровня Middle, в процесс технических собеседований. Такой подход, с одной стороны, помогает снизить нагрузку на сотрудников более высоких компетенций, с другой, расширяет кругозор вовлечённых специалистов и помогает им поддерживать знания в актуальном состоянии. Однако, в этом случае, возникает три задачи, которые нужно решить.
Задача 1: создание единых критериев оценок. Предположим, что нам удалось привлечь для собеседований 20 человек уровня Middle. В силу недостаточного опыта Middle специалист не может принимать окончательное решение о найме сотрудника, а тратить время на перепроверку каждого кандидата — прямой путь просто удвоить работу. Решением этого вопроса может выступать формирование единых критериев для оценки кандидатов.
Стоит отметить, что формирование таких критериев оказалось более сложной задачей, чем поиск 20-ти желающих проводить собеседования, хотя и это тоже непростая задача. Причиной трудностей является, в том числе, и тот факт, что для стажёров критерии одни, для синьора и лида — совсем другие. Более того, в одних командах ценится техника, в других — проактивность и креатив.
Для команд, где подразумевается тесное взаимодействие с бизнес-заказчиком, мы стали чуть больше уделять внимания тому, хорошо ли структурирует и излагает кандидат свои мысли, как оценивает свой опыт и достижения. Этот раздел называется Soft-Skills и всегда присутствует в анкете. По остальным разделам, относящимся к Hard-Skills, критерии дорабатывались после множества итераций собеседований разными участниками.
Задача 2: управление расписанием встреч. Следующим важным моментом является то, что при наличии достаточно большой группы участников собеседований возникает проблема назначений людей на встречи. Хотелось бы, чтобы нагрузка распределялась равномерно по участникам. Чтобы проследить за этим и учесть все нюансы в расписаниях, отпусках, встречах и т. д., нужна отдельно стоящая система контроля загрузки, т. к. резко возрастает объём коммуникаций. Эта проблема решаема, но на данном этапе мы авторитарно назначаем того, чья очередь подошла без учёта его расписания, а если человек не может, то меняем на следующего по очереди.
Задача 3: создание общего банка вопросов и задач. Ну и последней немаловажной проблемой при массовом участии людей в найме, о которой стоит упомянуть, является нефиксированные для разных уровней задачи и вопросы. Без формирования единых задач и вопросов сравнение людей будет некорректным даже при фиксированных критериях оценки.
В итоге решение проблемы узкого горлышка в найме путём вовлечения более широкого пула специалистов в найм существует, но требует:
разработки универсальных критериев оценки кандидатов;
разработки системы/правил равномерного распределения нагрузки;
формирования единого банка вопросов и задач.
Иллюстрация сервиса для собеседования
Итоговым решением стала разработка собственного сервиса найма. Сервис написан нашими аналитиками на веб-фреймворке Flask. Это простое, реализованное в короткие сроки решение, тем не менее, отлично закрывает потребности аналитиков в процессе технических собеседований и оценки кандидатов.
Опишу процесс работы с сервисом подробнее по шагам. Предварительно отмечу, что перед встречей с кандидатом всегда заводится карточка на Kanban-доске (сейчас мы используем Kaiten) с такими параметрами, как: уровень, компетенция, команды, в которые кандидат может подойти, исходя из описанного им опыта, и некоторые другие атрибуты.
Шаг 1. Собеседующий в начале встречи заходит в веб-сервис. Стартовая страница задания параметров собеседования выглядит так:
Рис. 1. Выбор параметров собеседования
Шаг 2. После нажатия на кнопку «Создать форму», формируется страница с вопросами и задачами, а также пятибалльные критерии в виде выпадающего списка по каждому разделу. В выпадающем меню каждой оценке прописан комментарий, при каких условиях такую оценку можно проставить кандидату.
Приведу часть анкеты, чтобы проиллюстрировать её структуру и пример заполнения формы для раздела Python:
Рис. 2. Иллюстрация формы для заполнения собеседующим
Как видно из рисунка 2, форма содержит вводную часть, позволяющую познакомиться с кандидатом, оценить его опыт и умение рассказывать про себя. Далее идут выбранные разделы по Python, SQL и статистике.
Каждый раздел содержит задачи и критерии оценивания в виде раскрывающихся списков:
Рис. 3. Просмотр задачи, выбор оценки и комментарий к ответу
Таким образом, собеседующий использует сервис во время интервью как ориентир, идёт по заданному шаблону разделов, проставляя на лету оценки и делая заметки во время собеседования. Это позволяет не отклоняться от единой структуры собеседования, а также лучше рассчитывать время на вопросы.
Шаг 3. В конце собеседования нужно нажать кнопку «Сохранить анкету», после чего поля с введённой информацией преобразуются в отчёт, который прикрепится к карточке кандидата автоматически. Попутно анализируются выставленные оценки и формируется решение, прошёл ли кандидат этап. В случае непрохождения этапа формируются рекомендации по непройденным разделам:
Рис. 4. Отправленная скомпонованная форма в виде комментария к карточке кандидата
По нашим оценкам, на этап формирования обратной связи уходило до 20% времени. Лидеру компетенций/нанимающему менеджеру после этого остаётся только прочитать структурированные комментарии и предложенные системой решения о прохождении этапа; не нужно никому напоминать, чтобы человек заполнил обратную связь, нет неоднозначных оценок. Для HR данная схема ускоряет время ожидания сбора обратной связи от коллег, что из нашего опыта иногда занимало несколько дней.
Архитектура решения
Несмотря на то, что сервис очень просто устроен, для заинтересовавшихся читателей опишу его чуть подробнее.
Все разделы подтягиваются из банка вопросов и задач. Банк — это вложенная структура папок для каждого раздела с вопросами, задачами и критериями, хранящимися в markdown файлах. Для каждой задачи есть свой файл. Пример структуры банка и иллюстрация простой задачи из раздела Python:
Рис. 5. Структура банка задач и пример файла с задачей
Файлы задач имеют фиксированную структуру для удобного парсинга сервисом. Здесь важно заметить, что для каждого раздела есть вопросы и/или задачи с правильными ответами и решениями. Критерии оценивания по пятибалльной шкале хранятся в файле Criteria вместе с рекомендациями и полезными материалами.
Заключение
Подводя итог, перечислю, что описанный подход с сервисом нам позволил:
снизить порог входа в процесс проведения собеседований, тем самым делая возможным масштабирование процесса найма и увеличение пропускной способности;
нивелировать затраты времени на написание обратной связи по техническому собеседованию (по сути, её не стало как таковой), а это примерно 15–20% времени;
упростить процесс принятия решений по кандидатам благодаря единым критериям;
формировать рекомендации кандидатам в случае непрохождения собеседования;
поддерживать компетенции сотрудников через участие в найме, актуализировать разделы и критерии оценивания.
Самым важным для нас плюсом оказалось то, что нам удалось заменить трудоёмкий монотонный процесс найма на масштабируемый вариант с актуализацией знаний.
Хочу поблагодарить коллег, которые постоянно участвуют в описанном процессе и помогают улучшать наш сервис.
