Как задавать правильные вопросы стейкхолдерам
customers поле lifetime_value_text хранится как текст. Вы делаете топ клиентов по выручке, но сортировка выглядит неверно (например, 100 идёт раньше 20). Как исправить ORDER BY?Почему это критично
Каждый опытный аналитик через это проходил: тратишь 3 дня на анализ, показываешь стейкхолдеру — «ой, я не это имел в виду».
Причина — неправильно поняли задачу в начале. Плохие уточняющие вопросы на старте → потраченная впустую работа.
Привычка задавать правильные вопросы — главный мультипликатор продуктивности аналитика.
Общий фреймворк
Перед любой задачей нужно получить ответы на:
1. Зачем. Зачем этот анализ?
2. Какое решение. Какое решение будут принимать на его основе?
3. Кто использует. Кто будет пользоваться результатом?
4. Когда. К какому сроку?
5. Определение. Точные определения метрик и сегментов.
6. Формат. Слайд? Дашборд? Доклад? Ванпейджер?
Пропустить хоть один — риск рассинхрона.
Техника «5 почему»
Классический приём от Toyota. Задавайте «почему» 5 раз, чтобы докопаться до корневой задачи.
Пример:
Стейкхолдер: «Дай мне конверсию за Q1».
Почему 1: «Зачем нужно?» → «Хочу посмотреть, вверх или вниз».
Почему 2: «Почему это важно?» → «Планирую маркетинговый бюджет на Q2».
Почему 3: «Что конкретно решаешь?» → «Увеличить Facebook Ads или Google Ads?».
Почему 4: «Почему именно эти каналы?» → «Не очень доверяю атрибуции Facebook».
Почему 5: «Нужна помощь с анализом атрибуции?» → «Да, было бы супер!».
Реальный вопрос не «конверсия», а «качество атрибуции Facebook».
Разные анализы — для разных вопросов.
Уточняющие вопросы по типам задач
«Проанализируй X» (размыто).
- Какой именно ракурс интересует? Тренды, состав, сравнение?
- Что пытаетесь понять или решить?
- С чем сравниваем?
- Есть ли гипотеза?
«Почему X упал или вырос?»
- Когда точно началось изменение?
- На сколько? В п.п. или относительно?
- Сравнение с чем (вчера, прошлая неделя, прошлый месяц, прошлый год)?
- Какие внешние события могли повлиять?
- Были ли изменения в продукте?
«Построй дашборд».
- Кто будет пользоваться? Ежедневно, еженедельно, ежемесячно?
- Какие решения будут приниматься?
- Какие метрики самые важные?
- Где эти данные смотрят сейчас?
- Нужна ли интерактивность?
«Оцени A/B-тест».
- Когда запущен и завершён?
- Какая гипотеза?
- Какая первичная метрика?
- Guardrail-метрики?
- Размер выборки и расчёт мощности?
- Нужна ли сегментация?
Холодный запрос: полное уточнение
Когда пришло сообщение в слаке «мне нужно соотношение X/Y за Q1»:
Привет! Помогу. Пара уточнений, чтобы правильно подготовить:
1. С какой целью? (чтобы выбрать правильный график и детализацию)
2. Как определяем X и Y? (возможны разные интерпретации)
3. Q1 — календарный год или финансовый?
4. Разбивать по сегментам (страна, продукт, ...)?
5. Формат: одно число, график трендов, дашборд, слайд?
6. Срок: когда нужно?
Если что-то уже понятно — достаточно минимального уточнения.Минус: стейкхолдер чувствует сопротивление.
Плюс: правильный анализ с первого раза.
Нужен баланс. Для мелких задач часть вопросов можно пропустить, для средних и больших всегда уточняем.
Избегайте микро-вопросов
Плохой паттерн — спрашивать по одному вопросу в слаке:
- Понедельник: «Какой период?».
- Вторник: «Какой сегмент?».
- Среда: «Какой формат?».
Стейкхолдер устаёт, учится игнорировать вас.
Лучше: задать все вопросы пачкой. Или 15-минутный созвон — получили ответы, поехали.
Понять невысказанные потребности
Часто стейкхолдер просит одно, а нужно другое.
Красные слова:
- «Интересные инсайты» — размыто, нужна конкретика.
- «Небольшая выгрузка» — часто больше, чем кажется.
- «Простой вопрос» — редко простой.
- «Просто число» — нужен контекст.
Когда слышите такое — копайте глубже. «Что сделает это ценным для вас?» часто раскрывает больше.
Несогласие по скоупу
Стейкхолдер просит X. Вы считаете, что нужен Y.
Вариант 1: просто сделать X. Самый безопасный, отдаёт то, что просили.
Вариант 2: сделать Y. Рискованно — может не закрыть их потребность.
Вариант 3: разговор.
«Я понял запрос. Альтернативно мог бы сделать Y, потому что [причина]. Что предпочитаете?».
Показывает инициативу, уважает их право решать.
Иногда делают оба — быстро X, потом проактивное предложение по Y.
Правильный уровень детализации
Типичная ошибка новичков — переисследовать простые вопросы и недоисследовать сложные.
Глубина анализа — пропорционально бизнес-важности.
Быстрый ad-hoc (< 1 часа):
- Простой SQL.
- Скриншот результата.
- Однопредложенный ответ.
- Минимум документации.
Средний проект (несколько дней):
- Структурный анализ.
- Несколько ракурсов.
- Графики.
- Мемо с рекомендацией.
Стратегический проект (недели):
- Исчерпывающий анализ.
- Несколько источников данных.
- Глубокие разделы.
- Формальные материалы (слайды, мемо).
- Готовность к презентации для руководства.
Не делайте стратегический уровень для быстрого ad-hoc. И наоборот.
Чёткий скоуп на старте экономит недели.
Уточняющие вопросы — базовый навык аналитика. В тренажёре Карьерник есть задачи по продуктовой аналитике, case interviews и реальным рабочим сценариям.
Шаблоны для типовых запросов
Шаблон 1: Разбор метрики.
Спек:
- Метрика: [точное определение, вплоть до SQL]
- Период: [даты от и до]
- Сравнение: [прошлый период, цель, сегмент]
- Разбивки: [все нужные сегменты]
- Формат: [график, таблица, мемо]
- Аудитория: [кто увидит]
- Дедлайн: [дата, время]
- Какое решение принимается: [конкретно]Заполнять вместе со стейкхолдером на 1:1 или в общем документе.
Шаблон 2: Оценка A/B-теста.
Название теста:
- Гипотеза:
- Запущен: [дата]
- Завершён: [дата или «активен»]
- Размер выборок: [контроль, тест]
- Первичная метрика:
- Ожидаемый лифт:
- MDE (минимально детектируемый эффект):
- Guardrail-метрики:
- Интересующие сегменты:
- На какие вопросы отвечаем:Шаблон 3: Исследовательский анализ.
Проблема:
- Что выглядит не так?
- С какого момента?
- Размер:
- Гипотезы:
- Какие данные нужны, чтобы проверить каждую:
- Критерии принятия решения: [какой результат → какое действие]Шаблоны ускоряют старт и обеспечивают полный бриф.
Документируйте ответы
Запросы в слаке → ответы теряются. Фиксируйте где-то:
Вариант 1: общий документ под запрос. Notion, Google Doc.
Вариант 2: таск-трекер. Jira, Linear. Со структурой полей.
Вариант 3: цепочка писем. Старо, но ищется.
Не работайте из тредов слака. Разговоры про требования должны жить в персистентном документе.
Возражать на размытость
Если стейкхолдер настаивает: «просто разберись»:
Мягко возражайте:
«Я могу сделать общий обзор, но без понимания цели это будет неэффективно. 10 минут обсуждения = сэкономленные дни. Готовы потратить 10 минут сейчас?».
Большинство согласятся. С теми, кто всё равно отказался, — делаете то, что кажется лучшим, и явно фиксируете допущения.
Асинхронные запросы
На удалёнке часто запросы асинхронные. Шаблон хорошего async-запроса:
## Контекст
[Зачем нужно, большая картина]
## Запрос
[Конкретно что нужно]
## Детали
- Метрика:
- Период:
- Формат:
- Дедлайн:
## Какое решение это определит
[Что будет решаться]Когда видите размытый месседж в слаке — давайте ссылку на шаблон. «Заполните, пожалуйста, этот шаблон».
Разумные допущения
Иногда до стейкхолдера не дотянуться. Надо двигаться дальше.
Делаете разумные допущения, фиксируете их.
«Для этого анализа я полагаю:
- Месячный период = календарный месяц.
- Активный пользователь = залогинился в течение периода.
- Сегмент new vs returning — по дате регистрации когорты.
Если это не совпадает с вашим намерением, дайте знать — пересчитаю».
Двигаться вперёд лучше, чем стоять.
Обратная связь
После сдачи анализа:
- Ответил ли на их вопрос?
- Будут ли пользоваться повторно?
- Чего не хватило?
- Что лишнее?
Обратная связь оттачивает ваши уточняющие вопросы на будущее.
Через 6 месяцев вы будете знать предпочтения стейкхолдера наизусть.
Типичные ошибки
Допущения «и так понятно». «Они, конечно, хотят последний месяц». Не всегда очевидно.
Пропуск уточнений для «быстрых» запросов. Быстрое становится долгим, если не совпало с ожиданием.
Принимать дедлайны «ASAP». Возражайте. «Какая реальная дата?».
Не записывать запросы. Забываете детали, переспрашиваете.
Один подход ко всем. Одинаковые уточнения для гендира и джун-продакта не работают.
Перегружать простые запросы. Простое должно оставаться простым.
Читайте также
FAQ
Слишком много вопросов — стейкхолдеры устают?
Да, можно переборщить. Батчите вопросы, избегайте микро-запросов, используйте шаблоны.
Что если стейкхолдер сам не знает?
Помогите ему подумать. «Какое решение это поможет принять?» «Если результат X — сделаем Y?».
Когда не уточнять и сразу делать?
Очень простые, чётко очерченные, низкорисковые запросы. «Сколько пользователей было вчера?» — просто отдаём.
Как не выглядеть занудой?
Задавайте вопросы с намерением: «чтобы мой результат совпадал с вашими ожиданиями, уточню...». Это забота, а не занудство.