PartitionByDataLab

Три строки кода с начала года С начала года я написал руками ровно три строки кода. Проверил историю: три, без округления. При этом кода в моих проектах стало больше, а задачи стали заметно сложнее. Всю разработку сейчас делает агент. Я ставлю задачу, даю контекст, задаю ограничения, расставляю приоритеты, принимаю архитектурные решения и проверяю результат. Иногда ещё объясняю, почему переписать половину проекта ради красивого рефакторинга не входило в задачу. Вокруг агентов сейчас много крайних обещаний. Один человек якобы может собрать космический корабль, а аналитические команды скоро пора распускать. Следом копится понятное раздражение: агент производит код, презентации и лонгриды быстрее, чем люди успевают их вычитывать; ответственность за результат растворяется где-то между промптом и кнопкой «отправить». В прошлом посте я разбирал ии-аналитика, которого хотели поставить поверх трёх баз без каталога, семантики и договорённостей о метриках. Саша Бараков писал про усталость от ИИ-контента фиксирует другую проблему. Гладкие буквы подешевели, а ресурса на их проверку больше не стало. На своём рабочем контуре эффект я вижу ясно. По числу задач, которые я довожу до готового результата, моя пропускная способность выросла примерно на 50-60%. Это личная оценка по завершённым задачам. Для корпоративного кост сейвинг fte данных пока мало, для собственного fte метрика видна каждую неделю. Сейчас у меня открыты два терминала. В одном агент разбирает SQL и тесты миграции витрины, во втором собирает сервис или очередную версию дашборда. Пока выполняются проверки, я переключаюсь между проектами, уточняю архитектуру, читаю diff и ставлю следующий шаг. Раньше такой набор задач шёл бы последовательно. Диапазон тоже изменился. В одном проекте теперь пересекаются задачи BI-разработчика, дата-инженера, DevOps, фронтендера и бэкендера. Агент пишет SQL, Python, конфиги, тесты, JS, html и скрипты деплоя. На мне остаются бизнес-логика, устройство системы, архитектура, приоритеты и приёмка. Главный прирост даёт параллельность и возможность переходить границы привычной роли. Такой режим заработал после настройки каскада. В проекте есть стабильный контракт, отдельные скиллы под повторяемые процессы и память о решениях. Мне не нужно заново пересказывать агенту стек, правила PR, устройство DWH и критерии готовности. Каскад снижает количество ошибок. Понимание архитектуры остаётся на операторе. Если он смутно представляет результат, агент быстро масштабирует эту смуту в десятки файлов. В рабочем дуэте агент служит быстрыми руками, а оператор выбирает маршрут, держит контекст и отвечает за приёмку. Самое узкое место для ии разработки сейчас это - разработка дашбордов. SQL, пайплайны, сервисы и проверки имеют чёткие контракты. Вёрстка требует множества итераций: информационная иерархия, плотность, поведение фильтров, пустые состояния, адаптация к реальным данным, визуальный баланс. Для читаемости пока нет теста, который снимет все вопросы. Сейчас в работе проект по пакету скиллов "вайбкодинга дешей": правила компоновки, библиотеку паттернов, примеры хороших решений и процедуру визуальной приёмки. Задача сложная и амбициозная. Агенту мало выдать стайлгайд. Нужно научить его замечать контекст экрана и исправлять результат по обратной связи. Сдвиг карточки на восемь пикселей эту задачу не закрывает. Личный эффект уже виден: с настроенным каскадом я несу примерно в полтора раза больше задач и беру гораздо более широкий контур. Мой рабочий процесс изменился необратимо. Я почти перестал быть основным исполнителем кода и стал оператором разработки. Теперь потолок задают качество декомпозиции, контекста и ревью. Три строки с начала года - самый наглядный симптом.

ИИ-аналитик на 350 ГБ и честном слове Давеча разговаривал с CTO одной компании. Оборот - около 5 млрд рублей в год, данных - примерно 350 ГБ, источников три: Redis, BigQuery и MS SQL. Масштаб вполне осязаемый, не пет-проект на ноутбуке. CTO продвигает внутри простую идею: BI и аналитика в привычном виде компании больше не нужны. Он сам навайбкодит ИИ-аналитика, который подключится к данным и будет отвечать на любые вопросы бизнеса. Заодно компания сэкономит миллионы долларов на аналитиках и привычной BI-инфраструктуре. 🤦 Последняя часть, судя по всему, особенно хорошо продаётся CEO. Есть только несколько деталей. В компании нет: ▫️ документации к дашбордам ▫️ доменной базы знаний ▫️ каталога данных и lineage ▫️ семантического или core-слоя ▫️ даже страницы в Confluence, где зафиксированы определения метрик, владельцы данных и правила работы с ними То есть агенту скорее всего дадут какой-то контекст и предложат самостоятельно понять, из какой таблицы брать revenue, какую дату считать датой продажи, как учитывать возвраты, НДС, отмены и задвоения, а затем уверенно отдать цифру бизнесу. Желательно сразу правильную. Написать SQL по схеме таблиц модель действительно может. Проблема начинается там, где заканчивается схема и начинается смысл. Если два менеджера по-разному понимают revenue или install, а договорённость нигде не записана, агенту нечего «понять». Он выберет одну из правд, аккуратно посчитает её и очень убедительно объяснит результат. Я сейчас участвую в разработке похожего инструмента в бигтехе. У нас уже есть существенная часть перечисленного фундамента, а недостающие элементы строятся: документация, каталог, lineage, доменные знания, владельцы, правила доступа, проверенные расчёты. И даже в такой среде по ощущениям мы пока не приблизились к заветному чату, который надёжно отвечает на любой вопрос про данные. Рабочий ИИ-аналитик требует не только хорошей модели. Ему нужен контекст, которому можно доверять, способ выбрать авторитетный источник, семантика метрик, контроль доступа, набор проверочных вопросов и механизм, который покажет ошибку до того, как цифра попадёт на стол руководителю. Без этого получается быстрый генератор правдоподобного SQL. По моим прикидкам сложность такого проекта слабо связана с объёмом данных. 350 ГБ могут быть сложнее 35 ТБ, если в этих гигабайтах никто не договорился о терминах. После условного порога в две базы, два дашборда и двух аналитиков появляются разные источники истины, локальные трактовки и исторические исключения. «Два аналитика» я, конечно, занизил, но направление мысли именно такое. Компания в сто раз крупнее получит больше таблиц, пользователей и политик доступа. Однако класс задачи уже тот же: сначала нужно превратить знания людей и случайные договорённости в машиночитаемый контекст. Размер усложняет работу, но не создаёт саму проблему. Навайбкодить демонстрацию при этом вполне реально. Агент ответит на десять подготовленных вопросов, построит симпатичный график и эффектно найдёт нужную таблицу. Настоящая проверка начнётся на одиннадцатом вопросе: почему его revenue или install не сходится с цифрой финансов или продукта, кто утвердил формулу и какой результат считать верным. Возможно, здесь и прячется ответ, почему инициативу про отказ от BI двигает именно CTO 😂 Технически собрать интерфейс к LLM несложно. Основная работа лежит в скучной области договорённостей, ответственности и качества данных, которую особенно приятно объявить лишними расходами. Такие проекты редко проваливаются на красивом демо. Они начинают буксовать позже, когда за ответы приходится отвечать. В итоге один участник продлевает себе время громкой инициативой, а компания утилизирует ресурсы и задним числом строит тот самый аналитический фундамент, на котором собиралась сэкономить.

Как я переехал с Claude Code на Codex без потери скорости На этой неделе у меня случился честный стресс-тест агентской архитектуры. Заблокировали аккаунт Anthropic, вместе с ним отвалился привычный Claude Code. Утро, рабочие задачи, миграция DWH, витрины, дашборды, документация, треды. Хороший момент, чтобы пересмотреть жизненные решения. Я открыл Codex и продолжил работать. Другой агент не знает мой стек, структуру репозитория, рабочие запреты, маршруты к DWH, правила PR и почему в расчетах нельзя верить памяти без проверки источника. Всё это ему нужно дать через файлы проекта. У меня это давно собрано в каскад. ▫️ AGENTS.md Главный контракт проекта. Кто я, как со мной работать, где лежат скиллы, что можно делать автономно, что требует подтверждения. Раньше в моём гайде эта роль была завязана на CLAUDE.md, потому что я писал его под Claude Code. После переезда я вынес рамку в AGENTS.md: агент может быть другим, но входной контракт проекта остаётся тем же. ▫️ SKILL.md Повторяемые процессы: PR в DWH, сверка витрин через QueryPad, документация в Confluence, Core Layer, миграция на Trino, Redash/ECharts-виджеты. Когда я прошу подготовить PR, агент не «вспоминает по памяти» из истории чата. Он читает скилл: узкий scope, diff против master, порядок dwh test, что нельзя трогать бонусом и как разбирать фейлы. ▫️ MEMORY.md Индекс того, что важно между сессиями: статусы проектов, решения, обратная связь, ссылки на источники. Память не заменяет проверку. Она показывает, куда смотреть. Из-за этого переезд получился скучным, а это лучший комплимент инфраструктуре. Я не переносил «личность агента». Я дал Codex ту же карту проекта. Пришлось поправить несколько вещей: ▪️ сделать AGENTS.md мостом к старой Claude-структуре; ▪️ потратить 30 минут, чтобы Codex прочитал проект, memory-индексы и рабочие skill-и; ▪️ проверить, что маршруты к DWH, Redash, Confluence и Stash описаны в правильных слоях. После этого Codex снова делает рабочие вещи: разбирает SQL в DWH-репозитории, готовит PR без лишних файлов, сверяет Vertica и Trino через QueryPad, правит документацию в Confluence, читает контекст Core Layer и миграции, собирает ECharts-виджет по стайлгайду. Обычный рабочий контур, только раннер поменялся. Ради этого я и затевал каскад. Если контекст живёт в голове автора или в истории чата, смена агента превращается в миграцию платформы. Снова объясняешь стиль, ограничения, технические маршруты, правила безопасности. На третьем повторе уже работаешь секретарём у собственного инструмента. Если контекст живёт в файлах проекта, агент становится заменяемым раннером. Один отвалился - подставляете другой. Часть команд и MCP-интеграций придётся адаптировать, но ядро остаётся на месте: правила, навыки, память, структура. Важно не переобещать. Каскад не делает агента безошибочным. Он будет путаться, галлюцинировать, цеплять не тот файл и криво трактовать правило. Разница в том, что ошибки становятся реже и чинятся понятнее: смотришь, какой слой контекста не сработал, и правишь конкретный файл. Для меня эта блокировка закрыла старый долг: отвязать «Каскадизация решает» от конкретного инструмента. Теперь это гайд про проектного AI-агента. Codex, Claude Code, Cursor Agent, Cline, корпоративная оболочка - вторично, если инструмент читает проект, работает с файлами и запускает команды. Главные вопросы остаются теми же: ▫️ где лежит стабильный контракт; ▫️ как агент понимает, какой скилл нужен; ▫️ что уходит в память, а что проверяется в источнике; ▫️ какие действия нельзя делать без подтверждения; ▫️ как не сжечь контекст и бюджет на простыне из всего подряд. Я обновил PDF-гайд под эту рамку и залил новую версию в @pbdl_tg_bot. 10 самым активным промо PBDL20 на скидку 20%. Старые формулировки про Claude Code убрал, основной контракт теперь AGENTS.md / SKILL.md / MEMORY.md. 🚀 Если вы уже работаете с AI-агентом в коде, DWH или аналитических проектах, смотрите не только на модель. Смотрите на то, сколько вашего рабочего контекста переживёт внезапную смену инструмента. Мой пережил. За это каскад и ценю.

Проектирование 3 из 3 - дэш core-слоя данных В первом посте серии я разбирал дэш миграции хранилища - там было два контура. Во втором - дэш здоровья метрик, тоже два контура, но уже внутри одной технической семьи. Сегодня третий и последний кейс. Здесь контуров уже три - и это тот случай, когда шаблон «Проектирование взаимодействия» из роскоши превращается в условие выживания. Контекст. В большом продукте делается core-слой данных - набор сертифицированных витрин, на которые должна перейти аналитика всей компании. Цель проста на словах и больна на практике: чтобы аналитики перестали ходить в сырой слой, а ходили в core. Чтобы доверяли. Чтобы пользовались. Дэш у этого продукта один. А смотрят его три разные группы людей - и хотят они принципиально разного. 1️⃣ Команда core-слоя - я и инженеры, которые этот core строят. Цель - видеть adoption: какая доля запросов уже идёт в core, какие домены сертифицированы, где доверие растёт, где валится. Решение - куда вкладывать инженерные руки на следующий спринт. Выходит с приоритетом на ближайшие 2 недели. 2️⃣ BI-партнёры доменов - аналитики и лиды кластеров, которые потребляют данные. Цель - найти свой домен и понять статус: что уже в core, что ещё в сыром слое, на что переключаться сегодня, а на что ждать. Решение - переписывать ли свои дэши и витрины под core прямо сейчас. Выходит со списком собственных миграций. 3️⃣ Менеджмент и data leadership - CDO-уровень и продуктовые руководители. Цель - убедиться, что продукт «core-слой» окупается: сколько денег экономит, сколько ресурсов сэкономили компании, как растёт доверие. Решение - расширять ли инвестиции, давать ли ещё команду, переводить ли в стратегию. Выходит с цифрой для квартального обзора. Три контура - три разных вопроса к одним и тем же данным. Aдopt-метрика для меня - оперативный сигнал «где буксует». Для BI-партнёра - индикатор «можно ли уже верить этому домену». Для менеджмента - доказательство, что продукт жив. Соблазн собрать всё на одном экране с фильтрами огромный. Не работает по той же причине, что в первых двух кейсах: разные вопросы требуют разной композиции. Менеджменту не нужен drill до конкретной витрины. Аналитику не нужны сводные индексы по компании. Команде core не нужен квартальный нарратив. В Workbook ушло три сценария, переключение по ролевой кнопке. Шаблон 5+2 заполнялся отдельно для каждой роли: ▫️ Цель - зачем пришёл ▫️ Ожидаемое поведение - что делает руками ▫️ Ключевое решение - что решает на этом экране ▫️ Каких сценариев быть не должно - что дашборд намеренно НЕ показывает ▫️ Результат - с чем выходит И два пункта про условия: ▫️ Сигналы доверия - почему верит цифрам ▫️ Контекст использования - когда заходит, как часто На двух контурах шаблон ещё можно держать в голове. На трёх - уже нет. Слишком легко перетянуть вопрос менеджмента в зону BI-партнёра и получить экран, на котором не отвечается ни один из трёх. Главное наблюдение серии Метод одинаковый - дэшы разные. Миграция, healthscore, core-слой - это три проектных контекста с разной аудиторией, но проектируются они одинаково: сначала роли с персонами и BI-уровнем, потом 5+2 на каждую роль, потом композиция экранов. Без этого шага получается «дэш-фотография» - много цифр, ноль решений. С этим шагом получается инструмент, после которого человек встаёт со списком «что делать» или с подтверждением «всё ок, можно дальше». Других результатов у дэша быть не должно. Шаблон не магия, а чек-лист. Просто заставляет проговорить вслух то, на что обычно машут рукой - «и так понятно». 🚀 На этом серия закрыта. Позже опубликую шаблон для проектирования взаимодействия 5+2.

Илон Маск покупает Cursor — сделку могут закрыть уже в этом году за $60 млрд. Соглашение между SpaceX и Cursor будет заключено в формате слияния акций — это будет одна из крупнейших сделок на рынке ИИ.

Три рамки управления данными на практике В книжках про data governance любят перечислять «лучшие практики» и фреймворки. На каждом митапе кто-нибудь покажет схему DAMA DMBOK, скажет «надо делать как тут», а через полгода забудет. Хочу разобрать три рамки, которые на моей памяти реально открывали в проектах, и где каждая ломается, если делать в лоб. DAMA DMBOK Самая известная. 11 областей знаний - от data architecture и modeling до governance, quality, MDM и метаданных. Это даже не методология, а словарь и оглавление дисциплины. Где помогает: когда в большой компании команды говорят на разных языках. Один зовёт «качество», другой - «доверие», третий - «достоверность», и спорят полгода. DMBOK даёт общий канон: вот governance, вот quality, вот lineage, договоримся об именах и пойдём дальше. На текущем проекте core-слоя именно это и спасает - на старте удалось не спорить два спринта про термины. Где ломается: 11 областей одновременно не внедряет никто. Пытаться - значит уйти на три года в ритуалы, метаописания и комитеты. На любой презентации рамки видишь блестящие глаза стейкхолдеров: «давайте всё внедрим». Через квартал команда в выгорании, а в проде ничего не поменялось. DMBOK - чек-лист, не план работ. Henderson-Venkatraman SAM Strategic Alignment Model, четыре квадранта: бизнес-стратегия, бизнес-операции, IT-стратегия, IT-инфраструктура - и связи между ними. Идея проста: тех-инициатива работает, когда поддерживает бизнес-направление, а не висит в вакууме. Где помогает: на больших трансформациях. Когда защищаешь миграцию хранилища или строительство core-слоя - SAM удобен, чтобы показать менеджменту: вот бизнес-цель, вот операционный слой, вот IT-стратегия, вот, наконец, инструменты. В посте 04.05 я разбирал как считать денежную ценность core-слоя - SAM это та рамка, в которой такие разговоры с CDO становятся системными, а не «нам это надо потому что круто». Где ломается: рамка 1993 года. На практике она не даёт ответов «что делать в понедельник» - только проясняет, на каком уровне ты сейчас разговариваешь. После SAM-сессии всегда нужен второй слой методов - иначе остаются красивые слайды и нулевая операционка. Amsterdam Information Model (AIM) Голландская академическая модель. Делит управление информацией на уровни «зачем - что - как» и «стратегия - тактика - операции». Архитектор получает ментальную карту, в которой видно, чем стратегический слой отличается от тактического и какие артефакты живут на каждом. Где помогает: лично мне - для проектирования. AIM позволяет сказать: «эта плитка adoption - тактический срез, эта стратегическая цель окупаемости - другой уровень, не мешать». Это не про коммуникацию с командой, это про мою собственную голову. Где ломается: в РФ и СНГ AIM почти неизвестна. На неё нельзя сослаться в рабочем чате - никто не считает её каноном. Если попробуешь использовать как общий язык команды - получишь недоумение. Это инструмент архитектора, а не словарь компании. Главное наблюдение Все три рамки - не методы. Метод рождается каждый раз заново под задачу. Рамки дают три разные роли: DMBOK как канонический словарь, SAM как язык разговора с менеджментом, AIM как личная карта архитектора. Соблазн «выбрать одну правильную и использовать всегда» обречён. У DMBOK - 11 областей, в которых не за всё надо браться. У SAM - четыре квадранта, в которых не на всех этажах ты живёшь. У AIM - чужая школа мышления, которую не получится навязать команде. Берёшь под задачу, не наоборот.

Проектирование 2 из 3 - дэш здоровья метрик В прошлом посте серии я разобрал первый кейс - дэш миграции хранилища - и рассказал про «Проектирование взаимодействия». Главный тезис там был: один дэш ≠ две аудитории, разделять контуры менеджмента и кураторов доменов. Сегодня - второй кейс. Здесь та же логика, но контур уже не «менеджмент vs кураторы», а две роли поглубже внутри одной технической семьи. И там разница между ними ещё тоньше, поэтому шаблон работает как фильтр. Контекст. В большом продукте есть пара тысяч продуктовых метрик. Например 10 000+. У каждой метрики - оунер (аналитик, который её ведёт) и куратор - лид кластера, отвечающий за весь домен метрик. У каждой метрики есть «здоровье» - 5 факторов, которые показывают, можно ей доверять или пора чинить. Дэш здоровья метрик строится один. А аудитории у него две. И на первый взгляд они хотят почти одного и того же - «сделать метрики здоровее». Но это иллюзия. Куратор домена - Lead кластера, BI ★★★★★, sql-high. Заходит регулярно, в проверяющем режиме. Цель - удерживать долю зелёных метрик в своём домене. Решение, которое принимает - какую задачу заводить на оунеров, кому что приоритизировать. Выходит со списком задач в трекер и коммуникацией с оунерами «нездоровых» метрик. Оунер метрики - Аналитик, BI ★★★★★, sql-medium+. Заходит реактивно - когда пришёл алёрт по его метрике или когда куратор дал задачу. Цель - понять, насколько одна конкретная метрика плоха и что именно фиксить в первую очередь. Решение - сколько времени займёт починка и что делать руками. Выходит с конкретным action item на свою метрику. Один и тот же набор из 5 факторов здоровья читается по-разному: ▫️ Куратор видит распределение - сколько процентов метрик в красной зоне, как это выглядит в разрезе вертикали и кластера, сравнение с компанией в среднем ▫️ Оунер видит карточку - его метрика, её 5 факторов, конкретный action «допиши описание», «почини зависимость» Дэш по-прежнему один. Но в нём два сценария использования - агрегатный для куратора и карточный для оунера. Это сильно отличается от «один экран с фильтрами для всех» - тут даже наборы плиток на странице разные, потому что разный объект внимания. Шаблон 5+2 в применении Куратор домена - заходит ежемесячно/еженедельно, кросс-фильтрует по вертикали и кластеру, видит распределение метрик по зонам и сравнение с компанией, выходит со списком задач для оунеров; отдельные карточки метрик не нужны - это уровень оунера. Доверяет цифрам, потому что бейдж сертификации, документированная логика 5 факторов и автоматизированные рассылки совпадают с тем, что он видит на экране. Оунер метрики - заходит реактивно на алёрт, открывает карточку своей метрики, видит 5 факторов и конкретные action items, выходит с минимальным списком «что починить»; общая статистика по домену ему не нужна, она его только запутает. Доверяет, потому что 5 факторов - те же, что в трекере задач, и «почему красная» совпадает с тем, что говорит куратор. Защита от ошибок здесь - отдельная тема. Две главные ловушки: судить о здоровье домена по одному агрегату (одна красная метрика ≠ красный домен) и формулировать action item на уровне домена, а не конкретной метрики. Шаблон ловит обе через раздел «Каких сценариев быть не должно» - когда вы явно прописываете, чего экран НЕ показывает, эти ловушки уходят. 🚀 В третьем посте серии - дэш core-слоя данных, где контуров уже не два, а три, и шаблон становится не роскошью, а условием выживания.

Проектирование 1 из 3 - дэш миграции хранилища Начинаю серию из трёх постов про проектирование дашбордов - не про инструменты, а про метод. На трёх живых кейсах покажу шаблон «Проектирование взаимодействия», который применяю на каждом новом дэше с широкой аудиторией. Первый кейс - дэш миграции хранилища. Большой продукт меняет движок витрин, есть план переезда объектов с одной бд на другую, и есть менеджмент плюс кураторы доменов, которым нужно держать руку на пульсе. Главный соблазн - сделать «один большой дэш для всех». Плитки KPI сверху, графики посредине, таблица снизу. Не работает. Менеджер спрашивает «идём ли мы по плану и где заносит». Куратор - «где мои объекты, и почему я тут хуже соседей». Два разных вопроса. Один дэш не отвечает чётко ни на один. Один дэш = один контур потребителей. Контуров два - либо два дэша, либо два сценария в одном Workbook. Смешивать нельзя. Какие вопросы должны закрываться: 1️⃣ Какой сейчас статус готовности? 2️⃣ Какой темп миграции? 3️⃣ Какие домены отстают, какие опережают? 4️⃣ Не видно ли странных ускорений или провалов в объектах? 5️⃣ Если есть отклонения - какие и в чьей зоне ответственности? Пятый - ключевой. Он превращает дэш из «красивого монитора» в инструмент решения. Action items не висят в воздухе, а привязаны к фамилии и задаче. Шаблон «Проектирование взаимодействия» Сейчас 5 пунктов про дэш и 2 про условия, в которых он живёт. К этой форме я пришёл не сразу. Первая версия была декомпозированнее - 8 разделов: цель, решение, ожидаемое поведение, поддержка мышления, защита от ошибок, результат, сигналы доверия, контекст. На практике на каждом новом дэше «поддержка мышления» и «защита от ошибок» дублировали «ожидаемое поведение». После трёх кейсов подсушилось. 5 пунктов про сам дэш: ▫️ Цель - зачем сюда пришёл ▫️ Ожидаемое поведение - что делает руками: фильтры, сортировки, клики, drill-down ▫️ Ключевое решение - что решает на основе экрана ▫️ Каких сценариев быть не должно - что дашборд намеренно НЕ показывает ▫️ Результат - с чем выходит (action items или «ничего делать не надо») 2 пункта про условия: ▫️ Сигналы доверия - почему верит цифрам ▫️ Контекст использования - когда заходит, как часто, регулярно или одноразово Над каждой ролью - персона-карточка с должностью, опытом, техническими навыками и BI-уровнем (★1–5). Это не для красоты: человек с BI ★★★★★ и sql-high живёт в дэше иначе, чем с ★★ и Excel. Применение к миграции Два контура - менеджер и куратор домена. Менеджер - раз в неделю на синке смотрит общий темп и процент готовности, решает эскалировать или перебалансировать ресурсы, выходит с коротким списком доменов на разговор; отдельные объекты и фамилии собственников - шум. Доверяет, потому что статусы стыкуются с регламентом миграции. Куратор домена - каждый день фильтрует свой домен с drill до объектов, понимает куда вложиться сегодня, выходит со списком своих объектов по приоритету; чужие домены и общие KPI компании только мешают. Доверяет, потому что статусы совпадают с его трекером задач. Это два сценария одного Workbook - «обзорный» и «по домену», переключение одной кнопкой. Никакого «универсального экрана с фильтрами» - даже фильтры разные. Вывод Дэш «для всех» - это не экономия, это никакой дэш. Когда менеджмент щурится и не находит ответ, а аналитики прокручивают мимо своей зоны - это не проблема визуала. Это пропущен нулевой шаг: «а кто и зачем сюда заходит». Шаблон с 5+2 выглядит избыточно, пока не попробуете раз. На втором кейсе он превращается в напоминалку: «ты не закрыл сигналы доверия» - значит дэшу не будут верить, как ни рисуй. 🚀 Дальше в серии: дэш здоровья метрик (где разделяются «куратор» и «оунер метрики») и дэш core-слоя (где контуров уже три).

Релиз. Каскад: настройка Claude Code для аналитика Сегодня выкладываю гайд. Полтора месяца писал, последние недели вы его видели по кускам. Теперь - целиком. Что вы получаете в базовой версии: ▫️ PDF на 22 страницы - удобно открывать с любого устройства ▫️ Шаблоны CLAUDE.md, SKILL.md, MEMORY.md - анонимизированные версии моих рабочих файлов. Не учебные, а из прода. Копируете, адаптируете под свой стек, начинаете работать ▫️ Чек-лист «Подготовка проекта по шагам» - 18 шагов, которые проводят вас от текущего состояния до каскадной архитектуры. ▫️ Три рабочих кейса с моих проектов: дайджест мессенджера на 35 каналов, контент-фабрика на два Telegram-канала, автоматизация месячного отчёта по миграции витрин. Каждый - с реальными конфигами, расписанием и параметрами Премиум добавляет (лимит 15 мест на запуск): 1️⃣ Часовой созвон со мной. Я смотрю ваш репозиторий, разбираю, что у вас сейчас в CLAUDE.md, скиллах и памяти 2️⃣ Помогаю выстроить каскад под ваш стек и стримы. Не «общие рекомендации», а конкретные правки в ваши файлы 3️⃣ Разбираем одну вашу задачу, которые вы хотите автоматизировать через скиллы 4️⃣ Отвечаю на вопросы по специфике вашей среды После консультации у вас не «материал для изучения», а работающая каскадная архитектура для вашего конкретного проекта. Чего внутри нет (чтобы не было сюрпризов): ▪️ Это не гайд по AI и нейросетям вообще. Не пересказ Anthropic-документации. Не «секреты промптинга» - там нет секретов, есть дисциплина ▪️ Это не про Cursor, не про Cline, не про Claude.ai в браузере. Только Claude Code как CLI-агент, потому что только он живёт в кронах и MCP ▪️ Это не для тех, кто никогда не открывал терминал. Я предполагаю базовую работу с файлами, git, shell. Без этого каскад не нужен ▪️ Это не серебряная пуля. Никакая подготовка контекста - ни каскад, ни Obsidian, ни графовые БД - не уберёт ошибки и галлюцинации LLM до нуля. Каскад снижает их кратно, но не до 100%. На текущем уровне развития нейросетей часть ошибок остаётся, и к ним нужно относиться спокойно. Если вы ищете магическое решение - его пока нет ни у кого 🚀 Кто уже читал превью - вы понимаете, о чём гайд. Если зашло - открывайте бот @pbdl_tg_bot, команда /buy_ai_guide. Премиум-слотов осталось семь на момент публикации этого поста.

Что внутри гайда: каскадная архитектура В понедельник я анонсировал гайд про настройку Claude Code. Сегодня - превью самой важной страницы. Это диаграмма, на которой держится всё остальное. ~/work_repo/.claude/ ├── CLAUDE.md ← главный зонт ├── memory/MEMORY.md ← индекс памяти └── skills/ ├── work/ ← рабочий стрим │ ├── PROJ-101_migration_dwh/ ← ЭПИК Jira │ │ ├── SKILL.md │ │ ├── PROJ-1011_vitrina/SKILL.md │ │ └── PROJ-1012_lineage/SKILL.md │ └── PROJ-102_core_layer/SKILL.md └── content/ ← личный стрим └── partitionbydatalab/ ├── styleguide/SKILL.md └── post-format/SKILL.md Идея простая: проектная иерархия Jira (Инициатива → Эпик → Таск) зеркалится в файловую структуру скиллов. Когда агент срабатывает на тикете PROJ-1011, он каскадно подтягивает: главный CLAUDE.md (профиль, MCP) → SKILL.md эпика PROJ-101 (цели, общая процедура) → SKILL.md таска (SLA, источники, схема). Контекст набирается слоями, без дублей. Переключился агент на личный стрим - пропали корпоративные правила, активировались скиллы канала. Один и тот же агент, разные «личности» в зависимости от того, в какой папке он сейчас работает. Главный вопрос, который встаёт сразу: куда положить новое правило - в зонт или в стрим. У меня в гайде на это есть страница, но если коротко: ▫️ Идёт в корневой CLAUDE.md если правило релевантно двум и более стримам. Профиль пользователя, общие MCP-серверы, безопасность, прокси для Anthropic в РФ-сети - всё это глобально ▫️ Остаётся в стримовом CLAUDE.md если работает только в одном стриме. Расписание публикаций контент-фабрики - только личный стрим. Конвенции PR в DWH-репозитории - только рабочий стрим ▫️ Уходит в SKILL.md если это шаги воспроизводимой процедуры. Лимиты конкретного канала, SLA конкретного таска, эталоны и шаблоны Ошибка новичков - класть всё в корневой CLAUDE.md «чтобы точно сработало». Корень разрастается, prompt cache рвётся при каждой правке, контекст забивается тем, что нужно одному скрипту в неделю. Дисциплина: правило держится на самом узком уровне, на котором оно ещё работает. И ещё одна часто встречающаяся ловушка - когда правило живёт в нескольких местах. В CLAUDE.md - «всегда отвечать по-русски». В скилле - пример с английским ответом. Агент срабатывает на скилл, отвечает по-английски. Через месяц вы забываете, где это поправить, чтобы починить. Но: ▪️ Каскад не делает агента умнее. Он делает контекст осмысленнее ▪️ Дисциплина важнее разовой настройки. Через два месяца, когда вы поймаете себя на «брошу правило куда-нибудь, потом разберусь», - вспомните этот пост ▪️ Это не серебряная пуля. Никакая подготовка контекста - ни моя каскадная система, ни Obsidian, ни графовые БД - не уберёт ошибки и галлюцинации LLM до нуля. Каскад снижает их кратно, но на текущем уровне развития нейросетей часть ошибок останется. К ним нужно относиться спокойно 🚀 Предзаказ открыт до релиза 16 мая. Два тарифа: базовый только pdf, премиум pdf+часовой созвон со мной. Промокод GUIDE20 дает скидку 20%, лимит 10 мест (на сейчас осталось чуть меньше половины). Бот @pbdl_tg_bot - команда /start

Каскад: настройка Claude Code для аналитика. Анонс Последние полтора месяца я писал гайд про то, как навести порядок в инструкциях для Claude Code. На этой неделе открываю предзаказ. Сейчас - что внутри. Гайд называется «Каскадный AI-агент для аналитика». 20+ страниц, плотно, без воды и AI-101. Не про то, что такое нейросети, а про то, как настроить рабочую среду так, чтобы агент работал, а не переписывал работу заново. Думаю многие часто сталкиваются, что при запуске агента он как с чистого листа либо вылетает из контекста, ошибается, чтобы такого не было я разработал свою каскадную систему проекта. Что я туда положил: Часть 1 - введение. Что такое Claude Code (и чем отличается от Claude.ai в браузере), какую модель брать под какую задачу (Haiku в кроны, Sonnet в IDE, Opus на ревью архитектуры), как работает prompt caching и почему он экономит 3-5 раз бюджета, как Claude собирает контекст в первую секунду сессии. Пять страниц. Часть 2 - мясо. Каскадная иерархия: три типа файлов (CLAUDE.md, SKILL.md, MEMORY.md), как они раскладываются по уровням (зонт, стрим, эпик, таск), правило сливания вверх, разделение «глагол vs существительное», антипаттерны, эффект на токены и качество. Десять страниц с центральной диаграммой, на которой держится всё остальное. Часть 3 - финал. Рабочие кейсы с моих проектов рабочих и личных (разработка дашбордов, дайджест мессенджера, контент-фабрика на два канала, автоматизация месячного отчёта), кроны и автономный режим, что делать когда агент тупит, безопасность токенов и доступов. Пять страниц. Кому подойдёт: ▫️ Аналитикам, BI-разработчикам, дата-инженерам, которые уже пробовали Claude Code и поняли, что просто открыть его недостаточно ▫️ Тем, кто хочет в кроны и автономные пайплайны, а не только интерактивные сессии ▫️ Тем, кто работает в крупных компаниях с корпоративными прокси и MCP-серверами Кому не подойдёт: ▪️ Тем, кто никогда не открывал терминал ▪️ Тем, кто ищет «секреты промптинга» - тут не про это ▪️ Тем, кто хочет общую теорию без привязки к стеку - я пишу из практики, не из Anthropic-документации Что вы сможете сразу: 1️⃣ Перевести свой проект на каскадную структуру по чек-листу 2️⃣ Адаптировать свои CLAUDE.md, SKILL.md, MEMORY.md 3️⃣ Настроить три прикладных скилла (дайджест, отчёт, ревью) 4️⃣ Провести аудит существующего setup'а на антипаттерны 🚀 Превью уже доступен. Это одностраничная PDF со схемой каскада и четырьмя ключевыми правилами. Бесплатно, через бот @pbdl_tg_bot - команда /start. Пользы хватит, чтобы понять подход без покупки. Уже сейчас там открыт предзаказ со скидкой 20 процентов первым 10-ти людям по промокоду GUIDE20. Релиз - 16 мая.

Что взять с собой на майские, кроме мангала Длинные выходные: три дня. Если в перерывах между шашлыками хочется полистать что-то полезное - вот шесть вещей из моего списка «рекомендую BI-коллегам». Не от корки до корки - достаточно пройтись глазами. ▫️ DAMA DMBOK (2-я редакция) Не книга, а справочник. Толстая энциклопедия про управление данными - 11 функциональных областей, от architecture до governance. Сесть и читать от начала до конца невозможно, и не надо. Но когда к вам в следующий раз придут с вопросом «а как у нас с data quality?» - открываете соответствующую главу, там систематизированный ответ. Кому: любому, кто сталкивается со словом «governance» чаще раза в квартал. Когда ломается: если ждёте практических рецептов «сделай раз, сделай два». Здесь больше про системы мышления, чем про инструкции. ▫️ Ralph Kimball, «The Data Warehouse Toolkit» (3rd ed) Dimensional modeling - факт-таблицы, измерения, SCD, conformed dimensions. Книга вышла ещё до того, как мы начали произносить слово «облако», но фундамент с тех пор не изменился. Если вы строите витрины и не читали Кимбалла - считайте, что изобретаете велосипед из палок. Кому: всем, кто проектирует ХД или витрины. Когда ломается: за пределами dimensional подхода. Data Lake, event-driven архитектуры, data mesh - там свои законы. ▫️ Henderson-Venkatraman, Strategic Alignment Model (статья 1993 года) Короткая, 15 страниц, легко гуглится. Модель про то, как бизнес-стратегия и ИТ-стратегия должны быть согласованы через четыре домена. Выглядит как абстракция, но когда начинаешь натягивать на реальный BI-проект - внезапно объясняет, почему красивая витрина оказывается никому не нужной. Кому: если приходится обосновывать BI-инициативу перед руководством. Когда ломается: внутри одной команды это избыточно. Для вечерней задачки - тяжеловесно. ▫️ Bas Harenslak, «Data Pipelines with Apache Airflow» - увидел у Димы Аношина Книга от инженера, который пишет DAG-и каждый день, а не рассуждает о них с Gartner-подиума. Про практику: как устроены DAG-и, операторы, sensors, хуки, как тестировать пайплайны и чинить фейлы в четыре утра. Читается как учебник в хорошем смысле - примеры, схемы, реальные сценарии. Кому: тем, кто пишет или сопровождает пайплайны - не обязательно в Airflow. Половина принципов применима и к dbt, и к Dagster, и к любому cron-скрипту, который разросся до боли. Когда ломается: если Airflow вам не нужен и не светит. Но методологически всё равно полезна - как оглавление того, что должно быть в любом оркестраторе. ▫️ Zhamak Dehghani, «Data Mesh» Самая обсуждаемая книга по BI-архитектуре за последние годы. Про децентрализацию - домены владеют своими данными как продуктами, центральная команда даёт платформу. Читать с критическим мышлением: не серебряная пуля, но важный сдвиг в мышлении про ownership. Кому: если в компании разрослись запросы «сделайте нам ещё одну витрину» и центральная команда не тянет. Когда ломается: в компаниях без культуры ownership. Там data mesh превращается в «данные у всех и никто ни за что не отвечает». ▫️ Bill Inmon, «Building the Data Warehouse» Историческая альтернатива Кимбаллу. Inmon - про централизованное корпоративное хранилище, 3NF, subject areas. Две школы долго считались враждующими; сейчас Inmon признаёт ценность dimensional подхода. Читать стоит ради классических дебатов - без них обсуждения про «core-слой vs витрины» теряют контекст. Кому: архитекторам ХД и тем, кто задумался о корпоративной семантической модели. Когда ломается: если только начинаете - Кимбалл проще для старта. Inmon - второй заход. И одна оговорка Не пытайтесь прочитать всё. Это верный способ испортить себе выходные и ничего не запомнить. Возьмите одну - ту, которая отвечает на живой вопрос прямо сейчас. Остальные пусть лежат на полке.

Три кита инструкций для агента: правила, скиллы, память В прошлом посте я писал, как агент перестал галлюцинировать на 35 каналах после переноса правил по уровням. Несколько человек спросили, как именно эти уровни выглядят. Сейчас расскажу. У Claude Code есть три типа файлов с инструкциями. Каждый - со своей ролью и своим режимом обновления. Если их перепутать, получится та самая свалка, в которой тонут хорошие правила. ▫️ CLAUDE.md - статический контракт. Сюда идут факты и правила, которые меняются редко. Профиль пользователя, стек проекта, правила работы с git, перечень MCP-серверов, конвенции именования. Этот файл грузится в контекст агента всегда. Поэтому в нём должно быть только то, что переживёт неделю - не то, что меняется в течение дня. ▫️ SKILL.md - триггерный модуль. Это файл с описанием конкретного процесса (собрать дайджест, сделать дашборд, выкатить витрину). У каждого скилла во фронтматтере лежит description - однострочное описание, по которому агент решает, нужен ли скилл сейчас. Само тело скилла грузится только тогда, когда description совпал с задачей. Это позволяет хранить десятки сценариев без раздувания контекста. А ещё у антропика есть скил по написанию скиллов =) ▫️ MEMORY.md - индекс авто-памяти. Здесь не сами знания, а ссылки на них. Сами факты лежат в отдельных файлах (один файл - один факт). Индекс грузится всегда, тела отдельных файлов - лениво. Три кита, четыре простых правила, которые держат всю систему: 1️⃣ Одна правда - в одном месте. Если правило живёт и в зонтичном CLAUDE.md, и в скилле, и в памяти - это не страховка, это будущий дрейф. Через месяц одно из мест уйдёт вперёд, остальные начнут расходиться 2️⃣ Скилл - это глагол, CLAUDE.md - существительное. «Как собрать дайджест» - скилл. «Лимит TG caption - 1024 символа» - CLAUDE.md. Если новый блок звучит как «делай так-то», это скорее скилл 3️⃣ Релевантность ≥ 2 стримов = вверх. Правило идёт в зонт только когда нужно двум и более стримам. Иначе остаётся в стриме. Иначе - в скилле. Если положили выше, чем нужно, контекст забивается шумом 4️⃣ Description - это интерфейс скилла. Расплывчатое описание = скилл не сработает там, где должен. «Скилл про публикацию» - не сработает. «Применяй когда пользователь говорит "опубликуй пост" или сразу при работе с .md в папке posts» - сработает Но: ▪️ Это всё дисциплина. Никто не запретит вам положить правило неправильно - агент будет работать, просто хуже ▪️ Память отдельная история - она живёт за пределами вашего репо, вы её даже в git не закоммитите. Управляется через правила в CLAUDE.md и периодический ручной аудит 🚀 Позже расскажу про каскадную структуру для рабочего стрима (как Jira-эпики и таски ложатся в дерево скиллов) и про антипаттерны, которые я разработал сам имперически при работе как на рабочих так и на собственных проектах. После этого - готовлю практический гайд с шаблонами.

Дайджест 35 каналов за семь минут Каждый понедельник в 09:00 у меня в личке появляется пост: дайджест прошедшей недели по 35 рабочим каналам мессенджера. С разбивкой на тематические блоки, с ID тикетов, ссылками, фамилиями вместо username. Делает его агент, я только утром читаю. До того как я перевёл это на нормальную архитектуру, дайджест занимал 18-22 тысячи входных токенов на проход. С учётом ежедневной утренней + вечерней пробежки получалось дорого, а главное - агент часто галлюцинировал. То тегал коллег вместо фамилий, то склеивал темы из соседних чатов, то выдумывал контекст «по правилам». Я разбирал, в чём проблема, и обнаружил классическую штуку. У меня был один большой файл с правилами - туда спринтами накидывали всё подряд. Профиль, MCP-серверы, стиль ответов, лимиты, шаги дайджеста, формат отчёта. Всё это грузилось в каждый запрос целиком. ▫️ Часть правил была универсальной (не используй длинное тире) - и применялась везде нормально ▫️ Часть была специфичной для дайджеста (фамилии вместо username) - и тонула среди других, агент её не замечал ▫️ Часть была дублированной в трёх местах с разными формулировками - в одном «всегда фамилии», в другом «не тегай», в третьем «преобразуй username в имя» - агент выбирал ту, что попадалась первой То, что выглядело как сбой умной модели, оказалось обычным мусором в инструкциях. Я разнёс правила по уровням. Универсальное - в зонт. Стримовое (рабочие правила, конвенции PR) - в стрим. Локальное (формат дайджеста, эталон, что игнорировать) - в скилл. Ничего не дублировал. Что получилось: 1️⃣ Прогон дайджеста стал стоить 6-8 тысяч токенов. В три раза меньше 2️⃣ Стартовый префикс перестал переписываться - prompt cache работает весь день, повторные запросы платят 10% обычной цены 3️⃣ Правило «фамилии вместо username» агент применяет в 100% случаев - оно теперь видно в нужный момент, а не тонет в шуме 4️⃣ Если хочу что-то поменять - я знаю, в каком файле живёт правило. Раньше приходилось грепать по трём местам, чтобы быть уверенным, что не остался дубль Но: ▪️ Дисциплина - не разовый рефакторинг. Через два месяца я ловил себя на том, что новое правило хочется бросить «куда-нибудь, разберусь потом». Каждый раз это «потом» обходится сильно дороже ▪️ Память тоже надо разгребать - там накопилось 27 файлов, два из них стали по 10 КБ каждый. Линт-скилл раз в месяц - обязательно И наконец агент начал отмечать все чаты причтанными, таким образом у меня нет шума в рабочем чате! 🚀 Это не магия и не «секрет, который от вас скрывают». Это аккуратная раскладка инструкций по уровням и дисциплина, чтобы они там оставались. На следующей неделе расскажу подробнее про то, как именно эти уровни устроены и какое правило куда идёт.

Как оценить данные в деньгах и не обмануть себя Любой BI-архитектор рано или поздно ловит этот вопрос. «Сколько стоит то, что вы строите?» Полезно, чтобы ответ был в голове - не пафосный, а с цифрами. Сложность в том, что данные - не акции. С акцией просто: купил за 100, продал за 120, разница - ценность. С данными даже затраты на получение посчитать непросто. В DMBOK (2-я редакция) есть целый раздел про это. Авторы предлагают начинать не с одной цифры, а с набора категорий затрат и выгод: ▫️ Затраты на получение и хранение - compute, storage, лицензии, ФОТ команды ▫️ Затраты на восстановление после утери - тест: если завтра потеряете половину DWH, сколько стоит собрать всё обратно? ▫️ Потери из-за отсутствия нужных данных - аналитик не нашёл витрину, написал запрос на сыром слое полдня, менеджмент ждёт. Это деньги. ▫️ Затраты на повышение качества - чистка, data contracts, DQ-чекеры ▫️ И ещё пять категорий: риски, выгоды от качества, цена для конкурентов, стоимость при продаже, доходы от инновационного использования Главная оговорка: ценность данных зависит от контекста. Одни и те же данные в одной организации стоят миллионы, в другой - ноль. Ещё один объективный ценник подкинула жизнь - WannaCry в 2017 захватил 100 000 организаций в 150 странах и требовал выкуп за расшифровку файлов. Мрачновато, но это и есть готовность бизнеса платить за свои данные, в рублях за гигабайт. На моей практике в одном проекте подход был такой: Задача - обосновать экономику консолидированного слоя витрин (центральный core-слой, снимающий нагрузку с сырого). Мы считали не одну цифру, а три блока: 1️⃣ Высвобожденное время аналитиков Берём реальное время, которое аналитики тратят на поиск витрин и написание запросов - по логам, без опросов. Переводим в деньги через ставку. 2️⃣ Compute Интеграл по Cumulative RAM - сколько ресурсов съедают запросы, которые могли бы обслуживаться из core-слоя, а сейчас обслуживаются из сырого. 3️⃣ Storage Размер дублирующих витрин, которые схлопнутся в одну. С учётом репликации на три ДЦ. Парадокс - экономия не в сокращении текущего размера, а в подавлении будущего роста. Но: ▪️ Время аналитиков считается как юнион интервалов, когда кто-то что-то делал - это календарный интервал, а не сумма человеко-часов. Два параллельных поиска по полтора часа в юнионе дадут полтора часа, а в человеко-часах - три. Реальная экономия может быть заметно больше, чем мы показываем. ▪️ Не все оценки равны. Compute и storage - настоящие деньги, счета от ЦОДа. Время аналитиков - предсказанная экономия, её ещё нужно доказать. Если смешать всё в одну цифру, сильные оценки тянутся вниз за счёт слабых. Лучше держать их раздельно: «доказуемо / предсказано». ▪️ Compute экономится не от существования core-слоя, а от того, что в него уходят именно тяжёлые запросы. Если в core уйдут самые лёгкие по RAM и CPU, а тяжёлые останутся в сыром слое - оценка схлопнется. Стратегию имеет смысл заранее нацеливать на тяжёлые паттерны. ▪️ Storage - честнее доказать экономию на будущем росте, чем на текущем размере. «Вот как растёт хранилище, вот как core-слой снизит рост, вот за сколько стоят сервера». Это сильнее, чем «мы схлопнули X дублей». Вывод Смысл не в красивой цифре на слайде. Смысл - чтобы сама процедура навешивания ценников на данные вошла в привычку. Без этого вы управляете активом, которому ни разу не смотрели в лицо. «Навешивание ценников - первый шаг на пути к оценке реального экономического эффекта». Ключевое - «первый шаг», не финальный ответ. Итоговая сумма в таком упражнении - не ценник, а рабочая гипотеза, которую дробят на проверяемые куски. Половина ценности работы не в цифре, а в том, что начинаешь отличать «реальные деньги» от «предсказанной экономии».

Как сделать Self-Service BI рабочим: 4 кейса из практики В прошлом посте я объяснил, почему self-service обычно не работает. Но это не значит, что идея мертва. Есть подходы, которые реально работают. Четыре кейса. Разные компании, разный масштаб, но паттерн один. 1️⃣ Кейс "Управляемая песочница" Компания создала два пространства: production (курируемые отчёты от аналитиков) и sandbox (площадка для экспериментов). Бизнес-пользователи могут строить что угодно в sandbox. Но если отчёт становится регулярным - он проходит ревью и переезжает в production. Ключевое: sandbox работает на тех же подготовленных данных что и production. Нельзя подключиться к сырым таблицам. 2️⃣ Кейс "Параметризованные шаблоны" Вместо "постройте свой дашборд" - "выберите параметры в готовом". Аналитики создали 10-15 шаблонных отчётов с гибкими фильтрами: период, сегмент, регион, продукт. 80% запросов бизнеса закрываются комбинацией фильтров. Оставшиеся 20% - ad hoc, делают аналитики. Не красиво, но работает. 3️⃣ Кейс "Data Champions" В каждом бизнес-отделе выделили по одному "чемпиону данных" - человеку, который прошёл обучение и стал мостиком между отделом и аналитиками. Чемпион строит отчёты для своего отдела, знает контекст, понимает данные. Не full-time аналитик, но и не случайный пользователь. 4️⃣ Кейс "Семантический слой как продукт" Самый зрелый подход. Команда данных строит семантический слой (Looker, dbt metrics, Cube.dev) - подготовленные, документированные, проверенные метрики. Пользователь не может ошибиться в расчёте, потому что расчёт уже встроен в слой. Он просто выбирает измерения и фильтры. Что общего у всех четырёх? ▫️ Подготовленные данные - пользователь не видит сырые таблицы ▫️ Ограниченная свобода - свобода в рамках, а не хаос ▫️ Поддержка и обучение - кто-то всегда рядом чтобы помочь ▫️ Чёткая граница - что можно самому, а что через аналитика Контраргумент: ▪️ "Это же не настоящий self-service! Это managed service!" ▪️ Именно. Чистый self-service - утопия. Работает managed self-service: свобода в подготовленных рамках. Не спрашивайте "как внедрить self-service". Спрашивайте "какие 80% вопросов бизнес может закрыть без аналитика, если мы подготовим данные". Ответ на этот вопрос - и есть ваш план. 🚀 Какой кейс ближе к вашей реальности?

Всем привет! Мой хороший товарищ и коллега Женя (@oblivionrrr) ищет себе в команду middle BI-разработчика — репощу с чистой совестью, реально топлю за этих ребят. Команда — ASD Авито Работы, TL + 4 биайщика. Делают BI-продукты от идеи до поддержки. Self-Service развивают, AI-агентов в повседневку уже встроили. Адхоки не любят 😁 Кого ищут: драйвера и тащера, который закроет поддержку отдела продаж. Важны и харды, и софты — нужно балансировать между кодом и разговорами со стейкхолдерами. А их там 10+, так что скучно не будет. Что такое ASD на пальцах: департамент продаж, где менеджеры разных грейдов ведут своих клиентов, плюс есть self-service сценарии. Глобальная цель — рост выручки через развитие текущих клиентов и новых проектов. И на каждом этапе работы менеджера отчётность — основной инструмент принятия решений. То есть зона ответственности команды — буквально нерв всего отдела продаж. Что предстоит делать: — работать с 10+ стейкхолдерами, выявлять боли — делать BI проекты от идеи до поддержки — рефакторить дашборды и участвовать в сертификации BI — развивать Self-Service — использовать AI-агентов — быть полноценной частью команды — делиться опытом и перенимать его На поддержке сейчас ~60 отчётов и 15 ключевых витрин. Простор для инициатив — огромный, и это правда: я знаю, как там устроено. Стек: DWH (Trino/Vertica), Redash (ClickHouse/JS/HTML), Aviflow (Python), Jira, Confluence. Если откликается — резюме Жене в TG: @oblivionrrr. За репост — плюс в карму ❤️

Self-Service BI: почему красивая идея не работает Идея красивая: дать бизнес-пользователям инструменты, чтобы они сами строили отчёты. Без очереди к аналитикам, без тикетов, без ожидания. Демократизация данных! На практике я видел это три раза. Три раза это начиналось с энтузиазма. Три раза заканчивалось одинаково: аналитики всё равно делают 90% работы, а self-service превратился в источник некорректных отчётов. Почему? ▫️ Проблема компетенций Построить отчёт - это не "перетащить поля в визуализацию". Это понять структуру данных, правильно выбрать агрегацию, учесть фильтры, не сравнить несравнимое. Парадокс, который я увидел при миграции с Tableau на web-BI: в Tableau self-service реально работал - drag-n-drop, LOD-вычисления, рекомендации по визуализациям. Инструмент настолько вылизан, что менеджер мог собрать приличный отчёт сам. В open-source web-BI хочешь что-то сложнее столбчатой диаграммы - учи JS. Инструмент мощнее, но порог входа выше. Self-service умер не потому что люди стали глупее, а потому что сменился инструмент. ▫️ Проблема качества данных Self-service предполагает, что данные готовы к использованию. В реальности - половина таблиц не документирована, названия колонок непонятны, есть дубли и пропуски. Пользователь берёт первую попавшуюся таблицу revenue и строит отчёт. А таблиц revenue - четыре. Пока нет core-слоя с каноничными витринами и единого каталога сущностей - self-service это лотерея. Пользователь может попасть на правильную таблицу. А может и нет. ▫️ Проблема "одинокого героя" Обычно self-service внедряет один энтузиаст - продвинутый бизнес-пользователь. Он реально разобрался, строит крутые отчёты, всех вдохновляет. Потом он меняет отдел или увольняется. Его дашборды - новые зомби. ▫️ Проблема доверия Когда каждый может построить отчёт - каждый строит свой. На совещании три человека приходят с тремя разными цифрами. Вместо экономии времени - больше споров и меньше доверия к данным. ▫️ Проблема инструмента как решения "Мы купим Tableau/Looker/Power BI и всё заработает!" Инструмент - это 10% решения. Остальные 90% - это данные, процессы, обучение и поддержка. Но 90% бюджета уходит на лицензию. Контраргумент: ▪️ "Но ведь есть компании, где self-service работает!" ▪️ Есть. И у них общее: зрелая data-платформа, подготовленные данные, обученные пользователи и выделенная команда поддержки. То есть self-service работает тогда, когда под него заложен серьёзный фундамент. Self-service BI - не плохая идея. Это преждевременная идея для большинства компаний. Как её сделать рабочей - в следующем посте. 🚀 Работает ли self-service у вас, или аналитики всё равно делают всю работу?

Лечим BI-архитектуру: план реанимации за 90 дней В прошлом посте - диагноз. Теперь - план лечения. 90 дней, три фазы. Не "идеальная архитектура с нуля", а реалистичный план для команды, которая параллельно делает текущую работу. Фаза 1: Остановить кровотечение (дни 1-30) ▫️ Провести аудит: что есть, что используется, что мертво Пройдитесь по всем дашбордам, отчётам и пайплайнам. Разметьте: активно используется / иногда открывают / никто не смотрит. Обычно 60-70% попадает в третью категорию. Не удаляйте пока - просто зафиксируйте. Мы начали с разметки ключевых датасетов - выделили те, которые питают операционные дашборды для сотен людей. Эти датасеты получили приоритетный расчёт - считаются первыми в очереди. Остальные ждут. ▫️ Выбрать 5-10 критичных отчётов Те, по которым принимаются реальные решения каждый день. Это ваш "золотой набор". Весь фокус следующих фаз - на них. ▫️ Настроить мониторинг пайплайнов Алерт в мессенджер когда данные не обновились вовремя. Плюс еженедельный автоотчёт: что отработало в SLA, что деградировало по времени расчёта, где нарушен error budget. Простейший healthcheck, 2-3 дня работы. ROI - космический. Фаза 2: Навести порядок (дни 31-60) ▫️ Построить базовый слой моделей данных Для золотого набора отчётов: стандартизировать определения метрик, вынести общие расчёты в переиспользуемые модели. Мы этот слой называем core-layer. SQL витрин ведём в git-репозитории с code review - любое изменение расчёта метрики проходит через PR. Параллельно вешаем data contracts на каждую витрину. Инструмент (dbt, LookML, view в базе) вторичен - подход первичен. ▫️ Один источник правды для ключевых метрик Revenue, MAU, конверсия - три-пять метрик, которые все считают по-разному. Зафиксировать одну формулу, один расчёт, одну точку доступа. Остальное - потом. ▫️ Документация? Минимум, но обязательный Не 100-страничный confluence. В минимальной версии - data docs: каталог витрин с описаниями полей, владельцами и линеджем. В продвинутой - автогенерация описаний через LLM как baseline, потом ручная вычитка владельцем. 10 строк текста на витрину, которые экономят часы. Фаза 3: Закрепить (дни 61-90) ▫️ Code review для аналитических моделей Если аналитик меняет расчёт метрики - это проходит через review. Как код в production. Звучит бюрократично, но спасает от "я тут формулу поправил и всё поехало". ▫️ Архивировать мёртвые дашборды Помните те 60-70%? Архивируйте. Не удаляйте совсем (на всякий случай), но уберите из видимости. Меньше шума - легче найти нужное. ▫️ Ретро: что получилось, что нет Честный разговор с командой. Что из плана реально работает, что осталось на бумаге. Скорректировать курс на следующие 90 дней. Контраргумент: ▪️ "90 дней - это нереально, у нас текучка и горящие задачи!" ▪️ 90 дней - это не full-time. Это 20-30% времени одного-двух аналитиков. Если даже этого нет - значит вы тушите пожары, а не строите систему. И будете тушить вечно. Лучшая архитектура - та, которую строят итеративно. Не ждите момента "когда будет время". Его не будет.

5 признаков того, что ваша BI-архитектура больна BI-архитектура - как здоровье. Пока всё работает - никто не думает. Когда ломается - все бегут к "врачу". Но к этому моменту обычно уже поздно лечить таблетками - нужна операция. Я научился видеть симптомы до того, как система ляжет. Вот пять красных флагов. ▫️ 1. "У нас 200 дашбордов, но никто не знает какие актуальные" Классический симптом отсутствия каталогизации. Аналитики создают новые дашборды вместо того чтобы искать существующие - потому что искать дольше чем сделать заново. На одном проекте мы стали отслеживать использование каждого дашборда через product analytics. Выяснили что 70% дашбордов открываются реже раза в месяц. Это цифровой мусор - занимает место, путает пользователей, тратит compute на обновление. Система растёт, но не развивается. ▫️ 2. Одну и ту же метрику считают тремя разными способами Финансы считают revenue из биллинга. Продукт - из event-логов. Маркетинг - из CRM. Три числа, три правды, ни одной верной. Если звучит знакомо - у вас нет единого семантического слоя. В зрелых платформах для этого существует метрическая система - единый реестр метрик с формулами, владельцами и версионированием. Не каталог данных, а каталог бизнес-логики. ▫️ 3. Время от запроса до отчёта - недели "Можете посчитать конверсию по новому сегменту?" - и аналитик уходит на две недели. Не потому что считать сложно, а потому что 80% времени уходит на поиск данных, понимание структуры и проверку качества. Сейчас появляются SQL-ноутбуки и AI-ассистенты, которые помогают аналитику быстрее находить нужные данные. Но если под ними хаос в витринах - AI просто быстрее найдёт неправильную таблицу. ▫️ 4. ETL-пайплайны ломаются, и никто не замечает неделями Данные перестали обновляться в пятницу. В понедельник никто не заметил. Во вторник менеджер спросил "почему цифры странные". В среду нашли проблему. Мы решили это оркестратором с SLA - каждая таска имеет временное окно, если не отработала - алерт в мессенджер автоматом. Плюс еженедельный автоотчёт по всем пайплайнам: что отработало, что упало, что деградировало по времени. Звучит просто, но до внедрения это была именно та картина - никто не замечает неделями. ▫️ 5. Каждый новый запрос начинается с нуля Нет переиспользуемых моделей данных. Каждый отчёт - ad hoc запрос к сырым таблицам. Аналитики пишут одни и те же JOIN-ы десятки раз. Именно поэтому мы строим core-слой - каноничные витрины, которые переиспользуются всеми доменами. Один раз посчитали revenue правильно, положили в витрину с SLA и документацией - и все домены берут оттуда. Не пишут свои JOIN-ы к сырым данным. Без core-слоя каждый аналитик - сам себе DWH-инженер. Контраргумент: ▪️ "Но у нас маленькая команда, нам рано думать об архитектуре!" ▪️ Архитектура - это не размер. Команда из трёх аналитиков может иметь чистую архитектуру, а отдел из тридцати - полный хаос. Дело в подходе, не в масштабе. Если узнали хотя бы 3 из 5 - это не приговор. Это диагноз. А диагноз - первый шаг к лечению. Об этом - в следующем посте. 🚀 Сколько симптомов узнали у себя? Пишите честно.