Сообщить об ошибкеКороткий ответ
Вместо прямых вопросов про метрики (на которые стейкхолдер не может ответить) использую косвенные вопросы о его реальных решениях и прошлом опыте: какие решения он принимал за последний месяц, что бы он хотел знать заранее, чтобы принять их раньше — и из этих ответов сам выведу релевантные метрики, предложив черновик на согласование.
Как это работает подробнее
стейкхолдеры часто хорошо знают свою работу и решения, но не умеют переводить их в язык метрик — вопрос «какие метрики нужны» для них абстрактен, а вопрос «что вы делали на прошлой неделе, узнав плохую новость о продажах» — конкретен и даёт материал для дизайна отчёта.
Что использовать на практике
- Применение. использую технику "job to be done": спрашиваю о последних 2-3 конкретных решениях или проблемах («расскажите о последнем случае, когда вам не хватило информации для решения»), смотрю на существующие отчёты/таблицы, которые стейкхолдер уже использует вручную (Excel, записи), и предлагаю черновой макет дашборда как отправную точку для итеративного обсуждения, а не жду точной спецификации заранее.
- Проверка или пример. Диалог: — «Расскажите про последний раз, когда вы приняли решение, опираясь на цифры по продажам». — «На прошлой неделе я увидел, что один регион сильно отстаёт, и перераспределил бюджет на рекламу». — «Что помогло бы заметить это раньше?» — «Наверное, сравнение регионов между собой по неделям». Вывод: отчёт должен включать сравнение продаж по регионам неделя к неделе с визуальным выделением отстающих — это конкретное требование, выведенное из рассказа о реальном решении, а не абстрактного вопроса.
Подводные камни
- Частая ошибка. пытаться получить полный список метрик одним вопросом и воспринимать нечёткий ответ как недостаток компетентности стейкхолдера, вместо того чтобы сменить технику опроса; строить финальную версию отчёта сразу, без промежуточного черновика-прототипа, рискуя сделать много ненужной работы, если первая версия не попадёт в ожидания.