От интервью до бэклога: как превращать пользовательские исследования в решения для продукта
На интервью пользователь говорит: «Добавьте фильтр по сроку». Для команды это звучит почти как готовая задача: понятно, что нарисовать, разработать и оценить.
Такую задачу рано ставить в бэклог.
Просьбу сохраняем вместе с записью разговора. Затем разбираем, что человек пытался сделать, где застрял и почему предложил именно фильтр. Иначе команда начинает с интерфейса и может аккуратно решить не ту проблему.
В Qtim мы начинаем аналитику с разговоров с бизнесом и пользователями, а затем переводим услышанное в гипотезы, требования и риски. Между цитатой и задачей у нас пять проверок. Они занимают меньше времени, чем разработка функции, которая никому не помогла.
Jira любит существительные. Нам нужно действие
Фильтр, кнопка, таблица, новый раздел — такие формулировки удобно переносить в трекер. Они называют элемент интерфейса. Работа пользователя остаётся за пределами карточки.
Представим, что человек вернулся к списку, чтобы сравнить два варианта по сроку. Это наблюдение. Фраза «ему не хватает сравнения на одном экране» описывает проблему. Фильтр, сортировка или таблица — варианты решения.
Смешать эти три уровня легко. В карточке появляется «добавить фильтр», разработчик оценивает поле и логику, а исходное действие исчезает. Позже уже никто не помнит, зачем пользователь хотел сокращать список и какие варианты он пытался сопоставить.
Даже фраза «пятеро попросили фильтр» оставляет нас на уровне ответов. Для задачи полезнее другая формулировка: «пользователи не могут быстро оставить в списке варианты, подходящие по сроку». Теперь команда может обсуждать несколько решений и сравнивать их.
Gallery: два фильтра, у каждого есть причина
В кейсе Gallery пользователь подбирает готовое дрон-шоу под конкретную площадку. Чтобы сузить каталог, мы заложили два параметра: размер флота и площадку. У каждого поля есть связь со сценарием запуска.
До разработки команда зафиксировала цели, аудиторию и ключевые метрики, затем собрала роадмап на 2,5 месяца. После брифа задача звучала так: «помочь подобрать шоу под условия запуска». Уже из неё появились параметры фильтра. Формулировка чуть длиннее. Зато разработчику не приходится угадывать смысл по названию поля — талант полезный, но в смету его обычно не закладывают.
Пять ответов, после которых появляется задача
Перед оценкой в карточке должны появиться пять ответов:
- Ситуация. Кто и в каком сценарии столкнулся с трудностью?
- Наблюдение. Что человек сделал, сказал и получил в результате?
- Связь с целью. Какое изменение в поведении или показателе мы ожидаем?
- Выбор. Какие варианты рассмотрели и почему остановились на этом?
- Проверка. Какой сигнал после релиза подтвердит или опровергнет решение?
Пустое поле показывает неопределённость. Команда может принять её ради дешёвого и обратимого теста. Дорогая интеграция, новый платёжный сценарий или переработка ролей требуют более сильной опоры.
Карточка ограничивает и бесконечный анализ. Сила проверки должна соответствовать цене ошибки. Небольшое изменение можно выпустить быстро. Решение, которое затрагивает оплату, безопасность или потерю данных, требует больше подтверждений.
Быстрый тикет переносит спор в разработку
Когда просьба о функции сразу становится задачей, вопросы никуда не исчезают. Они возвращаются на дизайне или уже внутри спринта: зачем нужно это поле, почему выбран фильтр, какой результат ждём после релиза. Команда идёт обратно к интервью, когда часть работы уже сделана.
Громкая цитата создаёт ещё одну ловушку. Один человек уверенно называет функцию, и его формулировка получает вес рынка. Поэтому рядом с цитатой мы сохраняем сегмент, контекст, частоту и тяжесть проблемы. Таблица наблюдений делает основания видимыми. Приоритет всё равно выбирает продакт.
Через несколько месяцев от задачи часто остаётся только название. Ссылка на разговор потерялась, сегмент забыли, ожидаемый эффект никто не записал. Тикет жив, а человек, который «вроде помнит контекст», как назло, в отпуске.
Цена такого сокращения пути — переделка дизайна, разработки и тестирования. Команда всё равно отвечает на пропущенные вопросы, только делает это после оценки или реализации.
После релиза фильтр должен доказать, что был нужен
Статус «готово» не завершает исследование. Мы возвращаемся к ожидаемому результату и смотрим, изменилось ли поведение: люди быстрее находят подходящие варианты, чаще доходят до сравнения или завершают заявку.
Фильтр может сработать. Может выясниться, что пользователи по-прежнему не понимают названия, не видят сроки или теряются в слишком длинном списке. Тогда команда обновляет вывод и выбирает следующую реакцию.
Вернёмся к просьбе «добавить фильтр». Задача готова к бэклогу, когда команда может показать путь от исходного наблюдения до цели продукта, выбранного решения и проверки после релиза.
Перед оценкой следующего тикета восстановите этот путь. Разобрать один ключевой сценарий можно вместе с нами.
