> ## Content Index > Fetch the complete content index at: https://think-visualize.ru/llms.txt > Use this file to discover other available public pages before exploring further. # Макро-повествование: этап мышления, о котором не говорят - URL: https://think-visualize.ru/principles-of-good-data-product-macro-narrative/ - Published: 2026-03-03T07:15:38.000Z - Updated: 2026-03-26T06:37:31.000Z - Description: Между сбором требований и открытием BI-инструмента существует невидимый этап мышления. Тот, кто его делает перестаёт быть руками и становится партнёром, который масштабирует свой аналитический ум на всю организацию. - Author: Сергей - Tags: Дата-продукты, #series-masterskaya ## Вы когда-нибудь делали идеальную работу, которую никто не использовал? Первые 3 года карьеры такие задачи преследовали меня регулярно. **2018 год.** Учусь на аналитика. В голове романтическая картинка: я Шерлок и серый кардинал. Работаю с кучей данных, интерпретирую их, нахожу инсайты и влияю на бизнес с помощью данных и критического мышления. Я активно учусь SQL и Python, правильно подбирать визуализации, выбирать стат. критерии. **2021 год.** Делаю очередной дашборд после слова заказчика: «Нужно к пятнице.» Я киваю, строю графики, все красиво. Понедельник: «Классно! Но давай переделаем.» Вторник: «А можно еще вот так?» Месяц спустя: никто не открывает дашборд. Я злился на заказчиков и думал: «Они ничего не понимают, не знают, что хотят.» **2022 год.** Осознаю, что проблема не в заказчиках. Проблема в сборе требований, надо лучше понимать, что хотят заказчики, больше их спрашивать. Ситуация становится лучше, но проблемы все еще всплывают. **2024 год.** Осознаю, что просто собрать требования недостаточно. Важно подумать и выстроить эти требования в структуру и связи. И почему-то об этом никто нигде не говорит. ## Разрыв между ожиданиями и реальностью В 2025 я вижу, что проблемы, с которыми я сталкивался в 2021 всё ещё актуальны и регулярно доставляют проблемы аналитикам в работе. Они чаще всего помогают руками воплощать идеи бизнеса, а не являются самостоятельной функцией и отдельным «мозгом», постоянно в завалах и адхоках. Проблема идет с двух сторон. Первая — ожидания при найме. Вторая — обучение и майндсет. Исследование [Parallel](https://platform.parallel.ai/shared/deep-research/fffbb428-61a6-4c05-9f32-d25b0f386109?ref=think-visualize.ru) подтверждает мою гипотезу: фокус на Hard Skills. На практике важнее именно решение бизнес-задач и умение коммуницировать с заказчиком — это неявные ожидания от бизнеса. | Навык | Обучение | Найм (РФ) | Найм (Мир) | Работа | | ---------------------------------- | -------- | --------- | ---------- | ------ | | **Технические (Hard Skills)** | | | | | | SQL и работа с базами данных | 1 | 1 | 1 | 1 | | Excel / Электронные таблицы | 3 | 3 | 4 | 9 | | Python/R для анализа данных | 2 | 4 | 3 | 7 | | Инструменты BI (Tableau, Power BI) | 4 | 2 | 2 | 5 | | **Аналитические** | | | | | | Статистика и A/B-тестирование | 5 | 6 | 5 | 8 | | Очистка и подготовка данных | 6 | 7 | 7 | 6 | | Решение бизнес-задач | 8 | 5 | 6 | 2 | | **Гибкие (Soft Skills)** | | | | | | Коммуникация и Data Storytelling | 7 | 8 | 8 | 3 | | Понимание бизнеса / Домена | 9 | 9 | 9 | 4 | То есть удивительный парадокс: **то, что от вас просят, и то, что реально нужно для успешной работы — совершенно разные навыки.** «Решение бизнес-задач», «коммуникация», «понимание домена» — звучит как общие слова из вакансии. Проблема в том, что эти навыки никто не формализует. Они остаются интуитивным знанием, которое невозможно передать. Эта статья — попытка дать структуру тому, что обычно живет только в голове опытного аналитика. Работая с данными, мы знаем простое правило: garbage in, garbage out. Если на входе плохие данные, на выходе тоже будет мусор. Мы стараемся это контролировать в работе с данными, но регулярно упускаем в работе с задачами, которые приносят заказчики. Постановка от заказчика — это тоже данные, и мы можем начать этим управлять. Подробно о том, как конкретно это делать, я рассказывал в [прошлой статье цикла](https://think-visualize.ru/principles-of-good-data-product-requirements/). Допустим, вы это сделали. У вас на руках — потребности, задачи, бизнес-контекст. Но как конкретно от сырых требований дойти до результата? Причём не просто результата, а инструмента, где объединены два мира. С одной стороны экспертиза бизнеса со стратегическим фокусом. С другой стороны аналитические связи, ведущие от стратегии к тактическим сигналам и причинно-следственным связям, которые будут драйвить решения. ![](https://think-visualize.ru/content/images/2026/03/visual-1-2.png) Давайте разбираться. ## Ключевой навык архитектора: макро-повествование Представьте, что вы делаете исследование и пытаетесь выяснить, почему у компании стало меньше заказов. Вы начинаете размышлять: так, с какого момента они падают, как оно распределено по сервисам, есть ли какие-то просадки, если есть, то из-за каких источников трафика это могло произойти? Может быть у нас были какие-то релизы приложения? Это и есть повествование — путь аналитической мысли. Большинство аналитиков держат этот путь в голове. Он работает для них, но не масштабируется на других. **Макро-повествование** — это способ упаковать этот путь в инструмент. Спроектированный аналитический сценарий, главная цель которого — **«запечь»** критическое мышление, логику и бизнес-контекст в аналитический продукт. Будь то дашборд, рассылка или исследование. Хорошее повествование решает для того, кто будет работать с вашим продуктом, три задачи: - **Определяет важность** — что главное, что второстепенное. - **Выстраивает связи** — как метрики влияют друг на друга. - **Добавляет контекст** — это хорошо или плохо, растем или падаем. Одна хорошо продуманная структура упрощает жизнь каждому пользователю вашего инструмента при каждом взаимодействии с ним. А вам даёт ещё одно преимущество: вы видите всю картину и делаете только то, что действительно нужно. Да, на проектирование уходит время, от 1 до 5 дней. Но вы не делаете работу в стол и экономите время на правках. ## Мастерская аналитика Давайте представим, что вы стали аналитиком, который работает как архитектор. От момента получения задачи до готового макета. Продакт приходит с запросом: «Нужен дашборд, который показывает DAU, MAU и Stickiness, выручка. К пятнице.» Вы не бросаетесь строить. Вы ставите встречу, проводите [сбор требований](https://think-visualize.ru/principles-of-good-data-product-requirements/), и после встречи у вас на руках потребности заказчиков, их задачи и бизнес-контекст — сырьё, из которого предстоит выстроить структуру. Процесс проектирования включает в себя два навыка. Первый — **аналитическая архитектура**: разобрать задачу на части, выстроить иерархию и найти причинно-следственные связи. Дальше — **макро-повествование**: спроектировать, как пользователь пройдёт через эту структуру. Одно без другого не работает: архитектура без повествования — карта, которую очень сложно читать, повествование без архитектуры — красивая обёртка без содержания. Всего **4 этапа**: 1. **Иерархия** — от сырых требований к структуре вопросов. *Инструмент:* текстовый редактор. *Цель:* определить, что главное. *Время:* 2-8 часов. 1. **Последовательность** — от структуры к визуальному макету. *Инструмент:* доска в Miro. *Цель:* спроектировать путь взгляда. *Время:* 1-4 часа. 1. **Группировка** — от макета к логичным блокам. *Инструмент:* продолжаем в Miro. *Цель:* снизить когнитивную нагрузку. *Время:* 30 мин — 1 час. 1. **Контекст** — от блоков к законченному макету. *Инструмент:* финализация в Miro. *Цель:* добавить ответ на «И что?» *Время:* 20-30 минут. Это эмпирическая модель, которую я вывел из своей практики. Она совпадает с тем, как когнитивная наука описывает обработку сложной информации — от общего к частному, от структуры к деталям. **Важно:** этот подход не для каждой задачи. Ad-hoc выгрузка на 3 графика не требует архитектуры. Но если вас засыпают ad-hoc или вы понимаете, что инструмент будут использовать 3+ человека дольше месяца — инвестиция в проектирование окупится. Теперь посмотрим, как это работает на практике. ### Этап 1\. Иерархия Вы уже пообщались с заказчиком, у вас есть материал из общения. Открываете текстовый редактор, смотрите на записи и задаёте себе вопрос: > Какую проблему мы на самом деле решаем? Из собранных требований вы выделяете ключевой страх: > *Мы боимся провалить запуск нового продукта из-за низкой окупаемости.* Из страха рождается центральный вопрос. Он нужен для того, чтобы не закопаться в бесконечное исследование. Это осознанные рамки, которые фокусируют процесс размышления. В текущей задаче это: **«Насколько здорова экономика нашей подписочной модели?»** Теперь декомпозируете это, чтобы попытаться понять как ответить на этот вопрос: - Из чего состоит здоровая экономика? Привлечение + Активация + Привычка + Монетизация - Откуда приходят пользователи? -> CR в триал по каналам - Получают ли они пользу? -> Время до первой пользы, Доля сессий с пользой - Возвращаются ли? -> DAU/MAU, Sticky Factor, Retention - Платят ли? -> Trial-to-Paid CR, Average Revenue На экране появляется **древовидная структура вопросов и метрик**. ![](https://think-visualize.ru/content/images/2026/03/visual-2-2.png) Пирамида вопросов — карта территории, она показывает что можно измерять. Но этого мало, нужно расставить приоритеты и проработать взаимосвязи во всём этом. Нужна карта причин: что на это влияет и как мы можем это измерить и увидеть как можно раньше. Это делает драйверная модель. Вы определяете самую главную метрику – North Star (LTV), находите её прямые драйверы (Trial-to-Paid CR, Retention, Average Revenue), продолжаете разворачивать дерево вниз. Это дерево автоматически позволяет выделить два типа метрик: lead и lag. Lag (LTV, Revenue) — результат, который проявляется через большое количество взаимосвязей и времени. Lead (Time to Value, CR по каналам) — рычаги, на которые у продукта больше влияния и которые проявляются достаточно быстро. Без этого разделения дашборд покажет, что что-то упало, но не подскажет, что делать. ![](https://think-visualize.ru/content/images/2026/03/visual-3-2.png) Вы **ещё не нарисовали ни одного графика**, но уже запекли своё аналитическое мышление в структуру. Связанная карта из \~20 метрик, где каждая находится на своём месте в иерархии важности. > **Инструмент:** Sublime Text, Notion. > > **Время:** 2-3 часа. > > **Артефакт:** Текстовый файл с иерархией метрик и драйверной моделью. ### Этап 2\. Последовательность Карта метрик готова. Теперь начинается макро-повествование — проектирование пути, по которому пользователь пройдёт через эту карту. Просто разложить по экрану этот набор метрик нельзя, нужно спроектировать **путь пользователя**. Вы открываете Miro и начинаете расставлять стикеры с метриками на виртуальном полотне. - Что пользователь должен увидеть **первым**? -> LTV — самая важная метрика идет в самую сильную зону (левый верхний угол) - Что **вторым**? -> Ее прямые драйверы (TTP CVR, Retention, Avg Revenue) — чуть ниже или правее - Как вести взгляд дальше? -> Драйверы драйверов идут еще ниже ![](https://think-visualize.ru/content/images/2026/03/visual-4-2.png) На доске появляется **грубый макет**: схема расположения блоков информации. Вы всё ещё не открывали BI-инструмент. Но уже знаете, **где** будет каждый элемент. > **Инструмент:** Miro, FigJam. > > **Время:** 1-2 часа. > > **Артефакт:** Визуальный макет с расположением метрик. ### Этап 3\. Группировка Допустим у нас получилось 16 метрик. Если будем на дашборд выводить это просто так, то пользователь утонет в количестве информации. Что делать? Вы начинаете **упаковывать** метрики в логические блоки. Метрики «Время до первой пользы» и «Доля сессий с пользой» отвечают на один вопрос: *«Насколько эффективна активация?»* Вы их сближаете, добавляете между ними меньше пространства, чем между другими блоками. Они визуально «склеиваются». И так шаг за шагом 16 элементов превращаются в **4 модуля**: Привлечение, Активация, Привычка, Монетизация. ![](https://think-visualize.ru/content/images/2026/03/visual-5-2.png) Эти четыре модуля — не просто визуальный порядок. Это **навигационная структура** будущего дашборда. Каждый модуль станет отдельной зоной на экране диагностики. 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-инструмент. Но у вас есть: - Четкое понимание проблемы - Полная карта метрик с причинно-следственными связями - Визуальный макет с продуманной навигацией - Спецификация контекста для каждого элемента **Теперь вы показываете макет заказчику.** А дальше — сбор данных, настройка источников, создание графиков и вёрстка по макету. Но об этом в следующих статьях. Всё, что вы только что прошли — обзор процесса, а не пошаговая инструкция. Конкретные техники (пирамида вопросов, построение драйверной модели, шаблоны) — в [Мастерской аналитика-архитектора](https://think-visualize.ru/workshop), которая выйдет следом. [****Мастерская аналитика-архитектора. Практическое руководство**](#) Там вы найдёте: - Техники декомпозиции через "Пирамиду вопросов" - Пошаговый процесс построения драйверной модели с примерами - Работу с JTBD и разрешением конфликтов между заказчиками - Конкретные паттерны проектирования для каждого уровня - Чек-листы и шаблоны для вашей работы А пока — давайте посмотрим, как выглядит результат этой работы. ## Результат в действии Ситуация ниже собрана из кусков реальных ситуаций и немного идеализирована, чтобы показать потенциал подхода и вдохновить вас. Но разница между спроектированным и неспроектированным инструментом — не фантазия. [University of Minho и University of Alicante](https://www.sciencedirect.com/science/article/pii/S0169023X25000059?ref=think-visualize.ru) провели исследование и доказали влияние. > 41 участнику показывали одинаковые данные. Разница была в проектировании. С продуманным повествованием пользователи инструмента давали в 2 раза больше правильных ответов и **в 7 раз меньше** ошибочных интерпретаций. ### Утро понедельника. 9:15 **CEO открывает дашборд.** Вкладка «Обзор» — спроектированная специально для его задачи: *«Быстро понять статус, чтобы отчитаться перед стейкхолдерами»*. Его взгляд падает на левый верхний угол — самую сильную зону экрана. Главная метрика: **LTV (Lifetime Value)**. ![](https://think-visualize.ru/content/images/2026/03/visual-6-2.png) **$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%. ![](https://think-visualize.ru/content/images/2026/03/visual-7-2.png) 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](https://t.me/think%5Fvisualize?ref=think-visualize.ru) — обсудим.