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

Главная страница

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

Мы сразу заметили, что в системе есть несколько ролей, у которых совсем разные цели и задачи. А так как сама система еще не была определена до конца, то нужно было заранее заложить механизм прав доступа. Лучше всего подходил классический паттерн Access Control List – где пользователи обладают ролями, а роли распоряжаются ресурсами. Это оказалось удачным решением, ведь добавление новых возможностей в процессе разработки легко было согласовать с системой доступа.

Когда была готова первая версия, заказчик решил расширить область применения системы. Теперь она должна была работать не внутри одной компании, а быть облачным продуктом для многих компаний. И еще раз нас выручила система ролей, достаточно было перераспределить уже размеченные ресурсы и добавить роль «Супер-администратора».

На данном этапе уже было понимание того, как должна работать система.

Прохождение теста

Отчет по тесту

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

Обмен сообщениями

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

Редактирование шаблона отчета

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

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

После некоторых размышлений мы решили написать особый язык конструктора отчетов, т.н. DSL (Domain Specific Language). За основу мы взяли шаблонизатор Twig, ведь в первую очередь язык был нужен для создания документов. Twig с одной стороны является полноценным языком с условиями, циклами и переменными, с другой – абсолютно безопасен и его шаблоны не имеют доступа к основному коду. Чтоб сделать его настоящим DSL мы добавили в Twig функции вывода графиков, таблиц и статистических расчетов. Также для каждого отчета уже были доступны переменные с наиболее часто используемыми данными – средним, дисперсией, списком ответов и т.п.

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

В итоге получился стабильный сложный по сути, но простой в управлении продукт. Своими главными достижениями мы считаем грамотное выяснение деталей процесса тестирования до написания кода (т.н. Requirements Specification) и удачное решение с конструктором шаблонов.