Читать книгу - "Тесты для оценки персонала: Как принимать кадровые решения на основе данных, а не ощущений - Юрий Шатров"

• Рассылка приглашений и автоматических напоминаний, в том числе массовая.

• Ограничение времени прохождения теста и контроль статусов участников: кто приглашен, начал, завершил, не приступил.

• Возможность поставить тест на паузу.

Отчеты и выгрузка данных.

• Автоматическое формирование отчетов — отдельно для участника и отдельно для заказчика или эксперта.

• Групповые отчеты и выгрузки по всей выборке, а не только по одному человеку.

Безопасность и юридическая чистота.

• Платформа обрабатывает персональные данные, и ответственность здесь ваша.

• Хранение данных в России и соответствие Закону №152-ФЗ.

• Сбор согласия на обработку персональных данных.

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

• Возможность отразить вашу организационную структуру — активы, локации, департаменты.

• Разграничение прав доступа как минимум на два уровня — администратор и эксперт по оценке или подбору (чтобы никто не увидел чего-то лишнего).

Надежность и поддержка. Справедливости ради, это проверяется не на демоверсии, а уже в «боевом тестировании».

• Поведение платформы при массовом одновременном входе — для проектов на сотни и тысячи участников это критично.

• Доступность техподдержки в часы тестирования и понятный канал эскалации сбоев.

• Обучение и инструктаж администраторов с вашей стороны.

Розничная сеть несколько лет отбирала директоров магазинов с помощью теста способностей одного провайдера. Когда HR-аналитики решили проверить, предсказывает ли тест успешность магазинов, выяснилось, что платформа отдает только готовые PDF-отчеты по каждому кандидату — выгрузки баллов в таблицу не было вовсе. Чтобы собрать данные для исследования, пришлось бы вручную открывать и перепечатывать более тысячи отчетов. Провайдер пять месяцев писал модуль групповых отчетов, чтобы компания смогла выгрузить все данные скопом. Этот кейс про то, что вопрос о выгрузке групповых результатов стоило задать при покупке теста.

В России основные проверенные платформы для тестирования — Linkis.pro («ЭКОПСИ»), ETEST (Talent Q), SHLTOOLS («Бизнес Психологи»), Maintest («Гуманитарные технологии»), ONTARGET (DeTech), StartExam, Planka (ANCOR), «Индиго» (РАНХиГС).

Ваши тесты на платформе провайдера

Иногда у вас уже есть собственные тесты — вы разработали их сами или с консультантом, — а строить под них платформу с нуля не готовы. Тогда вы арендуете «движок» у вендора и загружаете в него свой контент.

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

Конструктор теста и форматы заданий.

• Платформа должна уметь то, что заложено в вашем тесте, а не наоборот.

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

• Настройка структуры теста: число пунктов, размер банка (×2, ×3), правила рандомизации, разделы, лимиты времени.

• Если тест адаптивный или с ветвлением — поддерживает ли это движок или он рассчитан только на линейные тесты.

Свой скоринг и свои шкалы.

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

• Привязка пунктов к вашим шкалам и конструктам так, как задумано в тесте.

Свои тестовые нормы.

• Загрузка ваших норм (процентили, стены) и пересчет результатов по ним.

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

Свои отчеты и интерпретации. Готовые шаблоны отчетов вендора под ваш тест почти наверняка не подойдут.

• Настройка шаблонов отчетов под ваши шкалы и брендинг.

• Подстановка в отчеты ваших текстов-интерпретаций.

Психометрика и апробация. Раз методика ваша, вам ее и поддерживать, и развивать.

• Аналитика на уровне пунктов: сложность, дискриминативность, работа дистракторов. Без нее вы не сможете «чистить» банк и улучшать тест.

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

Брендирование.

• Ваш логотип, цвета, домен, приглашения с вашего адреса — и нигде не должно «проступать» имя вендора.

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

Разработка собственной платформы

Иногда компания решает не арендовать «движок» у провайдера, а создать платформу под себя. На практике это оправдано редко и только при сочетании нескольких условий: очень большие объемы тестирования (тысячи участников в год); уникальные тесты, которые не тянут вендоры; жесткие требования к безопасности и хранению данных (госсектор, силовые структуры, банки — данные не должны покидать контур компании). Во всех остальных случаях я отговариваю от этого: своя платформа не проект с началом и концом, а IT-продукт, который придется постоянно поддерживать и развивать. Главные расходы здесь не на разработку, а на сопровождение после запуска.

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

Модули, из которых состоит платформа для тестирования

Сюда же добавляются два сквозных слоя, без которых платформа не живет: безопасность и хранение персональных данных (соответствие Закону №152-ФЗ, резервное копирование) и интеграции с другими системами (про обмен с ATS/LMS/HCM — в следующем разделе).

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

Крупный агрохолдинг решил построить собственную платформу тестирования, чтобы не платить вендору за каждое прохождение — при больших объемах это казалось дорогим. В течение года команда писала все: рассыльщик, модуль управления участниками, конструктор, движок проведения, отчеты. Запустились без особых проблем. А дальше началось то, к чему не готовились: каждое обновление браузеров что-то ломало, посыпались обращения от администраторов. Через два года деньги, сэкономленные на вендоре, были многократно съедены зарплатой постоянной команды. В итоге проведение тестов вернули вендору, а у себя оставили только то, ради чего все затевалось, — сложную логику скоринга под свои тесты.

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