Руководителю аналитики: что нужно знать, изучать и как улучшать команду

Executive summary #

Руководитель аналитики в зрелой компании — это не «главный, кто умеет SQL/BI», а архитектор решений, который превращает данные в управляемые изменения: в продукте, процессах, рисках, экономике и культуре. Ваша задача — построить систему, которая стабильно производит полезные ответы, вовремя, с контролем качества, в рамках закона и с понятной стоимостью.

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

Целевая аудитория #

Текст рассчитан на руководителей отдела аналитиков, senior analytics managers, руководителей продуктовой аналитики, data/BI-подразделений и смежных лидов (analytics engineering, data science), которые одновременно отвечают за результат бизнеса и за качество аналитической машины.

Цели руководителя #

Навыки и знания

Статистика, моделирование данных, качество данных, эксперименты, продуктовые метрики, базовый ML-overview.

Лидерство и оргдизайн

Структура команды, карьерные траектории, культура качества, ответственность (RACI), мотивация и развитие.

Найм и онбординг

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

Процессы, инструменты, governance

Work intake, приоритизация, QA, документация, контуры данных и безопасности, этика, соответствие требованиям.

В РФ управление данными и продуктовой аналитикой неизбежно пересекается с правовыми и регуляторными требованиями: принципы обработки персональных данных, обязанности оператора, требования к обезличиванию, публикация политики обработки и т. п. Поэтому «data governance» для руководителя аналитики — не опция, а базовая компетенция. citeturn15view3turn10view3turn22search3

Принципы, которые «держат» систему #

Если вы хотите устойчиво улучшать отдел аналитики, держите «опорные балки»:

1) Принцип воспроизводимости. Любой важный вывод должен быть воспроизводим (данные, код, определения метрик, допущения, версия).

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

3) Принцип общего языка. Метрики, термины, data contracts, уровни качества — стандартизированы. Поддерживается метаданными и справочниками. citeturn13view0turn19view0

4) Принцип legal-by-design и privacy-by-design. Данные собираются и используются «по цели», с минимизацией и контролем доступа. citeturn15view3

5) Принцип «аналитика — это продукт». У вас есть пользователи (стейкхолдеры), SLA/ожидания, качество, версия, обратная связь и roadmap.

↑ вверх

Стратегическое видение #

Стратегия аналитики — это ответ на три вопроса: (а) какие решения и процессы мы улучшаем, (б) какие данные и методы нужны, чтобы делать это надёжно, (в) как мы измеряем, что аналитика приносит ценность.

Что такое «аналитика» как функция #

Внутри компании аналитика обычно распадается на 4 «продукта» (иногда их ведут разные роли, но руководителю важно, чтобы они были согласованы):

Четыре продукта аналитики, за которые обычно отвечает руководитель
Продукт	Ценность	Типичные артефакты	Риски, если не управлять
Измерение бизнеса	Единый язык метрик и наблюдаемость	Словарь метрик, KPI-дашборды, метрики-деревья	«Война метрик», разная трактовка, плохие решения
Диагностика и инсайты	Причины, точки роста, экономический эффект	Разборы, записки, RCA, когортный анализ	Случайные инициативы, «интуитивные» команды
Эксперименты	Быстрое и безопасное обучение (test/learn)	Планы экспериментов, отчёты, guardrails	Ложные эффекты, переобучение на шуме, «победы» без устойчивости
Данные как актив	Доступность, качество, безопасность, соответствие	Data catalog, lineage, data contracts, правила доступа	Инциденты, штрафы, «сломанные» пайплайны, недоверие

Идея «данные как актив» имеет смысл только тогда, когда есть дисциплина управления: роли, процессы, метрики и понятный язык. В эту сторону смотрят и отраслевые/международные рамки управления данными (например, DAMA-DMBOK как свод практик и терминологии). citeturn23view1turn19view2

Сервисная модель и портфель #

У зрелого отдела аналитики есть внятный «каталог услуг» (service catalog). Он нужен не для бюрократии, а чтобы защитить команду от хаоса и одновременно дать бизнесу предсказуемость. Каталог отвечает: что мы делаем, каким качеством, за какое время, на каких условиях.

Типичный антипаттерн: «аналитики делают всё». Это приводит к перегруженности, отсутствию приоритизации, уязвимости данных и деградации качества. Выход — формализованный intake, критерии приоритета и Definition of Done (см. разделы ниже).

Практический подход к портфелю: делите работу на Run (поддержка и мониторинг метрик/дашбордов), Change (разовые исследования и решения), Build (создание аналитических «продуктов»: витрин, семантического слоя, экспериментационных платформ).

Управление стейкхолдерами и решениями #

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

Что является решением? Например: выбрать стратегию ценообразования, изменить воронку, отказаться от фичи, пересобрать сегментацию.

Какая метрика подтверждает успех? North Star + guardrails (качество, риск, юридические ограничения).

Кто владелец решения? Не аналитик. Аналитик — владелец метода/качества доказательства, но не бизнес-политики.

Какие риски считаем недопустимыми? Например: ухудшение доступа, рост потерь, комплаенс-риски, негативный UX.

↑ вверх

Техническая основа #

Руководителю аналитики не обязательно быть «самым сильным инженером», но необходимо понимать техоснову настолько, чтобы: задавать правильные стандарты, распознавать риски, принимать архитектурные компромиссы и управлять качеством.

Архитектура данных (минимально жизнеспособная) #

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

Слои: источники → ingestion → хранилище (DWH/Lakehouse) → моделирование → семантика/метрики → витрины/BI → потребители.

Контроль: права доступа, логирование, версия, мониторинг, восстановление.

Метаданные: каталог, lineage, словарь сущностей, владельцы данных.

Формально «качество данных» в стандартах определяется как степень, с которой характеристики данных соответствуют требованиям. Это важная мысль: качество не «абсолютно», оно привязано к целям (требованиям) и контексту использования. citeturn19view0

Метрики и «единые определения» #

Главный источник конфликтов между командами — не «неправильные цифры», а разные определения. Поэтому руководитель аналитики должен внедрить слой метрик (semantic/metrics layer) — даже если технически он реализован просто (таблица определений + ревью + владельцы).

Практическое правило: «Определение метрики — это контракт». В контракт входят: формула, события/источники, фильтры, уровень агрегации, период, исключения, ограничения, владелец и тесты корректности.

На этом уровне особенно важно иметь дисциплину метаданных: что считать «данными», что считать «метаданными», и где хранить «истину об истине». Стандарты по метаданным фиксируют базовые определения: например, метаданные — это данные, которые определяют и описывают другие данные. citeturn13view0

Эксперименты и статистическая грамотность #

Экспериментация — это «двигатель обучения» продуктовой компании, но при слабой дисциплине превращается в фабрику ложных побед. Вам как лидеру аналитики нужны минимум: p-value, уровень значимости, мощность, размер эффекта, ошибки I/II рода, корректность дизайна, работа с выбросами.

Пример корректной формулировки: «Мы ожидаем +X% к метрике Y. Решение примем, если доверительный интервал эффекта не пересекает 0 и guardrails не ухудшены».

Чего избегать: «p-value < 0.05 значит успех». p-value не равно «вероятность, что гипотеза верна».

Практическое определение p-value можно объяснять так: это вероятность получить такие же или более экстремальные результаты при условии, что «эффекта нет» (нулевая гипотеза верна). citeturn17view1

В прикладной аналитике ключевой фактор качества — достаточный размер выборки и корректный дизайн, а не попытки «подогнать» данные под удобные предпосылки. Кроме того, некорректная независимая чистка выбросов в тесте/контроле может смещать результаты; чаще нужны симметричные правила и аккуратные методы (winsorization/capping и т. п.). citeturn17view0

Если вы хотите подпитывать команду «официальным» академическим контуром, полезны курсы и программы, где явно проговорены базовые темы: гипотезы, сравнение средних, bootstrap, ошибки и пр. (пример — курсы НИУ ВШЭ). citeturn17view2

Надзор за ML/DS #

Во многих компаниях руководителю аналитики приходится «держать рамку» вокруг Data Science: согласовывать постановки задач, риск-аппетит, качество, мониторинг и интерпретируемость, а также — социальные и юридические ограничения.

Сигнал, что нужен надзор: модель влияет на решения о людях (скоринг, модерация, персонализация), либо на критические процессы (ценообразование, риск, безопасность), либо используется на масштабных аудиториях.

Для управления рисками полезно мыслить «рамками», а не разрозненными практиками. Например, NIST AI RMF описывает итеративный цикл управления рисками ИИ через функции GOVERN → MAP → MEASURE → MANAGE: от культуры и ответственности — к картированию контекста, измерению рисков и управлению ими. citeturn18view4turn18view0turn18view1turn18view2turn18view3

На уровне стандартов риск-менеджмента ИИ существует и международный ориентир ISO/IEC 23894:2023, который фиксирует сам факт наличия отдельного стандарта «Guidance on risk management» для ИИ и его жизненного цикла. citeturn13view2

Качество данных и метаданные #

Качество данных — это не «про тесты в dbt» (хотя тесты важны). У качества есть организационный контур: владельцы, требования, контроль, инциденты, учёт изменений, и есть технический контур: валидации, мониторинг, lineage, версии, репликации.

В терминологии стандартов, помимо определения data quality как степени соответствия требованиям, выделяется и «управление качеством данных» как согласованная деятельность по контролю и управлению организацией в части качества данных. То есть речь не о «разовых правках», а о системе управления. citeturn19view0

flowchart TD A[Стратегия и цели бизнеса] --> B[Метрики и критерии успеха] B --> C[Контракты данных и определения] C --> D[Сбор / обработка / моделирование] D --> E[Аналитические продукты: отчёты, витрины, модели] E --> F[Решения и изменения в продукте/процессах] F --> G[Измерение эффекта и обратная связь] G --> B subgraph Quality Q1[Data QA: тесты, мониторинг] --> Q2[Инциденты и RCA] Q2 --> Q3[Улучшения и профилактика] end D --> Q1 Q3 --> C

Диаграмма — «контур управления»: аналитика эффективна, когда замыкает цикл «цели → данные → решения → эффект → уточнение метрик/данных».

↑ вверх

Управление командой и операционная модель #

Управление аналитиками — это управление высококвалифицированной неопределённостью. Вы строите систему, где люди: (1) понимают контекст и требования, (2) умеют превратить вопрос в метод, (3) умеют проверять себя, (4) умеют объяснять и внедрять выводы.

Team management #

Сильная команда аналитики держится на трёх вещах: ясность ролей, темп обучения, качество коммуникации.

Роли (пример): product analyst / BI analyst / analytics engineer / data scientist / data steward (частично).

Ожидания: критерии уровня (junior → middle → senior → lead) должны быть описаны «наблюдаемыми поведениями».

Ритмы: 1:1, еженедельные обзоры качества, демонстрации результатов, ретро по процессам.

Практика, которая сильно повышает зрелость: регулярные калибровки. Раз в 2–4 недели вы с лид-аналитиками берёте один кейс/отчёт/эксперимент и разбираете: корректность постановки, чистота данных, метод, интерпретация, дизайн артефакта, ясность рекомендаций.

Hiring & onboarding #

Качественный найм — это спроектированная система принятия решений. Она снижает ошибки и повышает предсказуемость команды. Один из самых практичных принципов — структурированные интервью: одинаковые вопросы для одинаковых ролей + единая шкала оценки + решения на основе заранее определённых критериев. citeturn17view3

Как сделать найм «analyst-proof»: сначала зафиксируйте «атрибуты найма» (компетенции), затем под них соберите матрицу вопросов и рубрику оценки, и только после этого «выпускайте» интервьюеров.

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

Workflows & QA #

Чтобы отдел аналитики был устойчивым, вам нужен «конвейер» из трёх этапов: Intake (принятие запроса) → Delivery (выполнение) → Impact (влияние и пост-контроль).

В дисциплинарном смысле полезно опираться на общий язык процессов управления (инициирование, планирование, исполнение, контроль, завершение) — это позволяет «прикрутить» аналитику к корпоративной системе управления проектами. citeturn10view0

О чем часто забывают: качество — это не только «правильный SQL». Это и качество постановки (цели, ограничения), и качество данных, и качество аргументации (что мы можем и не можем утверждать), и качество внедрения.

Процессный подход и цикл PDCA (Plan–Do–Check–Act) — универсальная организация улучшений: планируем, делаем, проверяем, корректируем. Это применимо и к аналитическим процессам (QA, постмортемы, предотвращение повторов). citeturn11view0

Инструменты и технологический стек #

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

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

Must-have для зрелости: контроль версий (Git), code review, окружения, CI для пайплайнов, мониторинг, каталог/метаданные.

BI и self-serve: лучше меньше «магии» и больше контрактов: определённые метрики, единые фильтры, предупреждения об ограничениях данных.

↑ вверх

Данные, этика и governance #

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

Персональные данные и требования РФ #

Принципы обработки персональных данных в РФ включают законность и справедливость обработки, ограничение обработки заранее определёнными целями, недопустимость объединения баз с несовместимыми целями, минимизацию (неизбыточность), обеспечение точности/актуальности и ограничение сроков хранения с последующим уничтожением или обезличиванием. citeturn15view3turn15view1

Для руководителя аналитики это означает практические требования: фиксируйте цели обработки, минимизируйте атрибуты, разделяйте контуры доступа, внедряйте политики ретеншна, делайте data classification, и исходите из того, что «аналитическая полезность» не оправдывает избыточный сбор. citeturn15view3

Обязанности оператора включают, в частности, обеспечение неограниченного доступа к политике обработки персональных данных (и сведениям о реализуемых требованиях к защите ПДн). Это влияет на то, как вы оформляете данные, документацию и процессы. citeturn22search3

Если организации нужно подать уведомление о намерении осуществлять обработку ПДн, Роскомнадзор предоставляет электронные формы на портале персональных данных. citeturn22search2turn22search6

Инфобез и управление рисками #

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

ГОСТ Р ИСО/МЭК 27001-2021 задаёт требования к системам менеджмента информационной безопасности (СМИБ): контекст, руководство, планирование, поддержка, функционирование, оценивание исполнения и улучшение — то есть «управленческий контур», а не разрозненные технические меры. citeturn16view1turn16view2

В финансовом контуре часто встречается ГОСТ Р 57580.1-2017, который описывает уровни защиты и требования к базовому составу организационных и технических мер, ориентируясь на актуальные угрозы и операционный риск (риск-аппетит). Даже если вы не финорганизация, сам подход «меры ↔ риск ↔ контроль» полезен как управленческий шаблон. citeturn21view0

Этика ИИ и риск-менеджмент #

В РФ существует «Кодекс этики в сфере искусственного интеллекта», который описывает общие этические принципы и стандарты поведения, а также механизмы реализации, применимые к жизненному циклу гражданских ИИ-систем там, где законодательство/техрегулирование не покрывает детали. citeturn7view2turn1search12

Практический вывод для руководителя аналитики: если вы управляете DS/ML и используете данные людей, вам нужна «книга правил» (политики и процедуры), а также понятные проверки: bias/fairness, приватность, безопасность, объяснимость, мониторинг дрейфа и инциденты. На уровне международных рамок полезны NIST AI RMF и стандарты по риск-менеджменту ИИ. citeturn18view4turn13view2

Data governance как дисциплина #

Нормальная governance-система отвечает на вопросы: кто владелец данных, где настоящая версия сущности, какие определения метрик допустимы, как меняются схемы, как управляются доступы и как измеряется качество.

В международных стандартах governance данных рассматривается как часть governance ИТ: например, ISO/IEC 38505-1 трактует governance данных как домен governance ИТ и даёт принципы для органов управления и руководства по эффективному, результативному и приемлемому использованию данных. citeturn20view0

На уровне практик управления данными DAMA-DMBOK описывает ядро знаний, роли, deliverables и метрики дисциплин data management, помогая выстроить общий язык между аналитикой, инженерами и бизнесом. citeturn23view1turn19view2

↑ вверх

KPI, развитие и материалы #

KPIs аналитической функции #

KPI аналитики должны измерять не «объём труда», а управляемую ценность. Хорошая модель KPI — четырёхуровневая: входы → процессы → выходы → исходы (impact).

Пример KPI-матрицы: что измерять руководителю аналитики
Уровень	Что измеряем	Пример метрики	Зачем
Входы	Ресурсы и условия	Доля времени на Run/Change/Build; покрытие ключевых доменов	Понять, где системное «узкое место»
Процессы	Скорость и предсказуемость	Lead time запроса; WIP; доля запросов с корректным брифом	Стабильность и управляемость потока
Выходы	Качество артефактов	Доля работ с peer review; количество дефектов данных; SLA дашбордов	Доверие к аналитике
Исходы	Влияние на бизнес	% решений с evidence; эффект от экспериментов; экономия/рост/снижение риска	Показать ценность и «защитить» аналитику

Практический совет: держите 1–2 «North Star KPI» для самой аналитики (например, доля решений с измеримым эффектом и доверие стейкхолдеров), и 6–10 операционных KPI по качеству/скорости/надёжности.

Learning roadmap #

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

Дорожная карта (12 месяцев) — раскрыть

Месяцы 1–2: инвентаризация: метрики, витрины, источники, ключевые решения, стейкхолдеры. Ввести intake и Definition of Done. Запустить базовый QA и peer review.

Месяцы 3–4: слой метрик: словарь, владельцы, версия, тесты. Внедрить регулярные калибровки качества и формат «аналитической записки».

Месяцы 5–6: экспериментация: стандартизировать план эксперимента, guardrails, post-analysis. Обучить команду статистике (p-value, power, дизайн).

Месяцы 7–8: governance: роли data owner/steward, каталог, lineage, data contracts. Начать измерять качество данных и SLA.

Месяцы 9–10: найм/карьера: описать уровни, компетенции, матрицу интервью, структурированные интервью, онбординг.

Месяцы 11–12: ML/DS oversight (если актуально): risk framework, мониторинг, инциденты, этика/приватность. Поднять качество коммуникаций с руководством: «портфель ценности» аналитики и KPI отдела.

Чтение и ресурсы #

Ниже — список источников и опорных документов. Вначале — российские первичные источники и стандарты, затем — авторитетные индустриальные/международные рамки.

Важно: ссылки даны как справочный материал. Проверяйте актуальность редакций и применимость к вашей отрасли.

Российские первичные источники и стандарты

152‑ФЗ «О персональных данных» (принципы обработки, условия обработки, уничтожение/обезличивание). Контур.Норматив
Статья 18.1 (публикация политики обработки ПДн и меры оператора). КонсультантПлюс
Приказ Роскомнадзора от 19.06.2025 № 140 (требования и методы обезличивания; действует с 01.09.2025; отменяет приказ № 996). Контур.Норматив
Портал персональных данных Роскомнадзора: уведомления и формы. pd.rkn.gov.ru
ГОСТ Р 52872‑2019 (доступность цифрового контента; уровни A/AA/AAA; опора на принципы WCAG). tiflocentre.ru
ГОСТ Р ИСО/МЭК 27001‑2021 (требования к СУИБ/СМИБ; контекст, лидерство, планирование, оценка, улучшение). meganorm.ru
ГОСТ Р 57580.1‑2017 (меры защиты информации финорганизаций; уровни защиты; связь с операционным риском). PDF
ГОСТ Р ИСО 8000‑2 / ISO 8000 (термины качества данных: data quality, data quality management). PDF
ГОСТ Р ИСО/МЭК 11179‑4 (термины метаданных и принципы определения элементов данных). PDF
Кодекс этики в сфере искусственного интеллекта (общие этические принципы и стандарты поведения). PDF (a-ai.ru)

Авторитетные индустриальные и международные рамки

DAMA-DMBOK (Data Management Body of Knowledge) — набор принципов и практик управления данными. dama.org
NIST AI RMF 1.0 — рамка управления рисками ИИ (GOVERN/MAP/MEASURE/MANAGE). PDF
WCAG 2.2 (W3C Recommendation) — рекомендации по доступности веб-контента. w3.org
ISO/IEC 23894:2023 — guidance по risk management для ИИ. gostinfo.ru
CRISP-DM — классическая модель жизненного цикла проектов data mining/DS (6 фаз). PDF
ISO/IEC 38505-1 (governance of data) — принципы governance данных в контуре IT-governance. iso.org

SEO и доступность (для этой страницы как HTML-продукта)

Яндекс.Вебмастер: рекомендации по meta description (уникальность, соответствие содержанию, язык, отсутствие «переспама»). yandex.ru
ГОСТ Р 52872‑2019: принципы воспринимаемости, управляемости, понятности и надёжности — как основа доступности цифрового контента. tiflocentre.ru

Templates / Checklists #

Ниже — набор шаблонов, которые можно прямо копировать в Confluence/Notion/Docs. Они сделаны так, чтобы руководитель мог внедрить «минимальный каркас» качества и управляемости.

Шаблон: бриф на аналитический запрос (intake)

Название запроса:
Инициатор / стейкхолдер:
Дата / дедлайн (желательно — окно времени, не точный час):
Тип запроса: [инсайт / метрики / эксперимент / витрина / дашборд / консультация / аудит качества]

1) Решение, которое будет принято по результату
- Что именно изменится, если вывод A? Если вывод B?

2) Цель (бизнес-результат)
- Какая North Star метрика и зачем?
- Какие guardrails (качество, риск, комплаенс, UX)?

3) Контекст и ограничения
- Что уже пробовали/знаем?
- Какие сегменты/периоды важны?
- Какие юридические/этические ограничения есть (ПДн/доступы)?

4) Данные
- Источники (таблицы/события/BI)
- Уровень доверия к данным и известные проблемы

5) Критерий готовности (Definition of Done)
- Формат результата: [записка / дашборд / PR в витрину / отчёт эксперимента]
- Как будет проведена проверка качества?
- Кому и как будет презентовано?

Шаблон: план эксперимента

Эксперимент:
Гипотеза:
Primary metric:
Guardrails:
Минимально значимый эффект (MDE):
Дизайн: [A/B / multi-variant / switchback / geo / quasi-experiment]
Единица рандомизации:
Период:
Критерии остановки:
Риски (технические/продуктовые/этические):
План анализа:
- p-value / CI / power
- корректировки множественных проверок (если есть)
- обработка выбросов (симметрично!)
План внедрения и пост-контроля:
- как измерим эффект после раскатки?
- что считаем регрессом?

Чек-лист качества для аналитического артефакта (записка/дашборд/витрина)

[ ] Понятна цель и решение, которое будет принято
[ ] Определены метрики и их формулы (фиксированы определения)
[ ] Указаны периоды, сегменты, фильтры, исключения
[ ] Источники данных перечислены и доступны по правам
[ ] Есть sanity-check: сравнение с ожидаемыми диапазонами / предыдущими периодами
[ ] Учтены смещения: выборка, сезонность, изменения трекинга, изменения бизнес-правил
[ ] Если есть статистика: указаны α, power/CI, размер эффекта, ограничения интерпретации
[ ] Рекомендация отделена от факта (что видно в данных vs что предлагается)
[ ] Есть план действий / next steps и владелец внедрения
[ ] Документация и версия сохранены (ссылка на код/запрос/дашборд)

Шаблон: RACI для data governance

Объект: [метрика / витрина / домен данных / справочник]
Data Owner (A):            [кто отвечает за бизнес-смысл и цель]
Data Steward (R):          [кто ведёт определения/качество/процессы]
Engineering Owner (R):     [кто отвечает за пайплайн/инфру]
Security/Compliance (C):   [кто консультирует по ПДн/ИБ]
Consumers (I):             [кто должен быть уведомлён об изменениях]

Изменения:
- Как принимаются (RFC/PR/комитет)?
- Как уведомляются (changelog/релиз-ноты)?
- Как тестируются (DQ checks/мониторинг)?
SLA/SLO:
- Доступность (дашборды/метрики)
- Свежесть данных
- Доля ошибок/дефектов
- Время реакции на инциденты

Шаблон: еженедельный отчёт руководителя аналитики (1 страница)

Неделя:
1) Главное влияние (impact)
- Решения, принятые на данных (2–5 пунктов)
- Измеримый эффект / статус (если рано — что будет считаться эффектом)

2) Состояние аналитической системы
- Инциденты данных/дашбордов: кол-во, критичность, RCA, профилактика
- SLA/SLO: свежесть, доступность, дефекты

3) Портфель работ (Run/Change/Build)
- Что завершили
- Что в работе (WIP)
- Что заблокировано и чем помочь

4) Команда
- Найм/онбординг
- Сильные достижения
- Риски выгорания/перегруза

5) Следующая неделя (фокус)

↑ вверх