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

Вопрос в том, почему мы решили, что разговора в начале достаточно. — В англоязычной продуктовой среде для этого есть понятие Continuous Discovery — постоянное исследование. Но я бы не сводила его к идее “чаще разговаривайте с клиентами”. Это слишком плоское понимание.

Смысл в том, чтобы у команды была привычка регулярно сверяться с реальностью. Потому что большинство продуктовых решений сначала выглядят очень убедительно. - “Нужен дашборд.” - “Добавим уведомления.” - “Сделаем личный кабинет.” - “Покажем статус заявки.” Всё звучит разумно. Пока не начинаешь разбирать, какая именно проблема за этим стоит. — Например, “показать статус заявки” — это вроде бы понятное требование. Но что за ним? Пользователь не понимает, где процесс остановился? Не знает, кто сейчас ответственный? Боится, что про него забыли? Пишет менеджеру, потому что нет срока следующего шага? Или статус есть, но написан таким языком, что лучше бы его не было? От ответа зависит решение. — Мне нравится смотреть на интервью не как на источник “пожеланий”, а как на источник сигналов. После разговора важно вытащить не только “что попросили”, а: - точную цитату; - контекст ситуации; - наблюдение; - проблему; - возможное последствие; - гипотезу; - что нужно проверить дальше.

Например: “Я не понимаю, где зависла заявка.” Это может превратиться не в готовую фичу, а в гипотезу: Если пользователь будет видеть понятный статус, ответственного и следующий шаг, количество обращений к менеджеру по статусу снизится. А уже потом — в требование. И, желательно, в проверяемое: пользователь видит текущий статус заявки, ответственного участника процесса и следующий ожидаемый шаг, чтобы не обращаться к менеджеру за уточнением. Плюс критерий: количество обращений по теме статуса должно снизиться на 20%. — Получается простая цепочка: бизнес-цель → проблема → гипотеза → требование → критерий проверки. И вот её как раз часто не хватает. Мы легко перескакиваем от цели к решению. Или от интервью к фиче. Или от просьбы стейкхолдера к задаче в backlog. — Вижу в этом зрелость аналитической работы: не просто собрать требования, а постоянно проверять, на чём они стоят.

Потому что требование без подтверждённой проблемы — это не всегда ошибка. Но почти всегда риск.