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

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

Ты не пользователь

Главная причина говорить с людьми в том, что ты на них не похож. Ты знаешь продукт изнутри, ты технически грамотен, ты помнишь, где какая кнопка. Пользователь — нет. То, что тебе очевидно, его останавливает; то, что тебе кажется важным, он не замечает. Свои привычки ты бессознательно приписываешь ему — и проектируешь для воображаемого человека, похожего на себя.

Это не лечится умом и опытом. Даже сильная интуиция — это сжатый прошлый контакт; когда контакт устаревает или его не было, интуиция уверенно врёт. Поэтому вопрос не в том, умный ли ты, а в том, давно ли ты смотрел, как реальный человек делает свою работу.

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

Три формы контакта

Контакт не обязан быть исследованием на месяц. Достаточно трёх простых форм, и все доступны одному человеку.

Первая — короткий разговор. Десять-пятнадцать минут с тем, у кого есть та самая задача. Не презентация твоей идеи, а расспрос про его работу: как он сейчас это делает, что в последний раз пошло не так, сколько это заняло. Найти человека проще, чем кажется: написать напрямую с коротким объяснением («делаю инструмент для X, хочу понять, как вы сейчас это делаете — 15 минут?») работает лучше, чем ждать «правильного момента».

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

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

Три разговора: что на самом деле узнаёшь

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

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

Разговор с менеджером. Говорит, что хочет видеть, кто работает в выходные. Просишь показать, как делает это сейчас. Открывает Excel с вкладками по неделям — создан три месяца назад, заполнены только последние две недели, остальное пусто. Спрашиваешь: «Зачем тогда просить функцию, которая у вас уже есть?» Молчание, потом: «Наверное, дело не в этом. Я просто не хочу заполнять это вручную каждую неделю». Настоящая задача — автоматически формировать расписание по правилам ротации, не поддерживать таблицу руками.

Разговор с курьером. «Как ты узнаёшь о своей смене?» — «Менеджер пишет в общий чат за день, иногда забывает». — «Бывало, что вышел не в ту смену или узнал слишком поздно?» — «Два раза так было». Это отдельная проблема: расписание не доходит до исполнителя надёжно и вовремя.

После трёх разговоров картина полностью другая: не «нужен удобный календарь», а три связанные задачи — автоматическое составление расписания, уведомление о невыходе в реальном времени, надёжная доставка расписания курьеру. Красивый интерфейс — последнее, что здесь важно. Без этих разговоров ты потратил бы несколько недель на UI поверх воображаемой проблемы и удивлялся, почему инструментом почти не пользуются.

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

О чём спрашивать, а о чём бесполезно

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

Отсюда же главные ловушки. Наводящий вопрос («удобно же, правда?») вытягивает подтверждение, которое ты сам и заложил. Рассказ о своей идее до того, как расспросил человека, сбивает его на оценку твоей задумки вместо описания своей боли. Усреднение — «обычно я…» — прячет реальные случаи; нужно тянуть к конкретике: «когда именно в последний раз, что тогда произошло». Продукт-инженер слушает в разы больше, чем говорит, и держит свои решения при себе, пока не услышал проблему.

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

Замкнуть петлю в работе одного

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

Но и ответственность та же — петлю обратной связи никто за тебя не замкнёт. Замкнуть — значит не только спросить до, но и посмотреть после: как пользуются тем, что выкатил, делают ли то, на что ты рассчитывал, ушла ли боль. Этот «после» — уже про бизнес-метрику: контакт говорит, что чинить, метрика — починилось ли. Без обоих ты гребёшь вслепую, как бы быстро ни грёб.

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

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

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

Контакт — не этап перед разработкой. Это непрерывная часть самой разработки.

Что это значит на практике

Контакт с пользователем — не разовое мероприятие перед стартом проекта, а ритм работы. Маленькие, частые касания лучше, чем большое исследование раз в квартал. Пять минут разговора в начале задачи и пять минут обратной связи после выкатки — это и есть минимальная рабочая петля.

Ошибки, которые повторяются чаще всего:

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

Дальше

Контакт даёт картину проблемы — дальше нужно выбрать, что строить первым, и договориться с собой, как понять, что сработало. Об этом — «Наименьший ценный срез» и «Бизнес-метрики». А о том, как устроена роль продукт-инженера в целом — кто это, что он делает и почему один человек с агентом может больше, чем раньше могла команда, — в обзоре «Продукт-инженер».