Начинайте презентацию не с дашборда, а с вывода. Одна фраза в начале — «конверсия в оплату упала на пятой неделе из-за нового флоу онбординга, предлагаю откатить экран подтверждения» — экономит стейкхолдерам двадцать минут блужданий по графикам. Дашборд и цифры идут дальше как доказательства, а не как квест, который команда должна разгадать вместе с вами. За четыре года работы с продуктовыми командами я пришёл к простому правилу: если человек после моей презентации не может пересказать вывод одним предложением, значит, презентации не было — был показ графиков.
Ниже — как я готовлю и провожу такие встречи, какой график под какую задачу беру, что проговариваю вслух и где чаще всего спотыкаются джуны (и половина сеньоров тоже).
Почему презентация — это часть работы аналитика, а не «приятное дополнение»?
Потому что решение принимает не ваш SQL-запрос, а человек, который вас слушает. Можно построить идеально корректную когорту, вычистить данные, свести всё в аккуратный дашборд — и получить ноль эффекта, если продакт вышел со встречи с ощущением «ну, посмотрели циферки». Ценность аналитика измеряется не количеством дашбордов, а количеством решений, которые эти дашборды сдвинули.
Есть и карьерная сторона. На ревью и на собеседованиях на middle и senior вас оценивают не только по тому, умеете ли вы написать оконную функцию, но и по тому, доносите ли вы смысл. Я не раз видел, как кандидат с крепким SQL проваливал финальную секцию, потому что на вопрос «расскажи про интересный анализ» сыпал деталями джойнов вместо того, чтобы сказать, что он вообще выяснил и что компания с этим сделала. Тренировать презентацию так же важно, как решать задачи в тренажёре — просто её реже тренируют, потому что она не выглядит как «настоящая работа».
С чего начинать презентацию: вывод, а не данные
Структура, которая у меня почти всегда работает, — это перевёрнутая пирамида, как в новостях. Сверху самое важное, дальше детализация по убыванию.
Порядок такой:
- Вывод. Что произошло и что я предлагаю. Одно-два предложения.
- Контекст. Почему мы вообще на это смотрим, какой был вопрос.
- Доказательство. Тот самый график или метрика, которая подтверждает вывод.
- Детали. Разрезы, оговорки, что осталось за кадром.
- Следующий шаг. Кто и что делает после встречи.
Ключевая ошибка — вести аудиторию хронологически, «как я делал анализ»: сначала выгрузил, потом заметил аномалию, потом полез в другую таблицу, потом ещё в одну. Вам этот путь кажется логичным, потому что вы его прошли. Слушателю он кажется туманом. Его не интересует ваш маршрут, его интересует пункт назначения.
Проверьте себя простым тестом: если начать презентацию с последнего слайда, аудитория поймёт главное? Если да — порядок правильный.
Как построить историю с данными за три минуты?
История с данными — это не «жили-были пользователи». Это связка: был вопрос → вот что данные ответили → вот что из этого следует. Три части, каждая на минуту.
Разберу на живом примере. Допустим, продакт спрашивает: почему просел вечерний трафик в приложении.
- Вопрос (setup). «Нас беспокоит, что вечерний DAU в будни упал примерно на десятую часть за последний месяц. Разбирался, где именно теряем.»
- Находка (conflict). «Падение целиком в сегменте Android на версиях приложения до определённой сборки. iOS и веб стабильны. Совпадает по датам с выкаткой обновления.»
- Вывод (resolution). «Похоже на баг в новой сборке под старые Android. Предлагаю проверить краш-репорты по этим версиям и, если подтвердится, выкатить хотфикс.»
Три предложения — и у команды есть гипотеза и действие. Всё остальное (как я резал когорты, какие джойны делал) — это приложение, которое достаётся, только если спросят.
Чтобы такая история собралась, данные должны быть заранее нарезаны по нужным осям. Я обычно готовлю разрезы SQL-запросом ещё до встречи — по платформе, версии, дате — чтобы на любой вопрос «а в каком сегменте?» ответить за секунды, а не лезть перестраивать дашборд вживую. Если хотите набить руку на таких срезах, это ровно то, что отрабатывается в задачах на агрегации и когорты и на первых модулях SQL-курса.
-- Разрез падения DAU по платформе и версии приложения
SELECT
d.event_date,
u.platform,
u.app_version,
COUNT(DISTINCT u.user_id) AS dau
FROM daily_active u
JOIN dates d ON d.event_date = u.event_date
WHERE d.event_date >= DATE('now', '-30 day')
GROUP BY d.event_date, u.platform, u.app_version
ORDER BY d.event_date;Какой график выбрать под задачу?
Тип графика — это не вопрос вкуса, это вопрос сообщения. Сначала формулируете, что хотите сказать, потом выбираете форму. Вот моя рабочая шпаргалка.
- Динамика во времени («растёт / падает / сезонность») — линейный график. Одна-две линии, не пять. Если линий больше трёх, вы уже потеряли половину зала.
- Сравнение категорий («какой канал больше») — горизонтальный барчарт, отсортированный по значению. Не пончик, не пирог — глаз плохо сравнивает углы.
- Вклад в целое («из чего складывается выручка») — стековый бар или простая таблица с долями. Пирог допустим только на двух-трёх сегментах.
- Связь двух метрик («цена против удержания») — скаттерплот.
- Распределение («сколько длится сессия») — гистограмма, а не среднее. Среднее по времени сессии почти всегда врёт из-за длинного хвоста.
- Одно число, которое важнее всего — просто крупная цифра со стрелкой тренда. Не каждую метрику надо рисовать графиком.
Три правила, которые экономят мне нервы на каждой встрече:
Первое — ось Y на линейных графиках по деньгам и объёмам начинается с нуля. Обрезанная ось раздувает движение на пустом месте, и на первом же дотошном стейкхолдере это всплывёт и подорвёт доверие ко всему остальному.
Второе — сортируйте барчарты по значению, а не по алфавиту. Отсортированный бар читается за секунду.
Третье — подписывайте единицы и период прямо на графике. «Выручка» — плохой заголовок. «Выручка, ₽/нед, последние 12 недель» — хороший. Стейкхолдер не должен угадывать, что за числа перед ним.
Если строите визуализации в Python, минимальные аннотации — половина успеха. Один вызов может выделить главное лучше, чем абзац объяснений:
import matplotlib.pyplot as plt
fig, ax = plt.subplots(figsize=(8, 4))
ax.plot(weeks, conversion, color="#888")
# выделяем неделю, когда всё сломалось
ax.axvline(x=5, color="crimson", linestyle="--")
ax.annotate("новый онбординг",
xy=(5, conversion[5]),
xytext=(5.3, conversion[5] + 0.02),
color="crimson")
ax.set_title("Конверсия в оплату, % по неделям")
ax.set_ylim(0, max(conversion) * 1.15) # ось с нуля
plt.show()Потренировать построение и настройку таких графиков можно прямо в браузере в Python-тренажёре, не поднимая локальное окружение.
Что говорить, пока показываешь дашборд
Молча листать вкладки — худшее, что можно сделать. Ваш голос ведёт внимание, дашборд его только подтверждает. Я держу в голове простую схему для каждого экрана: куда смотреть → что это значит → почему это важно.
Звучит это примерно так: «Смотрите на правый верхний график — это удержание по неделям. Видите, что вторая когорта проседает на третьей неделе? Это те, кто пришёл с новой акции. Значит, акция приводит людей, которые быстро отваливаются, и цена привлечения по ней на самом деле выше, чем кажется».
Обратите внимание: я не читаю числа с экрана вслух. Числа человек и сам видит. Я озвучиваю смысл. «Сорок два процента» — это не сообщение. «Меньше половины возвращаются на второй день, для нашего типа продукта это ниже нормы» — сообщение.
И держите один экран под одну мысль. Если на дашборде десять графиков, я не показываю их разом со словами «ну вот, тут всё». Я веду по одному, проговаривая вывод, и прячу или сворачиваю то, что сейчас не обсуждаем. Внимание — ограниченный ресурс, не транжирьте его на фон.
Какие ошибки убивают презентацию дашборда?
Самые частые я собрал в список — почти каждую делал сам в первый год.
- Начинать с методологии. «Я взял данные из трёх таблиц, соединил по user_id, отфильтровал ботов…» — стейкхолдер уже отключился. Метод достаём, только когда его спрашивают.
- Показывать всё, что построил. Вы потратили день на пятнадцать разрезов и жалко их не показать. Покажите два, которые двигают решение. Остальное — в приложение.
- Жаргон вместо человеческого языка. «p-value», «квантиль», «джойн», «атрибуция» без расшифровки. Люди кивают, но не понимают, а переспросить стесняются.
- Числа без сравнения. «Выручка сто миллионов» — это много или мало? Всегда рядом должна быть база: против прошлого месяца, против плана, против сегмента.
- Отсутствие вывода. Презентация заканчивается словами «вот такие данные». А что делать-то? Каждая встреча должна закрываться действием или решением.
- Защита процесса вместо обсуждения сути. Когда спрашивают про цифру, а вы полчаса объясняете, как её считали. Считали правильно — расскажете потом, если попросят.
Отдельно про честность: если данные шумные или выборка маленькая, скажите это сами, до того как спросят. «Тренд похож на рост, но это две недели и доверия пока мало» звучит намного профессиональнее, чем когда вас на этом ловят.
Как отвечать на неудобные вопросы стейкхолдеров?
Неудобные вопросы — это хорошо. Они значат, что человек включился и думает о ваших данных. Плохо, когда вопросов нет вообще: обычно это значит, что не поняли или не поверили.
Мой алгоритм ответа:
- Если знаю — отвечаю коротко и по делу. Без разворачивания всей истории вычислений.
- Если не знаю — говорю «не знаю, проверю». Это сильная позиция, а не слабая. Придумать цифру на ходу и ошибиться — вот что убивает репутацию аналитика надолго.
- Если вопрос уводит в сторону — фиксирую и возвращаю фокус. «Хороший вопрос, выпишу отдельно, чтобы не сбить нас с текущего решения».
Отдельная категория — когда данные не нравятся и их пытаются оспорить: «не может быть, чтобы конверсия так упала». Здесь не надо спорить и не надо прогибаться. Надо показать, откуда цифра, и предложить перепроверить вместе. «Вот запрос, вот сырые события за эти даты, давайте посмотрим конкретный сегмент, где вам кажется странным». Прозрачность снимает конфликт лучше любых аргументов.
Кстати, именно такие ситуации любят разбирать на интервью — «расскажи, когда твои выводы оспорили и что ты сделал». Разбор типовых поведенческих и кейсовых вопросов есть в подборке для собеседований, и я советую заранее прогнать пару таких сценариев вслух.
Как готовиться к презентации заранее?
Экспромт на встрече — это хорошо отрепетированная подготовка. Мой чек-лист перед тем, как звать людей:
Сформулировать вывод одной фразой и записать её. Если фраза не складывается — анализ ещё не закончен, показывать рано. Затем прикинуть, кто в аудитории и что ему важно: продакту — влияние на метрику и что делать, руководителю — деньги и риски, разработке — где именно баг. Одни и те же данные под разных людей рассказываются по-разному.
Дальше — проговорить презентацию вслух хотя бы раз. Не в голове, именно вслух. Мысленно всё звучит гладко, а вслух вылезают дыры и связки, которые не связываются. Заодно померяете время: если на дашборд с выводом уходит больше пяти-семи минут, режьте.
И последнее — подготовить ответы на два-три очевидных вопроса, которые точно зададут. «А в других сегментах так же?», «А это не сезонность?», «А статзначимо ли?». Держите разрезы наготове. Быстрый ответ на предсказуемый вопрос создаёт впечатление, что вы владеете темой целиком.
Технику построения этих разрезов и метрик стоит довести до автоматизма отдельно от презентации — чтобы на встрече думать о смысле, а не вспоминать синтаксис. Держу под рукой SQL-справочник и Python-справочник, когда собираю выгрузку в спешке перед встречей.
Что отработать перед собеседованием аналитика
Если коротко — три вещи, которые делают из «человека с графиками» аналитика, которого слушают.
Первое: всегда начинайте с вывода, данные держите как доказательство. Второе: выбирайте график под сообщение, а не наоборот, и подписывайте оси и единицы. Третье: заканчивайте встречу действием, а не словами «вот такие данные».
Презентация — навык, который тренируется повторением. Проговаривайте свои прошлые анализы вслух, как будто перед вами команда. Смотрите, где путаетесь, и упрощайте. А техническую базу под этими историями — SQL-разрезы, метрики, чистку данных на Python — держите в форме, решая задачи регулярно.
Если хотите системно прокачать и техническую часть, и разбор кейсов «как рассказать про анализ», в Pro открыт полный доступ ко всем задачам SQL- и Python-тренажёра, кейсам и метрикам, плюс AI-собеседования, где можно вслух отрепетировать презентацию своего анализа и получить обратную связь. Начать можно бесплатно — первые задачи каждого блока открыты без подписки.