Как запустить сервис для подбора сотрудников в стартап

Одна из проблем, с которой сталкиваются стартапы — это поиск команды. Для инвестора это важный параметр, прямо влияющий на размер инвестиций. И в этом месте сходятся 2 проблемы:

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

Об этих и многих других проблемах основатели стартапов узнают на преакселераторе. Это один из продуктов ФРИИ — обучающая онлайн-программа для тех, кто находится на стадии идеи или MVP. Здесь основатели компаний учатся смотреть на все глазами потенциальных инвесторов: ищут слабые места, изучают рынок, знакомятся с human resource management сравнивают продукт с конкурентами.

Для регистрации требуется заполнить достаточно объемную анкету, которую потом проверят эксперты, поэтому накопилась как база стартапов, так и люди, которые хотели бы в них работать. И так как ФРИИ сами заинтересованы в продвижении стартапов перед инвесторами (в том числе и с точки зрения команды), было решено создать новый продукт — сервис по поиску сотрудников в стартапы Cofoundit.

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

Задача — запустить полноценный продукт

Сначала продукт разрабатывался как внутренний сервис ФРИИ силами собственной команды. После проверки гипотез было решено превратить его в полноценный продукт — рекрутинговую систему.

Команда разработки hrm-продукта должна была создать веб-решение, учитывающее бизнес-логику и связанное с существующими системами ФРИИ.

Решение — быстрая разработка веб-приложения

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

Фронтенд проекта разработан на Angular, на бэкенде — Ruby-on-Rails-приложение. Для хранения данных был выбран PostgreSQL, обработка фоновых задач происходила с помощью Sidekiq и Redis.

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

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

• На вашем проекте много легаси или технического долга. В таком случае какое-то новое решение может просто не заработать со старыми частями.
• В проекте в первую очередь важны скорость и надежность. Эксперимент здесь может стоить десятков часов разработки, особенно в случае если в результате технология подходит под ваши требования не на 100%.
• Проект не сверхсложный, а у клиента нет собственной команды разработки или поддержки. Мы понимаем, что команды поддержки меняются, поэтому рекомендуем классический стек тем, кто не хочет долго искать узких специалистов.

В данном случае выбор стека был обусловлен требованием клиента.

Результат

Нам удалось целиком запустить для ФРИИ hr-сервис, который они позднее развивали и дорабатывали собственными силами. Сервис автоматизации подбора персонала претерпел 2 итерации изменений и помог многим стартапам встретить отличных сотрудников, дополнивших проект.