Одна из самых частых болей в HRTech - Техническое задание. Причем болит всегда с обеих сторон - и у заказчика (как правильно составить и выбрать решение?), и у вендора (как правильно заполнить и соответствовать, чтобы победить в тендере?). Обычно выбор начинается одинаково. Команда открывает Excel и собирает требования: оргструктура, отчёты, AI-функции, мобильное приложение, интеграции, уведомления. Через несколько недель - ТЗ на десятки страниц. Вендоры ставят напротив каждого пункта «есть/нет/доработаем». Кажется, чем подробнее документ, тем объективнее выбор, но длинное ТЗ не снижает, а увеличивает риск выбрать не ту систему, потому что список функций становится главной моделью выбора, а бизнес-задача и пользователь - приложением к нему.

ТЗ фиксирует не то, что нужно. Большинство требований рождается из текущего процесса: «сейчас делаем так, значит новая система должна уметь то же самое». Компания ищет технологию, которая воспроизведёт существующий способ работы. А стоило спросить: этот процесс вообще нужно переносить в нынешнем виде?

Галочка «функция есть» ничего не говорит. Три системы: у всех «Да» напротив «автоматизация согласования заявки». В первой руководитель делает это за несколько действий, во второй - переходит в отдельный модуль и заполняет длинную форму, в третьей - сценарий требует кастомной настройки. По таблице три одинаковых «Да», для пользователя - три разных продукта. Демо должно быть экзаменом по вашим сценариям, а не экскурсией по интерфейсу.

Длинный список стирает приоритеты. Рядом оказываются «SSO обязателен» и «можно менять цвет виджета». Оба получают строку и балл. Продукт с десятками приятных функций может выиграть у того, кто лучше решает три критических сценария. Я делю требования на Must, Should, Could. Никакие баллы не компенсируют провал Must.

Что вместо огромного полотна? Шесть критериев. 1. Задача. Не «нужна новая ATS», а какое ограничение бизнеса снимаем, где оно в процессе, какой результат должен измениться. 2. Пользователь. Кто будет работать: HR, руководитель, сотрудник, кандидат, HRBP. Какие 3–7 действий критичны для каждой роли? Часто система удобна администратору, но неудобна руководителю, от которого зависит процесс. 3. Эффект. До просмотра продукта договоритесь: какие 2–4 метрики должны измениться, как измеряем, что считаем успешным пилотом. Иначе останется «кажется, стало удобнее». 4. Интеграции. Не «есть API», а кто master по данным, что и куда передаётся, как работает SSO, что при ошибке обмена. Это влияет на стоимость владения. 5. Риски. ИБ, персональные данные, зависимость от вендора. Для AI: где рекомендует машина, а где решает человек, как проверяются ошибки, что при низкой уверенности ответа. 6. Adoption. Часто отсутствует в ТЗ. Какое поведение людей должно измениться? Если руководитель продолжит писать feedback в Telegram, а рекрутер вести параллельный Excel, система внедрена, а результата нет. До выбора продукта определите: кто владелец внедрения, что человек начнёт делать по-другому, как обучаем и по какой метрике поймём, что система стала нормой.

Функции нужны, но вторым слоем. Сначала задача, пользователь, результат, workflow, ограничения. Затем функциональность, необходимая для этого сценария. Это меняет разговор с вендорами. Вместо «покажите вашу систему» - «вот наш процесс, три роли и пять сценариев. Покажите, как они проходят путь от заявки до решения». Сравнивать поставщиков проще: они демонстрируют одну задачу, а не сильные части своих продуктов. Зрелый вендор может предложить решение, о котором заказчик не подумал.

Хорошее ТЗ - не то, где больше требований. А то, которое позволяет отличить продукт, умеющий многое, от продукта, который решит именно вашу задачу и приживётся в работе. Я помогаю HR-командам собирать матрицу выбора HRTech: задача, пользователь, эффект, интеграции, риски, adoption, TCO, оценка вендора. Также помогаю со сценарием демо и критериями пилота. Приходите обсудить, если есть такая задача.