Как разработать ПО для подбора персонала и не облажаться

how-to-develop-ats-software

Владимир Курило — CEO и идеолог корпоративной системы для рекрутинга CleverStaff — рассказал, какие нюансы нужно учесть и какие могут возникнуть сложности при разработке системы для рекрутеров своей компании.

Некоторые компании разрабатывают программную систему специально для своих рекрутеров. Это технологически непростая задача.

Я знаю, как её решать в деталях, поскольку руководил разработкой “с нуля” успешной облачной и корпоративной системы для найма.


Прочитав эту статью, вы узнаете:

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

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

 

Что такое система для рекрутинга?

 

Рекрутеры — это люди, подбирающие персонал.

Система для автоматизации рекрутинга — это программное решение, в котором рекрутеры могут:

  • Удобно вести рабочую базу кандидатов и вакансий;
  • Работать совместно, разделять ответственность и устанавливать напоминания;
  • Упростить и автоматизировать ведение базы данных и подбор персонала.

Рекрутеры ведут свою базу кандидатов, чтобы сохранять контакты, историю общения и результаты по каждому претенденту на вакансии.

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

 

Какой должна быть система? Требования.

 

I. Минимальные функциональные требования

 

Требования, без которых систему не стоит запускать:

1. Добавление в базу и редактирование данных по вакансиям, кандидатам, заказчикам. Возможность написания комментариев по ним.

2. Поиск вакансий и кандидатов по нескольким параметрам.

3. Лёгкость ведения базы данных.  Эта важнейшая функция сводится в основном к простоте и скорости добавления кандидатов в систему: рекрутеры добавляют в базу сотни резюме в месяц.

Кандидатов можно добавить в систему из:

  • файлов резюме в электронном виде;
  • онлайн-профиля в LinkedIn;
  • онлайн-резюме на сайтах поиска работы.

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

А что, если рекрутеры получили 30-200 откликов по вакансии на сайте поиска работы? Переносить их в систему вручную — трудоемко, даже если требуется перенести лишь часть из них. Если же переносить в базу не всю информацию, это отразится на дальнейшей эффективности работы.

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

Я специально привел аргументы и примеры, т. к. выполнение или не выполнение этого пункта определяет успех или провал системы. Сейчас есть много облачных программ для рекрутинга, а также решений, разработанных специально под конкретную компанию. Многие потерпели крах именно из-за пренебрежения парсингом резюме (автоматический перенос данных системой из загруженных файлов) и интеграцией с LinkedIn, сайтами поиска работы, электронной почтой.

4. Защита от дублирования кандидатов (их резюме) в базе. Не стоит недооценивать важность и сложность этой задачи. Ниже расскажу почему.

5. Совместная работа команды нанимателей с общей базой вакансий и кандидатов. Это включает возможность назначать ответственных рекрутеров по конкретным вакансиям и кандидатам.

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

7. Фиксирование истории каждого действия пользователями в системе. Это позволяет формировать отчеты о проделанной работе, статистику по работе рекрутеров и закрытию вакансий, а также точно знать, кто, что и когда именно сделал.

 

II. Обязательные функциональные требования

 

Очень важные. Без их выполнения можно запустить систему и какое-то время работать, принимая обратную связь от пользователей. Но без них система неполноценна и оставляет рекрутерам много “ручных” рутинных действий. Эти требования лучше выполнить еще до запуска или в кратчайшие сроки после запуска.

1. Полнотекстовый поиск по файлам резюме.

2. Уведомления о важных действиях и событиях на почту и в интерфейсе.

3. Интеграция с онлайн-календарём (Google Calendar, Outlook, и т.д.).

4. Удобные и настраиваемые этапы для кандидатов по вакансии (workflow вакансии) и причины отказов кандидатов.

5. Интеграция с email:

  • перенос в базу данных резюме, которые пришли рекрутеру на e-mail;
  • сохранение истории e-mail переписки с кандидатами на их страницах в системе;
  • возможность автоматически отправить кандидату напоминание о собеседовании с адресом и картой проезда.

6. Отчёты о проделанной работе по вакансии.

7. Отчёт по результатам работы каждого рекрутера за конкретный период.

8. Поиск по ФИО кандидата с транслитерацией, как умеет Facebook.

9. Понятное, “интуитивное” взаимодействие с программой (и весь UX интерфейса в целом).

Когда система усложняется, усложняется и внедрение функций. Как все правильно разместить в интерфейсе, подписать, правильно расставить акценты, чтобы все функции были понятны и под рукой? Нужно выдать пользователям мощные и удобные функции и в то же время не перегрузить интерфейс.

 

III. Продвинутые требования

 

Они нужны для увеличения эффективности работы. Для некоторых компаний отдельные пункты нужно причислить к обязательным, для некоторых они пока совсем не нужны. Это зависит от потребностей вашего HR-отдела.

1. Отчёт по источникам появления кандидатов.

2. Расчёт средней зарплаты по кандидатам, отобранным на вакансию.

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

4. Страница со всеми вакансиями компании, которую можно удобно внедрить на корпоративном сайте.

5. Возможность дать заказчику доступ к вакансиям в программе, чтобы он мог просматривать все отобранные резюме и отмечать по ним решения без общения с рекрутером.

6. Матчинг (автоматические рекомендации) подходящих кандидатов: система определяет в базе наиболее подходящих под заданные требования вакансии кандидатов по их резюме и предлагает рекрутеру.

7. Массовая загрузка новых резюме в базу в виде архива с файлами резюме.

8. Ведение задач по кандидатам и вакансиям с напоминаниями.

9. Мобильное приложение или удобная мобильная версия сайта.

10. Рассылка кандидатам вакансий на почту.

11. API для интеграции с сайтом или внутренними программами компании.

 

IV. Требования к безопасности

 

1. Шифрование паролей. С солью.

Для многих программистов и архитекторов ПО это само собой разумеется. При этом шифрование паролей многие игнорируют.

Не так давно была утечка части базы Яндекса с логинами и паролями от почты. Еще раньше у ведущих сайтов поиска работы функция “Забыли пароль?” просто присылала на почту пароль в открытом виде. Выходит, он так и хранится в базе в открытом виде. Некоторые сайты перестали так делать и выдают ссылку для смены пароля. Правда, это не значит, что пароли зашифрованы.

Зачем это делать?

Пароли в открытом виде может тайно кому-то передать или “слить” в сеть кто-то из администраторов. Руководство даже ничего не узнает о махинациях. Третьи лица могут скопировать себе данные из системы, потому что они заходят в нее по известным логинам и паролям, и им все доступно.

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

Зашифрованные пароли — это профессиональный подход. Лучше не брать на себя риски утечки паролей. Если кто-то получит хорошо зашифрованные пароли, расшифровать и воспользоваться ими будет практически нереально.

2. Шифрованное SSL соединение.

Шифрование защищает данные от перехвата. Если в адресе сайта есть “https”, это значит, что данные от браузера к серверу передаются зашифрованными и их перехват будет бесполезен. Логин и пароль не смогут перехватить. Это легко и дёшево сделать для любого сайта.

3. Бекапы (откаты изменений системы). Само собой.

 

V. Важные технические требования

 

1. Вечные пользовательские сессии, которые не занимают оперативную память.

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

2. Для полнотекстового поиска по резюме нужно использовать специальный “движок”.

Например, Apache Solr. Он вряд ли будет эффективно работать сразу после внедрения. Его необходимо донастраивать, проводить много тестов. Это творческая и интеллектуальная работа.

3. База данных быстро увеличивается.

Нужно строить эффективные индексы и писать эффективные SQL-запросы.

4. Программисты должны уметь находить и устранять утечки памяти.

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

 

VI. Нюансы поддержки и развития ПО

 

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

1. Интеграция периодически нарушается или перестает работать из-за изменений в LinkedIn, на сайтах поиска работы или в почтовых сервисах.

2. Выход новых версий браузеров вносит изменения в интерфейс пользователей. У них может что-то “поехать”, перестать работать или начать выглядеть хуже.

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

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

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

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

 

VII. Рекомендации перед началом разработки

 

Для разработки “с нуля” системы для рекрутинга, которая соответствует минимальным и обязательным требованиям, может потребоваться 35-50 человеко-месяцев работы.

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

Что нужно сделать перед началом разработки, некоторые рекомендации:

1. Детально расписать, какие функции ПО предпочтительны и достаточны для рекрутеров. Можно отталкиваться от списка, приведенного выше.

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

3. Определить, чем пользоваться, пока система в разработке.

4. Запросить коммерческие предложения от узкопрофильных поставщиков систем для рекрутинга.

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

 

VIII. Как можно облажаться

 

1. Потратить неприемлемо много денег.

При средней стоимости человеко-месяца для компании на уровне 1 500 USD (экономно), стоимость всей разработки составит от 52 500 до 75 000 USD. Напомню, это из расчета 35-50 человеко-месяцев работы.

Для примера: такие гиганты, как SoftServe и GlobalLogic разрабатывают свои системы для найма уже несколько лет (!).

Тут есть еще такой неприятный фактор: жалко бросать проект после того, как его долго делали и много денег вложили.

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

2. Разрабатывать слишком долго, вынуждая рекрутинг страдать быть неэффективным все это время.

3. Делать-делать и недоделать. Или отдать рекрутерам софт в таком плачевном состоянии, что они не захотят им пользоваться.

Так бывает, когда сменяется руководство или HR-директор, которые участвовали в принятии решения о разработке.

Желаю вам успехов в этом затягивающем и увлекательном деле!

 

Владимир Курило
CEO @ CleverStaff.net

Понравилась статья? Поделиться с друзьями:
x