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

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

В целом невовлеченность руководителей — одна из главных проблем в оценке персонала. В России это видно по нашему исследованию 2024 г., в котором представители HR делились, в частности, трудностями, с которыми они сталкиваются в оценке [138].

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

Чтобы заказчик был вовлечен, его нужно включать (делать соавтором) в работу на трех этапах:

• Выяснение запроса и проблемы.

• Разработка критериев и выбор инструментов.

• Работа с результатами.

Эти три этапа я и разберу в этой главе.

7.1. Выяснение запроса

Заказчик редко приходит с задачей. Обычно он приходит с готовым (как ему кажется) решением: «оцените отдел продаж», «нам нужен вот этот тест — про него рассказал коммерческий директор из другой компании», «оцените лояльность коллектива». Но брать такие формулировки в работу нельзя: важно понять, чего на самом деле ожидает заказчик или что у него «болит».

Проведу аналогию с медициной. Если бы врачи выписывали лекарства по запросу пациента «Выпишите мне вот эти таблетки, соседке помогло» — скорее всего, медицина была бы намного ближе к знахарству, чем мы привыкли. Хороший врач начинает не с рецепта, а с вопросов: что болит, как давно, что уже пробовали. И только потом решает, какое лечение следует предложить. Специалист по оценке сначала вместе с заказчиком выясняет запрос — и только потом формулирует варианты решения проблемы. Разница с медицинским лечением состоит в том, что в отношениях оценщика и заказчика больше равноправия: ситуацию они исследуют вместе.

Разобраться, что перед вами, помогает различение двух типов запроса:

• Запрос на сервис звучит как заказ услуги: «нужен ассессмент», «оцените отдел», «проведите опрос». Решение заказчик уже выбрал — от вас ждут исполнения. Опасность такого запроса в том, что сервис можно выполнить безупречно и при этом ничего не добиться: задача не была проработана и инструмент был выбран неверно.

• Запрос на решение проблемы звучит как жалоба на ситуацию: «у нас текучесть», «менеджеры не дают результата», «продажи падают — разберитесь с людьми». Готового решения у заказчика нет, он ждет его от вас. Тут схожая опасность: велик соблазн перепрыгнуть к решению — например, к тестированию, — минуя диагностику.

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

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

Вот вопросы, которые я рекомендую задать заказчику до старта любого проекта тестирования (даже если вам не по душе предложенная типология запросов):

• Какое решение будет принято по результатам? Это главный вопрос, который ловит «красные флаги». Если по итогам тестирования не планируется никакого решения или действия — тестирование не нужно. Если планируется решение, которое нельзя принимать на основе тестов (увольнение, взыскание, премирование), — такой проект проводить нельзя.

• Какая бизнес-проблема стоит за запросом? Высокая текучесть, слабая воронка кандидатов, необходимость выбрать преемника. Проблема определяет, нужны ли тесты вообще и какие именно.

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

• Что будет считаться успехом проекта через полгода-год?Этот вопрос переводит разговор с процедуры («провести тестирование») на результат («снизить текучесть на испытательном сроке»).

• Кто, кроме вас, участвует в решении? У проекта нередко есть заказчик формальный и заказчик реальный: инициатива исходит от HR-директора, а решения по итогам будет принимать генеральный.

• Какие есть ограничения по срокам и бюджету? Банально, но именно ограничения часто определяют выбор между готовым инструментом провайдера и разработкой под задачу.

Конкретный набор вопросов существенно зависит от ситуации. Мой главный посыл — необходимо работать с запросом заказчика, а не брать его сразу в работу.

Запрос на сервис

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

Заказчик просит: «Организуйте тестирование руководителей в департаменте маркетинга и продаж». В ответ на вопрос об эффекте он может сказать: «Хочу, чтобы они наконец увидели свои слабые места и занялись развитием». Значит, задача — не оценка, а развитие, и сам по себе тест ее не решит: нужна связка тестирования с обратной связью и планом развития. Сервис остается тем же — тестированием, — но проект вокруг него собирается совсем другой. А будь ответ «хочу решить, кого из них двигать на директорские позиции», тот же запрос превратился бы в проект о кадровом резерве — с другими критериями и другим весом теста в итоговом решении.

Запрос на решение проблемы

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

• Симптомы. В чем именно проявляется «проблема»? Где, когда, как часто и в каком масштабе? Откуда мы об этом знаем — и надежен ли источник?

• Норма и отклонение. С чем мы сравниваем? Какое положение дел считали бы нормальным — и насколько текущее от него отклоняется? Без точки отсчета невозможно сказать, есть ли проблема вообще.

• Следствия. К чему ситуация приводит уже сейчас и что произойдет, если ничего не делать? Ответ определяет, надо ли вообще решать проблему — и сколько разумно потратить на решение.

• Причины. Почему это происходит и какие причины главные? Только здесь — впервые за весь разговор — становится понятно, есть ли в этой истории место тестам.

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

Для примера разберу запрос реального заказчика «высокая текучесть, мне нужно ее снизить». Симптомы: