Как понять, что продукту нужен ИИ, а не ещё одна форма

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

Фраза «экономить время менеджера» слишком широка для проверки. Разложите её на действия: найти историю клиента, выделить ограничения, подготовить вопросы, согласовать предложение. Для каждого действия определите вход, ожидаемый результат и того, кто проверяет правильность. Затем выберите один узкий участок, где проблема повторяется и доступные данные позволяют помочь. Не объединяйте поиск фактов и принятие решения в одну непрозрачную кнопку. Пользователь должен понимать, что система подготовила, а что всё ещё требует его профессионального суждения.

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

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

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

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

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

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