Макро-повествование: этап мышления, о котором не говорят

Вы когда-нибудь делали идеальную работу, которую никто не использовал?

Первые 3 года карьеры такие задачи преследовали меня регулярно.

2018 год. Учусь на аналитика. В голове романтическая картинка: я Шерлок и серый кардинал. Работаю с кучей данных, интерпретирую их, нахожу инсайты и влияю на бизнес с помощью данных и критического мышления. Я активно учусь SQL и Python, правильно подбирать визуализации, выбирать стат. критерии.

2021 год. Делаю очередной дашборд после слова заказчика: «Нужно к пятнице.» Я киваю, строю графики, все красиво.

Понедельник: «Классно! Но давай переделаем.»

Вторник: «А можно еще вот так?»

Месяц спустя: никто не открывает дашборд.

Я злился на заказчиков и думал: «Они ничего не понимают, не знают, что хотят.»

2022 год. Осознаю, что проблема не в заказчиках. Проблема в сборе требований, надо лучше понимать, что хотят заказчики, больше их спрашивать. Ситуация становится лучше, но проблемы все еще всплывают.

2024 год. Осознаю, что просто собрать требования недостаточно. Важно подумать и выстроить эти требования в структуру и связи. И почему-то об этом никто нигде не говорит.

Разрыв между ожиданиями и реальностью

В 2025 я вижу, что проблемы, с которыми я сталкивался в 2021 всё ещё актуальны и регулярно доставляют проблемы аналитикам в работе. Они чаще всего помогают руками воплощать идеи бизнеса, а не являются самостоятельной функцией и отдельным «мозгом», постоянно в завалах и адхоках.

Проблема идет с двух сторон. Первая — ожидания при найме. Вторая — обучение и майндсет.

Исследование Parallel подтверждает мою гипотезу: фокус на Hard Skills. На практике важнее именно решение бизнес-задач и умение коммуницировать с заказчиком — это неявные ожидания от бизнеса.

То есть удивительный парадокс: то, что от вас просят, и то, что реально нужно для успешной работы — совершенно разные навыки.

«Решение бизнес-задач», «коммуникация», «понимание домена» — звучит как общие слова из вакансии. Проблема в том, что эти навыки никто не формализует. Они остаются интуитивным знанием, которое невозможно передать. Эта статья — попытка дать структуру тому, что обычно живет только в голове опытного аналитика.

Работая с данными, мы знаем простое правило: garbage in, garbage out. Если на входе плохие данные, на выходе тоже будет мусор. Мы стараемся это контролировать в работе с данными, но регулярно упускаем в работе с задачами, которые приносят заказчики.

Постановка от заказчика — это тоже данные, и мы можем начать этим управлять. Подробно о том, как конкретно это делать, я рассказывал в прошлой статье цикла.

Допустим, вы это сделали. У вас на руках — потребности, задачи,
бизнес-контекст. Но как конкретно от сырых требований дойти до
результата?

Причём не просто результата, а инструмента, где объединены два мира. С одной стороны экспертиза бизнеса со стратегическим фокусом. С другой стороны аналитические связи, ведущие от стратегии к тактическим сигналам и причинно-следственным связям, которые будут драйвить решения.

Давайте разбираться.

Ключевой навык архитектора: макро-повествование

Представьте, что вы делаете исследование и пытаетесь выяснить, почему у компании стало меньше заказов.

Вы начинаете размышлять: так, с какого момента они падают, как оно распределено по сервисам, есть ли какие-то просадки, если есть, то из-за каких источников трафика это могло произойти? Может быть у нас были какие-то релизы приложения?

Это и есть повествование — путь аналитической мысли. Большинство аналитиков держат этот путь в голове. Он работает для них, но не масштабируется на других.

Макро-повествование — это способ упаковать этот путь в инструмент. Спроектированный аналитический сценарий, главная цель которого — «запечь» критическое мышление, логику и бизнес-контекст в аналитический продукт. Будь то дашборд, рассылка или исследование.

Хорошее повествование решает для того, кто будет работать с вашим продуктом, три задачи:

• Определяет важность — что главное, что второстепенное.
• Выстраивает связи — как метрики влияют друг на друга.
• Добавляет контекст — это хорошо или плохо, растем или падаем.

Одна хорошо продуманная структура упрощает жизнь каждому пользователю вашего инструмента при каждом взаимодействии с ним. А вам даёт ещё одно преимущество: вы видите всю картину и делаете только то, что действительно нужно.

Да, на проектирование уходит время, от 1 до 5 дней. Но вы не делаете работу в стол и экономите время на правках.

Мастерская аналитика

Давайте представим, что вы стали аналитиком, который работает как архитектор. От момента получения задачи до готового макета.

Продакт приходит с запросом: «Нужен дашборд, который показывает DAU, MAU и Stickiness, выручка. К пятнице.»

Вы не бросаетесь строить. Вы ставите встречу, проводите сбор требований, и после встречи у вас на руках потребности заказчиков, их задачи и бизнес-контекст — сырьё, из которого предстоит выстроить структуру.

Процесс проектирования включает в себя два навыка.

Первый — аналитическая архитектура: разобрать задачу на части, выстроить иерархию и найти причинно-следственные связи.

Дальше — макро-повествование: спроектировать, как пользователь пройдёт через эту структуру.

Одно без другого не работает: архитектура без повествования — карта, которую очень сложно читать, повествование без архитектуры — красивая обёртка без содержания.

Всего 4 этапа:

1. Иерархия — от сырых требований к структуре вопросов.

Инструмент: текстовый редактор. Цель: определить, что главное. Время: 2-8 часов.

2. Последовательность — от структуры к визуальному макету.

Инструмент: доска в Miro. Цель: спроектировать путь взгляда. Время: 1-4 часа.

3. Группировка — от макета к логичным блокам.

Инструмент: продолжаем в Miro. Цель: снизить когнитивную нагрузку. Время: 30 мин — 1 час.

4. Контекст — от блоков к законченному макету.

Инструмент: финализация в Miro. Цель: добавить ответ на «И что?» Время: 20-30 минут.

Это эмпирическая модель, которую я вывел из своей практики. Она совпадает с тем, как когнитивная наука описывает обработку сложной информации — от общего к частному, от структуры к деталям.

Важно: этот подход не для каждой задачи. Ad-hoc выгрузка на 3 графика не требует архитектуры. Но если вас засыпают ad-hoc или вы понимаете, что инструмент будут использовать 3+ человека дольше месяца — инвестиция в проектирование окупится.

Теперь посмотрим, как это работает на практике.

Этап 1. Иерархия

Вы уже пообщались с заказчиком, у вас есть материал из общения. Открываете текстовый редактор, смотрите на записи и задаёте себе вопрос:

Какую проблему мы на самом деле решаем?

Из собранных требований вы выделяете ключевой страх:

Мы боимся провалить запуск нового продукта из-за низкой окупаемости.

Из страха рождается центральный вопрос. Он нужен для того, чтобы не закопаться в бесконечное исследование. Это осознанные рамки, которые фокусируют процесс размышления.

В текущей задаче это: «Насколько здорова экономика нашей подписочной модели?»

Теперь декомпозируете это, чтобы попытаться понять как ответить на этот вопрос:

• Из чего состоит здоровая экономика? Привлечение + Активация + Привычка + Монетизация
• Откуда приходят пользователи? -> CR в триал по каналам
• Получают ли они пользу? -> Время до первой пользы, Доля сессий с пользой
• Возвращаются ли? -> DAU/MAU, Sticky Factor, Retention
• Платят ли? -> Trial-to-Paid CR, Average Revenue

На экране появляется древовидная структура вопросов и метрик.

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

Нужна карта причин: что на это влияет и как мы можем это измерить и увидеть как можно раньше. Это делает драйверная модель.

Вы определяете самую главную метрику – North Star (LTV), находите её прямые драйверы (Trial-to-Paid CR, Retention, Average Revenue), продолжаете разворачивать дерево вниз.

Это дерево автоматически позволяет выделить два типа метрик: lead и lag. Lag (LTV, Revenue) — результат, который проявляется через большое количество взаимосвязей и времени.
Lead (Time to Value, CR по каналам) — рычаги, на которые у продукта больше влияния и которые проявляются достаточно быстро.

Без этого разделения дашборд покажет, что что-то упало, но не подскажет, что делать.

Вы ещё не нарисовали ни одного графика, но уже запекли своё аналитическое мышление в структуру. Связанная карта из ~20 метрик, где каждая находится на своём месте в иерархии важности.

Инструмент: Sublime Text, Notion.

Время: 2-3 часа.

Артефакт: Текстовый файл с иерархией метрик и драйверной моделью.

Этап 2. Последовательность

Карта метрик готова. Теперь начинается макро-повествование — проектирование пути, по которому пользователь пройдёт через эту карту.

Просто разложить по экрану этот набор метрик нельзя, нужно спроектировать путь пользователя.

Вы открываете Miro и начинаете расставлять стикеры с метриками на виртуальном полотне.

• Что пользователь должен увидеть первым? -> LTV — самая важная метрика идет в самую сильную зону (левый верхний угол)
• Что вторым? -> Ее прямые драйверы (TTP CVR, Retention, Avg Revenue) — чуть ниже или правее
• Как вести взгляд дальше? -> Драйверы драйверов идут еще ниже

На доске появляется грубый макет: схема расположения блоков информации. Вы всё ещё не открывали BI-инструмент. Но уже знаете, где будет каждый элемент.

Инструмент: Miro, FigJam.

Время: 1-2 часа.

Артефакт: Визуальный макет с расположением метрик.

Этап 3. Группировка

Допустим у нас получилось 16 метрик. Если будем на дашборд выводить это просто так, то пользователь утонет в количестве информации. Что делать?

Вы начинаете упаковывать метрики в логические блоки. Метрики «Время до первой пользы» и «Доля сессий с пользой» отвечают на один вопрос: «Насколько эффективна активация?» Вы их сближаете, добавляете между ними меньше пространства, чем между другими блоками. Они визуально «склеиваются». И так шаг за шагом

16 элементов превращаются в 4 модуля: Привлечение, Активация, Привычка, Монетизация.

Эти четыре модуля — не просто визуальный порядок. Это навигационная структура будущего дашборда.

Каждый модуль станет отдельной зоной на экране диагностики. PM откроет вкладку «Детализация воронки» и увидит ровно эти четыре блока — Привлечение, Активация, Привычка, Монетизация — с метриками, планами и трендами внутри каждого.

А для CEO вы выносите наверх по одной ключевой цифре из драйверной модели — LTV, Trial-to-Paid CR, Retention, Avg Revenue. Так появляется вкладка «Обзор»: три цифры и North Star, без деталей.

Два дашборда для двух разных аудиторий, одна структура.

Инструмент: Продолжает в Miro.

Время: 30 минут — 1 час.

Артефакт: Макет с явными границами между блоками и вкладками.

Этап 4. Контекст

Последний штрих. Вы проходитесь по каждому ключевому KPI и задаёте вопрос: «Если пользователь увидит эту цифру, сможет ли он понять — хорошо это или плохо?»

Пометки на стикерах:

• Возле LTV -> «Сравнение с планом + предыдущий период»
• Возле TTP CR -> «Бенчмарк по индустрии + прошлый квартал»
• Возле Retention -> «Разбивка по когортам + цель»

Инструмент: Продолжает в Miro.

Время: 20-30 минут.

Артефакт: Финальный макет с метаданными о контексте.

Результат проектирования

Прошёл рабочий день. Вы всё ещё не написали ни одного SQL-запроса, не открывали BI-инструмент. Но у вас есть:

• Четкое понимание проблемы
• Полная карта метрик с причинно-следственными связями
• Визуальный макет с продуманной навигацией
• Спецификация контекста для каждого элемента

Теперь вы показываете макет заказчику. А дальше — сбор данных, настройка источников, создание графиков и вёрстка по макету. Но об этом в следующих статьях.

Всё, что вы только что прошли — обзор процесса, а не пошаговая инструкция. Конкретные техники (пирамида вопросов, построение драйверной модели, шаблоны) — в Мастерской аналитика-архитектора, которая выйдет следом.

А пока — давайте посмотрим, как выглядит результат этой работы.

Результат в действии

Ситуация ниже собрана из кусков реальных ситуаций и немного идеализирована, чтобы показать потенциал подхода и вдохновить вас.
Но разница между спроектированным и неспроектированным инструментом — не фантазия. University of Minho и University of Alicante провели исследование и доказали влияние.

41 участнику показывали одинаковые данные. Разница была в проектировании. С продуманным повествованием пользователи инструмента давали в 2 раза больше правильных ответов и в 7 раз меньше ошибочных интерпретаций.

Утро понедельника. 9:15

CEO открывает дашборд.

Вкладка «Обзор» — спроектированная специально для его задачи: «Быстро понять статус, чтобы отчитаться перед стейкхолдерами».

Его взгляд падает на левый верхний угол — самую сильную зону экрана. Главная метрика: LTV (Lifetime Value).

$2,847 — 12% вверх vs прошлый месяц, но 89% от плана.

Он видит это за 3 секунды. Не нужно искать цифру. Не нужно задаваться вопросом «хорошо или плохо?» — контекст уже встроен.

Правее — драйверы LTV:

• Trial-to-Paid CVR: 8.2% (план: 12%)
• 3-Month Retention: 76% (план: 75%)
• Average Revenue: $49 (план: $45)

Еще 5 секунд. Удержание хорошее. Средний чек хороший, есть проблема в конверсии из триала.

Он пишет Product Manager-у:

Смотрю наш даш, а что там с онбордингом происходит?

Потрачено: 30 секунд.

10:40. PM получает письмо

Старый мир: паника. Нужно срочно собирать данные, делать выгрузки, писать аналитику.

Новый мир: он открывает тот же дашборд. Вкладка «Детализация воронки» — спроектированная для его задачи: копнуть глубже и найти причину.

Экран разделен на зоны по драйверной модели. Привлечение — зеленое. Активация — время до первой пользы 4.2 дня вместо плановых 3, доля сессий с пользой 32% вместо 45%. Привычка — Sticky Factor 0.41 вместо 0.5. Монетизация — Trial-to-Paid CVR 8.2%.

PM видит проблему не как изолированную цифру «8.2%», а как результат цепочки. Причинно-следственные связи читаются сами собой.

Он видит снизу декомпозицию этой цепочки по каналам. Facebook Ads: CVR в триал 18% (лучший канал!), но время до первой пользы 8.3 дня, доля сессий с пользой 12%, Trial-to-Paid CVR 2.1%.

Инсайт появляется мгновенно. Facebook дает много регистраций, но эти пользователи совершенно нецелевые. Проблема не в онбординге. Проблема в том, что креатив в Facebook врет.

PM не придумывал этот анализ и не тратил время на раскопки. Структура дашборда провела его по этому пути. Аналитик запек свое критическое мышление так глубоко, что PM просто следовал за логикой системы — и пришел к инсайту.

Время: 5 минут.

11:30. Встреча PM и маркетолога

Они открывают те же данные. Маркетолог видит проблему своими глазами — через общую систему понимания, которую создал аналитик.

Решение: остановить текущую Facebook-кампанию, переделать креатив, перенаправить бюджет на Google Ads (где метрики активации в норме).

Решение принято через 3 часа после того, как CEO открыл дашборд.

Старый мир vs новый мир

Аналитик-исполнитель:

День 1 — CEO спрашивает «почему LTV ниже плана?», аналитик идет собирать данные.

День 3 — «кажется, дело в онбординге». PM: «а разбей по каналам».

День 5 — «проблема в Facebook». PM: «а покажи метрики активации?»

Итого: неделя вопросов, 10+ итераций, потраченные бюджеты, выгорание.

Аналитик-архитектор:

День 1, 9:15 — 11:30: проблема обнаружена -> причина найдена -> решение принято.

Аналитик не участвовал ни в одном из этих разговоров. Но именно его работа объединила всех в одном контексте и позволила быстро и эффективно решить проблему.

Масштабирование аналитического ума

Представьте, что аналитик — это однопоточный процессор. Он может обрабатывать один запрос за раз.

В модели «исполнителя» вы — единственный процессор в компании, способный анализировать данные. Все вопросы идут через вас. Вы — узкое горлышко.

В модели «архитектора» вы создаете многопоточную систему. Ваше мышление теперь работает в нескольких местах одновременно: CEO думает через вашу систему, PM думает через вашу систему, маркетолог думает через вашу систему.

Вы перестали быть узким местом. Это и есть настоящая победа аналитика. Не «я сделал красивый дашборд», а «я научил организацию думать аналитически, даже когда меня нет рядом».

BI-инструменты все больше автоматизируют реализацию. Этап мышления — единственное, что останется за человеком. Инвестируйте в то, что не автоматизируется.

Что дальше

В начале статьи мы говорили о парадоксе: компании ищут мыслителей, а используют их как исполнителей. Всё, что вы прочитали — не про красивые дашборды, а про то, как сломать этот парадокс.

Первая реакция обычно: «Звучит здорово, но у меня задачи горят.» Справедливо. Но посчитайте честно: сколько из ваших задач — это правки к тому, что можно было спроектировать один раз нормально? Подход архитектора — это не дополнительная работа, а перераспределение: вы инвестируете время на старте, чтобы не тратить недели на переделки потом.

Не пытайтесь применить всё сразу. Начните с одного: следующую аналитическую задачу начните не с BI-инструмента, а с блокнота. Потратьте 20 минут и сформулируйте один вопрос:

«Какую проблему я на самом деле решаю?»

Не «какие метрики показать», а что на самом деле тревожит заказчика. Какой страх, какая неопределённость стоит за его запросом. Запишите это. Из страха родится центральный вопрос, и всё остальное — декомпозиция, драйверная модель, путь взгляда — вырастет из него.

Привычка начинать с вопроса, а не с инструмента — это уже половина пути.

Подумайте о задаче, над которой работаете прямо сейчас. Сформулируйте: «Какую главную проблему я решаю?»
Напишите ответ в Telegram — обсудим.