(почему мой заказчик мудак?)
Когда-нибудь такой вопрос может всплыть в голове. Делаешь дашборд, всё как попросили в задаче. Она даже по SMART. Сроки — чёткие. Метрики — расписаны.
Но на выходе:
- Не то хотели
- Надо добавить ещё разрезов
- Руководству не понравилось
И думаешь: "Ну как же они все достали...". А может быть проблема не в них?
Ты решаешь не ту задачу. Ищешь источники, строишь графики, но не понимаешь зачем вообще всё это нужно.
Это скользкая дорожка, потому что превращает тебя в интерфейс к БД, а не бизнес-партнёра. Люди-интерфейсы — первые под замену LLM моделями.
—————————————
(что ж делать?)
Собирать требования. На первый взгляд это сложный процесс, но пара задач и будет достаточно часовой встречи, чтобы всё это собрать
и превратить в качественный дата-продукт. Вот этапы:
1. Понять потребность
Это не «нужен график», а боль, страх, проблема бизнеса.
❌ MAU в разрезе по подпискам
✅ Платные пользователи отваливаются и мы не понимаем, что делать
2. Выявить бизнес-требования
Что будет делать заказчик, если цифры упадут?
Какие цели есть у продукта?
Какие решения примут по этим данным?
3. Выслушать (и фильтровать) хотелки заказчика
Они могут быть не связаны с реальной проблемой или закрывать её очень частично.
Ты должен помочь ему понять, что он хочет на самом деле.
4. Сформировать требования к решению
- Какие метрики?
- Какие срезы?
- Как часто обновлять?
- Кому и как раскатывать?
—————————————
(вывод)
Правильное погружение в задачу может решить много проблем: от выгорания и карьерного роста до разворота задач и превращение их в большие и интересные проекты.
—————————————
(пост — небольшое интро)
Полная статья с объяснением по этапам и примерами диалогов:
https://think-visualize.ru/principles-of-good-data-product-requirements
Пишите комментарии, отправляйте коллегам, ставьте сердечки и огонёчки, для меня это важно!
Когда-нибудь такой вопрос может всплыть в голове. Делаешь дашборд, всё как попросили в задаче. Она даже по SMART. Сроки — чёткие. Метрики — расписаны.
Но на выходе:
- Не то хотели
- Надо добавить ещё разрезов
- Руководству не понравилось
И думаешь: "Ну как же они все достали...". А может быть проблема не в них?
Ты решаешь не ту задачу. Ищешь источники, строишь графики, но не понимаешь зачем вообще всё это нужно.
Это скользкая дорожка, потому что превращает тебя в интерфейс к БД, а не бизнес-партнёра. Люди-интерфейсы — первые под замену LLM моделями.
—————————————
(что ж делать?)
Собирать требования. На первый взгляд это сложный процесс, но пара задач и будет достаточно часовой встречи, чтобы всё это собрать
и превратить в качественный дата-продукт. Вот этапы:
1. Понять потребность
Это не «нужен график», а боль, страх, проблема бизнеса.
❌ MAU в разрезе по подпискам
✅ Платные пользователи отваливаются и мы не понимаем, что делать
2. Выявить бизнес-требования
Что будет делать заказчик, если цифры упадут?
Какие цели есть у продукта?
Какие решения примут по этим данным?
3. Выслушать (и фильтровать) хотелки заказчика
Они могут быть не связаны с реальной проблемой или закрывать её очень частично.
Ты должен помочь ему понять, что он хочет на самом деле.
4. Сформировать требования к решению
- Какие метрики?
- Какие срезы?
- Как часто обновлять?
- Кому и как раскатывать?
—————————————
(вывод)
Правильное погружение в задачу может решить много проблем: от выгорания и карьерного роста до разворота задач и превращение их в большие и интересные проекты.
—————————————
(пост — небольшое интро)
Полная статья с объяснением по этапам и примерами диалогов:
https://think-visualize.ru/principles-of-good-data-product-requirements
Пишите комментарии, отправляйте коллегам, ставьте сердечки и огонёчки, для меня это важно!
Teletype
Почему мой заказчик мудак?
Если вы хотя бы раз задавались таким вопросом, потому что проделали работу в стол или в последний момент вам вносят большие правки...
9❤15
Привет, спасибо, что дождались, я скучал!
Июль был очень насыщен на события, поэтому с небольшим перерывом возвращаемся.
—————————————
(рассказываем про суровый open-source BI)
Когда в 2022 мы в Т переезжали в Superset, было страшно и непонятно, а большинство гайдов и статей в интернете освещали инструмент с точки зрения возможностей или ответов на базовые вопросы: как сделать график, как на дашборд расположить.
Но вот как всё это работает в единой системе нигде не объяснялось. А это важно, ведь понимая систему, мы можем делать гораздо больше, потому что можем отходить от прописанных шаблонов. Приходилось осознавать это всё самому в процессе.
Картинка этой системы уже давно сформировалась и теперь делюсь этим с вами.
Точно будет полезно тем, кто присматривается к Superset, или уже работает в нём и до сих пор страдает или совершает ошибки. Если вы работаете с другим инструментом, то полезно для кругозора и понимания возможностей и архитектуры других инструментов.
Статья уже в блоге: https://think-visualize.ru/superset-overview
P.S. Следующим будет продолжение цикла по принципам построения дата-продуктов: макро-визуал и UX, оставайтесь на связи!
Июль был очень насыщен на события, поэтому с небольшим перерывом возвращаемся.
—————————————
(рассказываем про суровый open-source BI)
Когда в 2022 мы в Т переезжали в Superset, было страшно и непонятно, а большинство гайдов и статей в интернете освещали инструмент с точки зрения возможностей или ответов на базовые вопросы: как сделать график, как на дашборд расположить.
Но вот как всё это работает в единой системе нигде не объяснялось. А это важно, ведь понимая систему, мы можем делать гораздо больше, потому что можем отходить от прописанных шаблонов. Приходилось осознавать это всё самому в процессе.
Картинка этой системы уже давно сформировалась и теперь делюсь этим с вами.
Точно будет полезно тем, кто присматривается к Superset, или уже работает в нём и до сих пор страдает или совершает ошибки. Если вы работаете с другим инструментом, то полезно для кругозора и понимания возможностей и архитектуры других инструментов.
Статья уже в блоге: https://think-visualize.ru/superset-overview
P.S. Следующим будет продолжение цикла по принципам построения дата-продуктов: макро-визуал и UX, оставайтесь на связи!
Teletype
Apache Superset: от данных до дашборда
Часто для людей Apache Superset (Суперсет) — open-source альтернатива Tableau (Табло). И когда переходишь из Табло в Суперсет и изучаешь...
6👍11❤6
Ку-ку! 9 месяцев c последнего поста, да уж... У меня было время для того, чтобы родилась статья🫃А, стоп, это я опять перестал ходить в зал😁
Расходились мы на том, что я обещал написать продолжение статьи по созданию дата-продуктов — макро-повествование. Это про то, в каком порядке графики расположить, да ведь?
Когда я начинал писать, то тоже так думал. Но всё это выросло в 2 большие статьи, одну из которых публикую сейчас.
На самом деле хорошее макро делается в 4 этапа: проектируем аналитический сценарий и то, как пользователь идёт по нему.
Было у вас такое, что вы собрали требования, вроде глубоко погрузились. А дальше пытаетесь сделать макет, или делаете сразу дашборд и... непонятно, как собрать что-то полезное и цельное из этого, при этом не перегрузив пользователя.
Сам я пришёл к этому интуитивно в течение нескольких лет боли и страданий. В статье попытался раскрыть и формализовать, как это сделать классно и потратить как можно меньше времени на это.
Что происходит между требованиями и первым графиком, и почему именно здесь решается будет ваш инструмент жить или пылиться и утонете вы в правках и костылях или нет?
Читайте на сайте:
https://think-visualize.ru/principles-of-good-data-product-macro-narrative/
Расходились мы на том, что я обещал написать продолжение статьи по созданию дата-продуктов — макро-повествование. Это про то, в каком порядке графики расположить, да ведь?
Когда я начинал писать, то тоже так думал. Но всё это выросло в 2 большие статьи, одну из которых публикую сейчас.
На самом деле хорошее макро делается в 4 этапа: проектируем аналитический сценарий и то, как пользователь идёт по нему.
Было у вас такое, что вы собрали требования, вроде глубоко погрузились. А дальше пытаетесь сделать макет, или делаете сразу дашборд и... непонятно, как собрать что-то полезное и цельное из этого, при этом не перегрузив пользователя.
Сам я пришёл к этому интуитивно в течение нескольких лет боли и страданий. В статье попытался раскрыть и формализовать, как это сделать классно и потратить как можно меньше времени на это.
Что происходит между требованиями и первым графиком, и почему именно здесь решается будет ваш инструмент жить или пылиться и утонете вы в правках и костылях или нет?
Читайте на сайте:
https://think-visualize.ru/principles-of-good-data-product-macro-narrative/
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤15🔥6❤🔥3
К нам регулярно выходят новые ребята и многие из них не так глубоко погружены в Superset. Главная ошибка при погружении — завязаться на реализацию, а не выполняемую задачу.
«А где в Superset LOD-выражения?»
«Как в Metabase применить CSS дашборда?»
«Как реализовать Actions из Табло?»
—————
На самом деле любой BI-инструмент решает одни и те же 6 задач:
1. Загрузить данные
Подключить БД и дать инструменту доступ к данным. В Tableau — экстракт, в Superset — датасет поверх live-подключения.
2. Сделать кастомные вычисления
Пользовательские метрики, вычисляемые поля, формулы. В Tableau — calculated fields и LOD, в Power BI — DAX, в Superset — SQL-выражения прямо в датасете.
3. Нарисовать график
Выбрать датасет, тип визуализации, накинуть поля на оси. Для 99% дашбордов хватит четырёх типов: линейный график, таблица, KPI, барчарт.
4. Задать стиль графику
Минимизировать визуальный шум по заветам Тафти: убрать ось Y и отступы, добавить подписи данных и маркеры, оставить линию на оси X.
5. Задать стиль дашборду
Единые отступы, шрифты, цвета, контейнеры. Чтобы 10 дашбордов выглядели как один продукт, а не 10 разных поделок.
6. Использовать ввод пользователя
Фильтры, параметры, динамическая группировка. В Superset это Jinja-шаблоны, в Tableau — параметры и экшены. Чтобы дашборд позволял задавать вопросы, а не только показывать ответы.
—————
Попробуйте в следующий раз и увидите, насколько быстрее вы осваиваетесь.
«А где в Superset LOD-выражения?»
«Как в Metabase применить CSS дашборда?»
«Как реализовать Actions из Табло?»
—————
На самом деле любой BI-инструмент решает одни и те же 6 задач:
1. Загрузить данные
Подключить БД и дать инструменту доступ к данным. В Tableau — экстракт, в Superset — датасет поверх live-подключения.
2. Сделать кастомные вычисления
Пользовательские метрики, вычисляемые поля, формулы. В Tableau — calculated fields и LOD, в Power BI — DAX, в Superset — SQL-выражения прямо в датасете.
3. Нарисовать график
Выбрать датасет, тип визуализации, накинуть поля на оси. Для 99% дашбордов хватит четырёх типов: линейный график, таблица, KPI, барчарт.
4. Задать стиль графику
Минимизировать визуальный шум по заветам Тафти: убрать ось Y и отступы, добавить подписи данных и маркеры, оставить линию на оси X.
5. Задать стиль дашборду
Единые отступы, шрифты, цвета, контейнеры. Чтобы 10 дашбордов выглядели как один продукт, а не 10 разных поделок.
6. Использовать ввод пользователя
Фильтры, параметры, динамическая группировка. В Superset это Jinja-шаблоны, в Tableau — параметры и экшены. Чтобы дашборд позволял задавать вопросы, а не только показывать ответы.
—————
Попробуйте в следующий раз и увидите, насколько быстрее вы осваиваетесь.
3👍10❤7🔥5
Чем конкретнее задача от заказчика — тем выше шанс, что вы сделаете работу в стол.
—————
Да это бред! Метрики понятны, срезы указаны, даже цель ясна — отслеживать активность пользователей. Всё по SMART. Бери и делай, что время терять?
Да, только через неделю на демо: «не то хотели», «а где ещё вот это», «руководство просило другое».
Почему так происходит? Потому что заказчик проделал за вас самую важную работу — прошёл путь от боли до решения сам, и отдал вам только последний шаг. Вы получили готовый ответ, не зная вопроса.
—————
Как быстро раскопать, что нужно на самом деле? Спросите:
П: Нужен DAU/MAU по подпискам.
А: Окей. Вы открываете дашборд, Stickiness 30%. Что делаете?
П: Ну... смотрю, не просели ли платные после первых двух недель.
А: Почему именно платные? Почему две недели?
П: В прошлый раз запускали платную подписку — пользователи пробовали и пропадали. Мы на это кучу денег потратили.
А: А почему запускаете снова?
П: Руководство считает, что проблема была не в идее, а в исполнении. Сейчас масштабируем.
А: Тогда DAU/MAU вам не поможет. Давайте покажем жизненный цикл платного клиента и конверсию по этапам — так будет видно, где именно теряем.
—————
Четыре вопроса — и задача превратилась в инструмент, который реально закроет проблему, а не поведёт по неправильному пути.
Не отдавайте аналитическую функцию и продумывание вашей задачи заказчикам, иначе доработки неизбежны. Ваша работа начинается не с «возьму в спринт», а с поиска вопроса, на который заказчик на самом деле ищет ответ.
—————
↓ Как за хотелками заказчика найти настоящую задачу — в статье:
https://think-visualize.ru/principles-of-good-data-product-requirements
—————
Да это бред! Метрики понятны, срезы указаны, даже цель ясна — отслеживать активность пользователей. Всё по SMART. Бери и делай, что время терять?
Да, только через неделю на демо: «не то хотели», «а где ещё вот это», «руководство просило другое».
Почему так происходит? Потому что заказчик проделал за вас самую важную работу — прошёл путь от боли до решения сам, и отдал вам только последний шаг. Вы получили готовый ответ, не зная вопроса.
—————
Как быстро раскопать, что нужно на самом деле? Спросите:
И что дальше?
П: Нужен DAU/MAU по подпискам.
А: Окей. Вы открываете дашборд, Stickiness 30%. Что делаете?
П: Ну... смотрю, не просели ли платные после первых двух недель.
А: Почему именно платные? Почему две недели?
П: В прошлый раз запускали платную подписку — пользователи пробовали и пропадали. Мы на это кучу денег потратили.
А: А почему запускаете снова?
П: Руководство считает, что проблема была не в идее, а в исполнении. Сейчас масштабируем.
А: Тогда DAU/MAU вам не поможет. Давайте покажем жизненный цикл платного клиента и конверсию по этапам — так будет видно, где именно теряем.
—————
Четыре вопроса — и задача превратилась в инструмент, который реально закроет проблему, а не поведёт по неправильному пути.
Не отдавайте аналитическую функцию и продумывание вашей задачи заказчикам, иначе доработки неизбежны. Ваша работа начинается не с «возьму в спринт», а с поиска вопроса, на который заказчик на самом деле ищет ответ.
—————
↓ Как за хотелками заказчика найти настоящую задачу — в статье:
https://think-visualize.ru/principles-of-good-data-product-requirements
2🔥14👍12
Когда мы переезжали из Tableau в Superset, из 130 дашбордов оставили 36. И одной из самых сложных задач было понять, какие отчёты реально нужны, какие нужно доработать, а какие можно выкинуть.
У нас тогда родился чеклист, по которым мы оценивали каждый отчёт. Это всего лишь 5 пунктов, но они достаточно надёжно разделяли важное и не очень. Делюсь теперь с вами.
Проверьте свой (или не свой) самый подозрительный отчёт, делитесь результатами с коллегами, скидывайте в комменты:
https://think-visualize.ru/dashboard-score/
https://think-visualize.ru/dashboard-score/
https://think-visualize.ru/dashboard-score/
Есть ли критерии, которые вы считаете очень важными, но их здесь нет?
У нас тогда родился чеклист, по которым мы оценивали каждый отчёт. Это всего лишь 5 пунктов, но они достаточно надёжно разделяли важное и не очень. Делюсь теперь с вами.
Проверьте свой (или не свой) самый подозрительный отчёт, делитесь результатами с коллегами, скидывайте в комменты:
https://think-visualize.ru/dashboard-score/
https://think-visualize.ru/dashboard-score/
https://think-visualize.ru/dashboard-score/
Есть ли критерии, которые вы считаете очень важными, но их здесь нет?
3❤12🔥7
За годы работы выработал для себя базовый минимум, который делаю почти во всех дашбордах, независимо от их типа.
Он выражает два принципа:
1. По умолчанию должно быть красиво.
2. Минимизируем возможность пользователя сформировать себе кашу.
———————
Временной срез + глубина данных
Даём пользователю возможность регулировать "зум" и смотреть данные по дням, неделям, месяцам, кварталам, годам. Но это не просто группировка — срез регулирует глубину данных.
Смотришь по месяцам — видишь последний год. По дням — последние пару недель. Отдалил — шире картина, приблизил — детальнее, но короче.
Как правило берём до 14 точек.
- «День» → 14 дней.
- «Неделя» → 12 недель.
- «Месяц» → 12 месяцев.
- и т.д.
Данных на графике почти всегда достаточно, нет возможности по умолчанию сгенерировать шум из данных или получить одну точку.
Формат оси X
В связке с первым. Делаем лаконичную и контекстно-ориентированную ось.
Срез «Месяц» — на оси 2025.01, «Квартал» — 2025 Q1. Не 2025-01-01 00:00:00, где 11 из 19 символов не несут пользы.
Фильтр с пустым дефолтом. Параметр — нет
То есть фильтр по датам всегда пустой, но видно по какой гранулярности (временному срезу) показываются данные. Это важная практика для случаев, когда пользователь настраивает фильтры.
Ему не надо запоминать: а что сделать, чтобы вернуться к исходной позиции?
Так работает почти во всех интернет-магазинах, очень понятный и привычный паттерн.
Пользователь ничего не трогал, а картина адекватная. Захотел конкретный период — выбрал, дефолт перебит.
—————
А какие настройки для любого дашборда делаете вы?
Подробнее с примерами реализации в Superset в статье:
https://think-visualize.ru/superset-overview/
Он выражает два принципа:
1. По умолчанию должно быть красиво.
2. Минимизируем возможность пользователя сформировать себе кашу.
———————
Временной срез + глубина данных
Даём пользователю возможность регулировать "зум" и смотреть данные по дням, неделям, месяцам, кварталам, годам. Но это не просто группировка — срез регулирует глубину данных.
Смотришь по месяцам — видишь последний год. По дням — последние пару недель. Отдалил — шире картина, приблизил — детальнее, но короче.
Как правило берём до 14 точек.
- «День» → 14 дней.
- «Неделя» → 12 недель.
- «Месяц» → 12 месяцев.
- и т.д.
Данных на графике почти всегда достаточно, нет возможности по умолчанию сгенерировать шум из данных или получить одну точку.
Формат оси X
В связке с первым. Делаем лаконичную и контекстно-ориентированную ось.
Срез «Месяц» — на оси 2025.01, «Квартал» — 2025 Q1. Не 2025-01-01 00:00:00, где 11 из 19 символов не несут пользы.
Фильтр с пустым дефолтом. Параметр — нет
То есть фильтр по датам всегда пустой, но видно по какой гранулярности (временному срезу) показываются данные. Это важная практика для случаев, когда пользователь настраивает фильтры.
Ему не надо запоминать: а что сделать, чтобы вернуться к исходной позиции?
Так работает почти во всех интернет-магазинах, очень понятный и привычный паттерн.
Пользователь ничего не трогал, а картина адекватная. Захотел конкретный период — выбрал, дефолт перебит.
—————
А какие настройки для любого дашборда делаете вы?
Подробнее с примерами реализации в Superset в статье:
https://think-visualize.ru/superset-overview/
3❤11🔥9👍1
Сегодня про самый важный навык аналитика — управление вниманием. И это не только про то, как где-то поставить график. Это про то, что вообще надо выводить, какую информацию?
Решить, что действительно важно и обосновать это когда заказчик не согласен. Именно это спасает от постоянных доработок и переделок. Для меня это ядро продуктового подхода к дашбордам.
Целостно это описывал в прошлой статье-манифесте и обещал подробнее рассказать в практической части. Она разделилась на две: аналитическая архитектура (что показать) и повествование (как показать).
Сейчас выходит первая. Я попытался формализовать это в алгоритм из 4 шагов, в которых вы раскладываете своё понимание бизнеса и задачи в карту метрик, где каждая обоснована.
С таким пониманием вы начинаете проектировать инструмент и становитесь настоящим партнёром для бизнеса, а не просто исполнителем. Можете аргументированно сказать «нет» и предвосхищаете запросы стейкхолдеров.
Хотелось сделать больше, чем статью, поэтому в конце каждого блока есть интерактивные секции, где вы можете подумать и сформировать дерево для своих задач.
Рекомендую прочитать дважды. В первый раз как статью, чтобы хоть даже 5% осталось в голове, уже будет полезно. А второй раз вернуться, когда будете работать над следующим своим инструментом и поработать в интерактивном режиме.
В общем, читайте, пробуйте, пишите как вам:
https://think-visualize.ru/principles-of-good-data-product-analytical-architecture/
Решить, что действительно важно и обосновать это когда заказчик не согласен. Именно это спасает от постоянных доработок и переделок. Для меня это ядро продуктового подхода к дашбордам.
Целостно это описывал в прошлой статье-манифесте и обещал подробнее рассказать в практической части. Она разделилась на две: аналитическая архитектура (что показать) и повествование (как показать).
Сейчас выходит первая. Я попытался формализовать это в алгоритм из 4 шагов, в которых вы раскладываете своё понимание бизнеса и задачи в карту метрик, где каждая обоснована.
С таким пониманием вы начинаете проектировать инструмент и становитесь настоящим партнёром для бизнеса, а не просто исполнителем. Можете аргументированно сказать «нет» и предвосхищаете запросы стейкхолдеров.
Хотелось сделать больше, чем статью, поэтому в конце каждого блока есть интерактивные секции, где вы можете подумать и сформировать дерево для своих задач.
Рекомендую прочитать дважды. В первый раз как статью, чтобы хоть даже 5% осталось в голове, уже будет полезно. А второй раз вернуться, когда будете работать над следующим своим инструментом и поработать в интерактивном режиме.
В общем, читайте, пробуйте, пишите как вам:
https://think-visualize.ru/principles-of-good-data-product-analytical-architecture/
2❤9🔥7❤🔥2
Все выходные я потратил на личного ассистента, поэтому не успел подготовить пост↗️
Сегодня немного экспериментальная тема. Не про BI, но про дата-продукт.
Я всегда пытался как-то структурировать и систематизировать потоки информации, которые происходят в жизни. Чтобы всё было в одном месте и понятно. Но каждый раз получалось так, что на поддержание системы уходило больше времени, чем она экономила, и я всё забрасывал.
С появлением AI эта тема стала легко реализуема, особенно с появлением OpenClaw и подобных монстров. Поэтому сделал своего.
Почему своего, а не готового?
1. Интересно. На этом уже можно было остановиться😁
2. Много слышал про проблемы безопасности.
3. Я и так плачу за подписку, мне не хочется тратиться на API токены.
——————
Что получилось?
———
Архитектура
1. Obsidian vault — единственный источник правды
Сейчас ~200 markdown-файлов: задачи, проекты, люди, финансы, здоровье. Каждый файл — сущность с YAML-метаданными и связями через wikilinks, которые образуют граф.
2. Мозг: Claude Code из 12 агентов
Работает локально через подписку, а не API-вызовы.
У каждого агента своя задача:
🫀 Health — читает Garmin: сон, пульс, стресс, HRV, готовность к задачам, долгосрочные тренды.
🏋️ Trainer — составляет тренировки, следит за зонами, не даёт перетренироваться
🥗 Nutrition — считает КБЖУ, ведёт дневник, учитывает диету
💰 Finance — бюджет, расходы, план накоплений. Подключен к ZenMoney
📋 Planner — утренний план на день, задачи, календарь. Пинит дашборд дня в ТГ бота.
🔬 Pattern Miner — ищет корреляции между доменами и создаёт гипотезы знания.
🐝 Systematizer — пчёлка-архивариус: проверяет теги, создаёт ссылки, дедуплицирует, раскладывает по папкам, работает в фоне по расписанию или по запросу.
🔗 Knowledge Worker — фоновый агент, каскадирует обновления через wikilinks. Когда задача закрывается — обновляет проект, цель, человека.
🧠 Coach — читает профиль из 5 аспектов (мотивации, блокеры, оптимальные условия, идентичность, слепые зоны), отслеживает прогресс по трекам, подсвечивает паттерны мягко и с фактами.
🔭 Meta — helicopter view по всем доменам на одном экране. Используется для еженедельного обзора.
Данные приходят через MCP-серверы: Garmin Connect, ZenMoney, Google Calendar, плюс ТГ для ввода.
3. Telegram — интерфейс
Допилил официальный коннектор Claude Code-Telegram через channels.
1. После моего сообщения он ставит реакции на сообщение — сигнал о том, что мысль в проработке.
2. Отправляет короткое сообщение-маршрутизатор со статусом о том, что сейчас будет делать. Потом редактирует с полной инфой.
3. Делает закреп с дашбордом дня: задачи, шаги, тренировки, календарь, питание.
Кайф в том, телеграм по-настоящему единая и понятная точка входа для всего, можно отправить фото или документ, и CC всё распарсит и маршрутизирует нужному агенту, и это дополнит единую систему знаний.
———
Треки внимания
Это фокус на цели в данный момент. Например, хочу похудеть. Все агенты адаптируются, а какие-то получают больше власти:
— Planner добавляет в утренний план тренировку, ставит напоминание взвеситься, чекбоксы на белок и воду
— Trainer знает что много стресса, выбирает Z2 кардио вместо интервалов
— Nutrition фокусируется на белке, учитывает медицинские особенности
— Coach знает, что были разные циклы похудения и понимает в какой момент попытки ломались, поддерживает на критичных точках
———
Три слоя мудрости
Система не просто хранит данные — она учится:
1. Сигналы. Каждый факт с меткой времени. Проснулся, потренировался, потратил, поел, перенёс задачу. Сырой поток, 10-30 сигналов в день.
2. Гипотезы. Pattern Miner анализирует сигналы за 90 дней и формулирует гипотезы: "после плохого сна расходы растут", "четверг — самый продуктивный день". Каждая гипотеза имеет confidence score. Система ищет не подтверждения, а опровержения (falsification-first).
3. Профиль. Глубинная модель: мотивации, блокеры, оптимальные условия, слепые зоны. Обновляется по мере накопления evidence. Поможет избегать самообмана или каких-то деструктивных паттернов.
——————
Пробовали ИИ для личных дел? Какие грабли словили? Что классно получилось?
Сегодня немного экспериментальная тема. Не про BI, но про дата-продукт.
Я всегда пытался как-то структурировать и систематизировать потоки информации, которые происходят в жизни. Чтобы всё было в одном месте и понятно. Но каждый раз получалось так, что на поддержание системы уходило больше времени, чем она экономила, и я всё забрасывал.
С появлением AI эта тема стала легко реализуема, особенно с появлением OpenClaw и подобных монстров. Поэтому сделал своего.
Почему своего, а не готового?
1. Интересно. На этом уже можно было остановиться
2. Много слышал про проблемы безопасности.
3. Я и так плачу за подписку, мне не хочется тратиться на API токены.
——————
Что получилось?
———
Архитектура
1. Obsidian vault — единственный источник правды
Сейчас ~200 markdown-файлов: задачи, проекты, люди, финансы, здоровье. Каждый файл — сущность с YAML-метаданными и связями через wikilinks, которые образуют граф.
2. Мозг: Claude Code из 12 агентов
Работает локально через подписку, а не API-вызовы.
У каждого агента своя задача:
🫀 Health — читает Garmin: сон, пульс, стресс, HRV, готовность к задачам, долгосрочные тренды.
🏋️ Trainer — составляет тренировки, следит за зонами, не даёт перетренироваться
🥗 Nutrition — считает КБЖУ, ведёт дневник, учитывает диету
💰 Finance — бюджет, расходы, план накоплений. Подключен к ZenMoney
📋 Planner — утренний план на день, задачи, календарь. Пинит дашборд дня в ТГ бота.
🔬 Pattern Miner — ищет корреляции между доменами и создаёт гипотезы знания.
🐝 Systematizer — пчёлка-архивариус: проверяет теги, создаёт ссылки, дедуплицирует, раскладывает по папкам, работает в фоне по расписанию или по запросу.
🔗 Knowledge Worker — фоновый агент, каскадирует обновления через wikilinks. Когда задача закрывается — обновляет проект, цель, человека.
🧠 Coach — читает профиль из 5 аспектов (мотивации, блокеры, оптимальные условия, идентичность, слепые зоны), отслеживает прогресс по трекам, подсвечивает паттерны мягко и с фактами.
🔭 Meta — helicopter view по всем доменам на одном экране. Используется для еженедельного обзора.
Данные приходят через MCP-серверы: Garmin Connect, ZenMoney, Google Calendar, плюс ТГ для ввода.
3. Telegram — интерфейс
Допилил официальный коннектор Claude Code-Telegram через channels.
1. После моего сообщения он ставит реакции на сообщение — сигнал о том, что мысль в проработке.
2. Отправляет короткое сообщение-маршрутизатор со статусом о том, что сейчас будет делать. Потом редактирует с полной инфой.
3. Делает закреп с дашбордом дня: задачи, шаги, тренировки, календарь, питание.
Кайф в том, телеграм по-настоящему единая и понятная точка входа для всего, можно отправить фото или документ, и CC всё распарсит и маршрутизирует нужному агенту, и это дополнит единую систему знаний.
———
Треки внимания
Это фокус на цели в данный момент. Например, хочу похудеть. Все агенты адаптируются, а какие-то получают больше власти:
— Planner добавляет в утренний план тренировку, ставит напоминание взвеситься, чекбоксы на белок и воду
— Trainer знает что много стресса, выбирает Z2 кардио вместо интервалов
— Nutrition фокусируется на белке, учитывает медицинские особенности
— Coach знает, что были разные циклы похудения и понимает в какой момент попытки ломались, поддерживает на критичных точках
———
Три слоя мудрости
Система не просто хранит данные — она учится:
1. Сигналы. Каждый факт с меткой времени. Проснулся, потренировался, потратил, поел, перенёс задачу. Сырой поток, 10-30 сигналов в день.
2. Гипотезы. Pattern Miner анализирует сигналы за 90 дней и формулирует гипотезы: "после плохого сна расходы растут", "четверг — самый продуктивный день". Каждая гипотеза имеет confidence score. Система ищет не подтверждения, а опровержения (falsification-first).
3. Профиль. Глубинная модель: мотивации, блокеры, оптимальные условия, слепые зоны. Обновляется по мере накопления evidence. Поможет избегать самообмана или каких-то деструктивных паттернов.
——————
Пробовали ИИ для личных дел? Какие грабли словили? Что классно получилось?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤2
Think. Visualize
Сегодня про самый важный навык аналитика — управление вниманием. И это не только про то, как где-то поставить график. Это про то, что вообще надо выводить, какую информацию? Решить, что действительно важно и обосновать это когда заказчик не согласен. Именно…
Пара недель назад вышла статья про Иерархию — первый этап проектирования структуры дашборда. Это ключевой этап, определяющий ценность и глубину дашборда.
Сейчас перечитываю анонс и понимаю, что не раскрыл главного. Мастерская, архитектура, очень абстрактно это всё. Давайте попробую заново.
Статья учит строить дерево метрик. Казалось бы, что тут сложного? И зачем это вообще для дашбордов?
Сначала отвечу на второй вопрос. В контексте дашбордов и дата продуктов дерево супер-практично:
1. Определяет, как и где лучше располагать метрики. Всё становится очень логичным.
2. Показывает слепые зоны в требованиях и предвосхищает запросы.
3. Даёт вам сильное мнение и возможность сказать «нет», когда просят вставить очередной фильтр или странную метрику, которая ну вообще никак не ложится сюда.
А передавать или принимать дела от коллеги с этим артефактом намного быстрее.
Теперь что касается сложностей. Недавно в нашем корпоративном канале выходил пост о North Star Metric. Амплитуда написала 63 страничный гайд только по тому, как выбрать одну ключевую метрику.
Это намекает на то, что процесс сложный, нюансов куча. В своей статье собрал всё это в одном месте: приёмы и тонкости, которые обычно собираются годами по крупицам из разных статей, постов, допущенных ошибок и вот таких манускриптов на 60+ страниц.
И всё это уложено в пошаговый процесс — так, чтобы не приходилось каждый раз вспоминать, что ещё нужно проверить.
Почему дашборд показывает «хорошо», а бизнесу при этом плохо? Как не оказаться в ситуации «три дашборда про одно и то же, и никто не знает, куда смотреть»? Почему одна успешно «оптимизированная» метрика так часто ломает соседнюю — и как предвидеть это заранее, а не задним числом?
Всё это и многое другое в статье:
https://think-visualize.ru/principles-of-good-data-product-analytical-architecture/
Сейчас перечитываю анонс и понимаю, что не раскрыл главного. Мастерская, архитектура, очень абстрактно это всё. Давайте попробую заново.
Статья учит строить дерево метрик. Казалось бы, что тут сложного? И зачем это вообще для дашбордов?
Сначала отвечу на второй вопрос. В контексте дашбордов и дата продуктов дерево супер-практично:
1. Определяет, как и где лучше располагать метрики. Всё становится очень логичным.
2. Показывает слепые зоны в требованиях и предвосхищает запросы.
3. Даёт вам сильное мнение и возможность сказать «нет», когда просят вставить очередной фильтр или странную метрику, которая ну вообще никак не ложится сюда.
А передавать или принимать дела от коллеги с этим артефактом намного быстрее.
Теперь что касается сложностей. Недавно в нашем корпоративном канале выходил пост о North Star Metric. Амплитуда написала 63 страничный гайд только по тому, как выбрать одну ключевую метрику.
Это намекает на то, что процесс сложный, нюансов куча. В своей статье собрал всё это в одном месте: приёмы и тонкости, которые обычно собираются годами по крупицам из разных статей, постов, допущенных ошибок и вот таких манускриптов на 60+ страниц.
И всё это уложено в пошаговый процесс — так, чтобы не приходилось каждый раз вспоминать, что ещё нужно проверить.
Почему дашборд показывает «хорошо», а бизнесу при этом плохо? Как не оказаться в ситуации «три дашборда про одно и то же, и никто не знает, куда смотреть»? Почему одна успешно «оптимизированная» метрика так часто ломает соседнюю — и как предвидеть это заранее, а не задним числом?
Всё это и многое другое в статье:
https://think-visualize.ru/principles-of-good-data-product-analytical-architecture/
🔥13
Приходите завтра, обсудим в ламповом формате макро-повествование — это очень важный этап построения инструмента, будет интересно!
🔥2👍1
Forwarded from JetMetrics
Когда аналитика просят "сделать дашборд", он открывает BI инструмент и начинает раскладывать и графики метрики по виджетам. И зря.
Между сбором требований и первой плиткой есть отдельный этап мышления, который определяет, поймёт ли пользователь дашборд с первого взгляда или будет каждый раз спрашивать "а на что тут смотреть в первую очередь?".
Этот этап Сергей Сидоров (BI Tech Lead в Т-Банке) называет макро-повествованием. Это сценарий, который ведёт пользователя по логике мышления, а не по случайному набору показателей.
Завтра Сергей разберёт этот подход, который состоит из 4 шагов:
1. Иерархия. От сырых требований к центральному вопросу и пирамиде драйверов. Что такое Lead и Lag метрики и почему их нельзя складывать в один блок.
2. Последовательность. Как спроектировать путь взгляда пользователя по дашборду. Куда он смотрит первой, второй, третьей, и как этим управлять.
3. Группировка. Как разбить метрики на блоки, чтобы снизить когнитивную нагрузку. Когда пользователь видит 20 KPI без структуры, он не видит ни одного.
4. Контекст. Как для каждой метрики дать ответ на «и что?»: через сравнение с планом, бенчмарками или прошлыми периодами.
По исследованию, на которое ссылается Сергей: при продуманном макро-повествовании пользователи дают в 2 раза больше правильных ответов и в 7 раз меньше ошибочных интерпретаций.
Конечно же обсудим, как этот подход стыкуется с системой карт и деревьев метрик. Где он начинается, что было до него, и почему дашборд без 2-х предыдущих слоёв всё равно остаётся просто отчётом.
Присоединяйтесь завтра, в среду, 6 мая в 18:00 мск
Записаться на эфир
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥17❤8😱2
Вчера прошёл эфир с Димой Некрасовым с темой «Что между требованиями и первым графиком».
Часто при разработке дашбордов мы прыгаем от сбора требований сразу к графикам. И именно в этот момент рождаются дашборды, которые имеют проблемы с логикой, но не помогают принимать решения. Между требованиями и первым графиком есть отдельный этап мышления — макро-повествование, я уже писал об этом подробно в цикле по разработке дата-продуктов.
В эфире разобрали 4 шага этого этапа:
🎯 Иерархия — кто «герой» дашборда, какой у него центральный вопрос, какой набор метрик его обслуживает и для чего нам нужна аналитическая модель.
🧭 Последовательность — как дерево превращается в путь по экрану через Z- и F-паттерны взгляда: вершина → драйверы → детали.
🧩 Группировка — 16 метрик в куче = когнитивный перегруз. Группировка по узлам дерева превращает их в 4 модуля и навигационную структуру.
📐 Контекст — без сравнения с планом / периодом / бенчмарком цифра не работает. Контекст — последняя миля, без неё пользователь утопает в догадках.
Также поговорили:
— Lead vs Lag метрики и почему держать оба типа
— Тавтология в формулах: ARPU vs средний чек как пример «нет рычага»
— Кейс CEO → PM → Facebook за 5 минут: как хорошие дашборды живут без аналитика
— Почему такие дашборды живут годами
🎥 Запись с таймкодами:
https://youtu.be/pQxZmjdIwHA
Слайды — в комменте/следующим постом.
Посмотрите, буду рад обратной связи и вопросам!
Часто при разработке дашбордов мы прыгаем от сбора требований сразу к графикам. И именно в этот момент рождаются дашборды, которые имеют проблемы с логикой, но не помогают принимать решения. Между требованиями и первым графиком есть отдельный этап мышления — макро-повествование, я уже писал об этом подробно в цикле по разработке дата-продуктов.
В эфире разобрали 4 шага этого этапа:
🎯 Иерархия — кто «герой» дашборда, какой у него центральный вопрос, какой набор метрик его обслуживает и для чего нам нужна аналитическая модель.
🧭 Последовательность — как дерево превращается в путь по экрану через Z- и F-паттерны взгляда: вершина → драйверы → детали.
🧩 Группировка — 16 метрик в куче = когнитивный перегруз. Группировка по узлам дерева превращает их в 4 модуля и навигационную структуру.
📐 Контекст — без сравнения с планом / периодом / бенчмарком цифра не работает. Контекст — последняя миля, без неё пользователь утопает в догадках.
Также поговорили:
— Lead vs Lag метрики и почему держать оба типа
— Тавтология в формулах: ARPU vs средний чек как пример «нет рычага»
— Кейс CEO → PM → Facebook за 5 минут: как хорошие дашборды живут без аналитика
— Почему такие дашборды живут годами
🎥 Запись с таймкодами:
https://youtu.be/pQxZmjdIwHA
Слайды — в комменте/следующим постом.
Посмотрите, буду рад обратной связи и вопросам!
🔥8❤5👍5