Интервью с клиентом, после которого не появилось ни одного решения, — тоже результат

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

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

Не каждое «хочу» — задача для продукта

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

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

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

Когда отсутствие решения — хороший результат

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

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

Все четыре варианта экономят продукту время. Самая дорогая функция — не та, которую трудно написать. Самая дорогая та, которую написали уверенно, а потом она живёт в меню, усложняет поддержку и никому по-настоящему не помогает.

Как не превращать разговор в вежливое согласие

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

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

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

Пауза после интервью нужна не для красивого протокола

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

Затем можно задать простой вопрос: если мы ничего не разработаем, что именно останется сломанным? Если ответ расплывчатый, функция пока не созрела. Если ответ конкретный, появляется основа для дальнейшей работы: проверить частоту, поговорить с другими ролями, посмотреть данные, выбрать самый маленький способ изменить сценарий.

Такой подход защищает и от обратной ошибки — не отбрасывать неудобный сигнал только потому, что он пришёл от одного человека. Одиночный рассказ не равен статистике, но он может показать место, куда команда раньше не смотрела.

Что делать с разговором, который ничего не «принёс»

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

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

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

Короткий рабочий чек-лист

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

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

Отделяйте жалобу от направления работы

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

Полезно последовательно сузить разговор. Что именно человек пытался сделать? Что считал правильным результатом? В какой момент понял, что не справляется? Что сделал дальше? Кто ещё участвует в этом участке? Такая цепочка не выглядит допросом, если идти за реальной историей и не перебивать выводами.

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

Кому верить, если интервью противоречат друг другу

Разные ответы не означают, что кто-то ошибается. Часто люди находятся на разных этапах одного процесса. Менеджер хочет быстрее зарегистрировать заявку, специалист — получить в ней полные данные, руководитель — увидеть риск просрочки. Если смешать эти цели в одну «среднюю» просьбу, получится экран, который никому не помогает.

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

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

Нельзя подменять исследование обещанием

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

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

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