Основное направление деятельности компании заказчика - финансовая аналитика, штат компании более 200 сотрудников. Основной задачей была автоматизация процесса найма. На тот момент вся документация была на сторонних сервисах: Гугл-документы, отдельные файлы в Excel в облачных хранилищах.

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

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

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

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

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

Подобный гибкий подход уже не раз выручал нас в других проектах. Когда мы писали платформу тестирования сотрудников MetaTest, благодаря ему, мы легко переделали систему из корпоративного масштаба одной компании в продукт с монетизацией, где тесты проходят сотрудники множества компаний. В ERP-cистеме ProcessCandy, которую мы сами используем в компании для продаж, найма и проектного управления, мы постоянно тестируем различные версии процессов, собираем статистику и на основе data mining корректируем процессы.

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

По пожеланию заказчика в качестве frontend-технологии был выбран React.js.

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

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

Нам удалось внести эти правки буквально за неделю, и т.к. мы работали по Time & Material, заказчик понял ,что у него остается приличный кусок сэкономленного бюджета. “Гулять так гулять” решил заказчик и попросил расширить систему с процесса найма до полного сопровождения сотрудников в компании. Так появился функционал кадрового учета, обращения в юридический отдел, трекинг производительности и структура компании отдельной вкладкой.

Уже после сдачи основного этапа за последующее время мы сделали дополнительно таск-менеджер, где есть возможность отправлять уведомления не только через email, но и в Telegram; автоматизировали отправку отчетов и уведомлений; сделали карты этажей и комнат и древовидную структуру отделов.

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