Что спросить у заказчика перед разработкой ИИ-продукта

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

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

Начните с одной недавней операции

Перед беседой запишите гипотезу: «Хотим понять, как из входящего обращения получается карточка для менеджера». Так проще заметить, что разговор ушёл в общие планы автоматизации. GOV.UK рекомендует превращать допущения в исследовательские вопросы. Если на встрече только руководитель, попросите затем поговорить с исполнителем операции и человеком, который принимает её результат: их описания могут различаться.

Вместо «Вам нужен ИИ, который сам отвечает?» спросите:

• «Вспомните последнее обращение такого типа. Откуда оно пришло и что произошло дальше?»
• «Что вы открыли, чтобы понять, кому его передать? Где нашли недостающие сведения?»
• «Как выглядел готовый результат? Покажите обезличенный вход и итог, если это разрешено».
• «Что вы делаете, когда данных не хватает или сведения противоречат друг другу?»

Это вопросы о фактической работе. Они допускают ответ «спросили коллегу» или «оставили поле пустым», который легко потерять в разговоре о желаемом интерфейсе. GOV.UK в discovery предлагает изучать текущий путь пользователя, служебные роли и имеющиеся данные. Не просите переслать реальные клиентские письма в неутверждённый чат или личный аккаунт; сначала договоритесь, какие примеры разрешено показывать и где хранить заметки.

Найдите исключение, запрет и владельца решения

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

Отдельный блок вопросов касается полномочий:

• «Какие данные можно использовать в пробе? Кто разрешает доступ к рабочему источнику?»
• «Что решение может только предложить, а что ему разрешено записать или отправить?»
• «Кто заметит ошибку, кто её исправит и как узнает, какое обращение было исходным?»
• «Кто принимает результат и по каким наблюдаемым признакам?»

Вопрос «сколько времени хотите сэкономить?» полезен лишь вместе с исходной точкой: сколько работы занимает операция сейчас, чем это измерено и какие расходы добавит проверка результата. Если данных нет, не записывайте ожидаемую экономию как требование или прогноз. Atlassian описывает discovery как выяснение нужд и проверку идеи до реализации; само интервью остаётся одним способом собрать свидетельства, а не испытанием будущего продукта.

Протокол: отделите слова, пример и предположение

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

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

Скопируйте пустую форму для своей встречи:

Закончите беседу проверкой понимания

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

Если нельзя получить уполномоченного собеседника, допустимый пример или согласованный критерий приёмки, не обещайте рабочую автоматизацию. Можно показать ограниченный прототип на учебных данных и честно назвать его предположения. Если выяснится, что задержка возникает из-за неясного распределения заявок, следующим шагом может быть правило передачи между людьми, а не агент. Когда вводные подтверждены, их можно использовать для выбора способа реализации; сравнение цифровых сотрудников под конкретный процесс полезно, если вы рассматриваете готовые варианты.