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

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

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

12.2. Интеграция платформы для тестирования с «материнской» системой

Платформа для тестирования зачастую не живет сама по себе. Тестирование — это часть какого-то HR-процесса (подбора, обучения, работы с кадровым резервом), а процесс этот идет в другой, «материнской» системе: ATS в рекрутменте, LMS в обучении, HCM в управлении персоналом. Если две системы не связаны, рекрутер вручную переносит данные кандидата в платформу тестирования, а потом руками же переносит результаты обратно. При десятке кандидатов это терпимо, при тысячах — превращается в отдельную работу. Интеграция как раз и убирает этот ручной труд.

Потоки интеграции

Платформы общаются потоками — как бы передают друг другу данные. В случае тестирования есть два основных потока:

• Создание сессии. Материнская платформа передает данные участника на платформу тестирования, та заводит сессию и возвращает ссылку на тест.

• Возврат результатов. Платформа тестирования отдает обратно результаты участника — числовые результаты, статус «прошел / не прошел», ссылку на индивидуальный отчет (или сам отчет).

На практике к ним могут добавиться еще несколько потоков:

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

• Запуск и единый вход. Участник или сотрудник HR запускает тест из материнской системы без отдельного логина. В обучении для этого есть отраслевой стандарт — LTI (Learning Tools Interoperability), по которому LMS «вшивает» тест прямо в курс и возвращает результат в журнал.

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

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

Что нужно учитывать

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

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

• Есть ли вообще чем интегрироваться. Первое, что нужно проверить, — зрелость API (интерфейс для взаимодействия между платформами) у обеих систем. Бывает API с готовыми «мостиками» к популярным ATS/LMS, бывает «голый» API, под который нужна разработка, а бывает, что обмен возможен только файлами. Для обучения отдельно спрашивайте про поддержку LTI.

• Как сопоставляются участники. Нужен надежный уникальный ключ (ID кандидата или сотрудника), по которому системы узнают одного и того же человека. Сопоставление по Ф. И. О. или почте рано или поздно дает сбой — однофамильцы, смена почты, — и результаты прилетают не тому человеку.

• Что именно возвращать. Решите заранее, какие данные уходят в материнскую систему: только «прошел / не прошел», общий балл, баллы по шкалам или полный отчет. Часто достаточно вернуть статус и ссылку на отчет, а сам отчет хранить на платформе тестирования.

• Синхронность. Это совсем техническая деталь, но она важна. Тестирование почти всегда асинхронно: участник проходит тест не сразу, а в течение нескольких дней. Значит, результаты должны возвращаться событием (по вебхуку или колбэку [44]), а материнская система не должна зависать в ожидании.

• Безопасность передачи. Между системами ходят персональные данные. Канал должен быть зашифрован, авторизация — по токену, и ни в коем случае нельзя передавать данные участника в открытом виде в параметрах ссылки. Данные с обеих сторон должны храниться в РФ.

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

• Кто владеет интеграцией и поддерживает ее.Интеграция не разовая работа: как только одна из систем обновляет API, связка может отвалиться.

Если коротко: начните со «скелета» из двух потоков, добавляйте остальные по мере роста объема и держите в голове, что интеграцию придется не только построить, но и постоянно поддерживать в рабочем состоянии.

[44] Вебхук (webhook) и колбэк (callback) — механизмы, при которых одна система уведомляет другую о каком-то событии. В нашем случае: как только участник завершил тест, платформа тестирования сама стучится в HR-систему и передает в нее результаты.

Как использовать тесты этично

До этой главы я рассматривал тесты преимущественно как полезный и эффективный инструмент оценки персонала. Но тесты могут использоваться — осознанно или неосознанно — и во вред людям; по выражению Александра Шмелёва, как оружие [161]. Причем даже вредоносное использование тестов может прямо не противоречить законодательству. Поэтому здесь необходимо выйти на более зыбкую почву, в плоскость этики. Я рассмотрю семь случаев неэтичного или вредоносного использования тестов — от совсем жестких и однозначных кейсов до менее определенных.

13.1. Тесты как инструмент евгеники

Евгеника понималась как «улучшение» населения через контроль за размножением, при этом тесты интеллекта и знаний превращались в фильтры «достойности» родительства. В США в 1907–1974 гг. в более чем 30 штатах действовали законы о стерилизации «умственно дефективных» (термин того времени); количество операций исчислялось десятками тысяч. Символом институционализированной практики стерилизации по результатам тестирования интеллекта стал интернат Сонома в Калифорнии, в котором было проведено около 5500 операций. Похожее происходило в Канаде (акты в отдельных провинциях: IQ ниже 70 — стерилизация, около 3000 человек), в нацистской Германии (около 400 000 принудительных стерилизаций и 70 000 убийств), в Швеции (63 000 стерилизаций). Аналогичные программы существовали в Дании, Финляндии, Норвегии.

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