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

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

Определите роли через действия

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

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

GOV.UK рекомендует исследовать не только конечных пользователей, но и людей, которые предоставляют услугу или помогают другим ею пользоваться. Для предпринимательской задачи этот принцип полезен как напоминание: опыт одного участника не описывает всю систему принятия и использования решения.

С пользователем исследуйте выполнение задачи

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

В учебном примере администратор учебного центра переносит записи из сообщений в расписание. Он хочет быстро видеть свободные места и не допускать двойной записи. Разговор о том, какой бюджет центр выделит на внедрение, может дать лишь догадку: администратор в финансовом решении не участвовал.

Задайте вопросы о внедрении: кто подготовит данные, когда можно учиться, что произойдёт с текущими записями. Это помогает обнаружить работу, которую покупатель может не замечать. Удобная функция не компенсирует переход, для которого никто не выделил время.

С покупателем исследуйте основание решения

Попросите рассказать о последнем сопоставимом приобретении. Как появилась необходимость потратить деньги? С чем сравнивали предложение? Кто проверял риск? Какие документы понадобились? Что считалось приемлемым результатом и кто отвечал за его оценку?

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

Не превращайте беседу в запрос универсальной цены. Сумма без состава работ, периода и условий мало что объясняет. Уточняйте фактическое решение: что приобретали, какие расходы включали, что делали собственными силами и почему некоторые варианты отклонили.

Сопоставляйте рассказы по одному случаю

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

В учебном примере руководитель считает, что перенос расписания занял час. Администратор вспоминает три вечера исправления ошибочных записей. Не выбирайте победителя голосованием. Уточните, что каждый включил в слово «перенос»: загрузку файла, подготовку исходных данных или последующую проверку.

Не пересказывайте одному участнику личные оценки другого без разрешения. Для уточнения можно спросить о самом процессе: «Какие работы были после загрузки?» Это сохраняет исследовательскую задачу и не превращает интервью в разбирательство между сотрудниками.

Администратор три вечера исправлял записи. Руководитель оценил тот же перенос в один час и покупает систему из-за второй площадки.
Час и три вечера — разный состав слова «перенос». Бюджет со слов пользователя не подтверждают.
Пользователь
Администратор переносит записи и три вечера исправляет ошибки. Он видит свободные места и двойную запись и не участвует в финансовом решении.
Покупатель
Руководитель оценивает перенос в один час. Повод покупки — вторая площадка и понимание, кто менял расписание.

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

Переведите различия в требования

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

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

Практическое задание

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