Data-driven или data-hopeful: зачем аналитике становиться системой

В команде может быть сильный аналитик, десятки дашбордов и привычка принимать решения на данных, но это еще не значит, что аналитика в команде зрелая. Мы в Garage Eight решили разобраться, как измерить это состояние и что делать, если сильное партнерство с бизнесом уже есть, а аналитический фундамент всё еще хромает.

Меня зовут Олег Игнатов, я Head of Product Analytics в Garage Eight. В статье расскажу, как мы собрали матрицу зрелости аналитики, а затем превратили результаты оценки в планы развития. Покажу, почему партнерская модель — важный, но не финальный этап развития аналитика, и объясню, почему с распространением AI роль аналитика-владельца становится только важнее.

Предыстория: когда сильный аналитик не спасает систему

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

Но в какой-то момент мы у себя столкнулись с ограничением этой модели. У нас в периметре были продуктовые, бизнесовые и маркетинговые команды. Везде данные так или иначе влияли на решения: что развивать, как оценивать результат, куда направлять усилия, что считать успехом. 

При этом качество работы с данными в командах сильно различалось. В одной команде была понятная система метрик, но слабые процессы; в другой — хороший контакт со стейкхолдерами, но проблемы с качеством данных; в третьей — сильный аналитик, но практически всё знание находилось у него в голове. Где-то были дашборды, но доверять им было рискованно, а где-то решения по-прежнему принимались скорее «по ощущениям».

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

Так мы обнаружили проблему, с которой предстояло справиться: мы не могли объективно оценить, насколько надежен аналитический фундамент, на основе которого принимаются решения:

• Если метрика не связана с целями, она может вести не туда.

• Если данные нестабильны, команда может реагировать на шум.

• Если дашборд сделан ad hoc и никто не отвечает за его поддержку, он может стать источником ложной уверенности.

• Если процесс анализа не описан, каждый раз команда изобретает его заново.

• Если компетенции есть только у аналитика, команда не становится сильнее.

Если мы называем себя data-driven, хочется уметь показать, в каком состоянии находятся данные, метрики, дашборды и аналитические процессы конкретной команды. Если мы не можем этого сделать, возможно, мы пока скорее data-hopeful: надеемся, что данные помогают принимать решения, но не всегда управляем качеством этой помощи.

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

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

Как мы сделали состояние аналитики измеримым: матрица зрелости

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

• Метрики. Есть ли у команды понятная система метрик, связаны ли метрики с целями, используются ли они в управлении продуктом или процессом.

• Данные: качество и доверие. Понятны ли источники, есть ли владельцы, мониторинг качества и доверие к данным.

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

• Дашборды. Есть ли стандарт, семантика, поддержка, source of truth, регулярное использование.

• Компетенции. Есть ли data-мышление не только у аналитика, но и у команды, лида, владельца решения.

• Взаимодействие со стейкхолдерами. Насколько аналитика встроена в коммуникацию, приоритизацию и согласование ожиданий.

• AI. Используется ли AI точечно, регулярно, встроен ли в процессы и есть ли понимание ограничений и рисков.

Для каждого домена мы оценивали команды по шкале от 0 до 4:

• 0 — домена фактически нет. Всё хаотично или не используется.

• 1 — есть отдельные практики, но они не связаны в систему.

• 2 — есть базовая работа, понятные практики и регулярное использование.

• 3 — домен встроен в регулярное управление.

• 4 — промышленный уровень: автоматизация, владельцы, мониторинг, стандарты, регулярные циклы улучшения.

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

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

Матрица зрелости на практике: что мы узнали о наших командах 

Далее мы провели оценку текущего и целевого уровня зрелости команд. Охватили 16 команд и уже на этих данных смогли увидеть не отдельные боли, а системную картину. 

Домен

Средняя оценка

Стейкхолдеры

1,9

Метрики

1,78

Компетенции

1,67

Аналитические процессы

1,44

Данные

1,0

Дашборды

1,11

AI

0,78

Взаимодействие со стейкхолдерами оказалось на относительно хорошем уровне, а самыми слабыми стали три зоны: данные, дашборды, AI. Средний уровень по доменам по итогам первой оценки составил 1,38 из 4.

Могло показаться, что аналитика была уже достаточно зрелой: аналитики в командах были, со стейкхолдерами общались, решения обсуждали, в планировании участвовали. То есть партнерская модель в целом работала.

Но оценка показала другое: фундамент под решениями еще не был везде устойчивым: 

• У команды могло быть партнерство, но не было качественных данных.

• Могла быть включенность в обсуждения, но не было единого дерева метрик. 

• Могло быть много дашбордов, но не было стандарта поддержки и доверия. 

• Мог быть сильный аналитик, но не было системы, которая осталась бы после него.

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

3 уровня роли аналитика

Я для себя разделяю три уровня роли аналитика в команде:

1. Аналитик-исполнитель. Команда приходит с задачей. Аналитик считает. Команда принимает результат. В этой модели аналитик полезен, но включается поздно. Он отвечает за выполнение запроса, но почти не влияет на постановку вопроса.

2. Аналитик-партнер. Здесь аналитика зовут думать вместе. Не просто «посчитай», а «давай разберемся, что происходит», «какую гипотезу проверяем», «как понять, был ли эффект», «какое решение лучше принять».

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

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

Владение не значит, что аналитик отвечает за всё в одиночку. Он несет ответственность за состояние аналитики в зоне.

Аналитик-владелец может ответить:

• в каком состоянии у команды метрики;

• где есть проблемы с качеством данных;

• какие дашборды являются источником правды, а какие лучше не использовать для решений;

• какие процессы аналитики у команды есть, а какие живут только в привычках людей;

• какой следующий шаг развития самый важный;

• какие артефакты должны появиться, чтобы команда стала сильнее.

При этом, если в каждой команде есть аналитики-владельцы, это не значит, что все должны сами изобретать все стандарты, процессы и подходы. Часть вещей должна жить на уровне всей аналитической функции. У нас эту роль берет core-команда.

Она отвечает за сопровождение общего качества работы аналитики. Она помогает дополнительными ресурсами, если это нужно, и владеет тремя большими направлениями: качеством данных, экспериментами и инсайтами, а также AI. И особенно важно, что core-команда отвечает не просто за «методологию в вакууме», а за процессы и за то, как эти процессы реально работают.

TDDP: переходим от оценок к действиям

В результате опросов мы получили объективную оценку команд по матрице зрелости, текущий и целевой уровень по ключевым доменам. Кроме того, появились первые TDDP — Team Data Development Plan, план развития работы с данными в команде. По сути, это PDP или ИПР — только не для сотрудника, а для команды.

В TDDP мы фиксируем:

• какой домен развиваем;

• какой текущий уровень;

• какой целевой уровень;

• на какой период планируем изменение;

• какие действия предпринимаем;

• какие артефакты должны появиться;

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

Главное правило — не пытаться развивать все домены одновременно. Даже если проблемы есть в метриках, данных, дашбордах, процессах, AI и компетенциях, команда выбирает один, максимум два фокуса.

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

Чтобы развитие зоны не проигрывало срочным запросам, мы закладывали его в рабочее время аналитиков. Для этого договаривались с лидом, выбирали фокус и выделяли 10–15% рабочего времени. Без защищенного времени развитие аналитики быстро уступает выгрузкам, проверкам и дашбордам, которые нужны прямо сейчас.

Результат работы должен был подтверждаться конкретным артефактом. Например, деревом метрик, процессом контроля качества, распределением зон ответственности или документацией. Так развитие аналитики становилось частью регулярной работы, а не факультативной задачей на свободное время.

Наши примеры: как развитие системы встроилось в работу

TDDP помог перевести развитие аналитики в конкретные изменения. Покажу несколько примеров без названий команд:

Дашборды и ETL-процессы. Раньше дашборды могли появляться как быстрый ответ на конкретный запрос. Это было удобно в моменте, но со временем становилось непонятно, какие из них поддерживаются, на каких данных построены и можно ли использовать их при принятии решений.

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

Data Governance. Мы запустили процесс Data Governance, а три человека взяли на себя роль Data Steward. В нашей системе Data Steward занимается операционным контролем качества данных: мониторит их состояние, расследует проблемы, ведет документацию, эскалирует отклонения и работает в паре с Data Owner.

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

Изменилось и качество обсуждений. Вместо спора об отдельной цифре команды начали разбирать систему: на каком уровне дерева возникла проблема, какой драйвер изменился и что с этим делать.

Регулярный обзор метрик. В командах появились регулярные обзоры метрик. Благодаря новым показателям и более частому мониторингу резкие отклонения стали обнаруживаться быстрее. По предварительной оценке, скорость обнаружения выросла в 2–3 раза, но эту цифру нам еще предстоит проверить.

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

Кроме артефактов, из этой работы выросло и распределение ролей: 

• аналитик в команде отвечает за качество аналитики и данных в своей зоне;

• Data Steward занимается операционным контролем качества данных;

• хед аналитики отвечает за качество аналитики и данных в своей зоне — она просто очень широкая: от дивизиона до всей компании;

• core-команда помогает держать общие стандарты, процессы и практики;

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

В такой связке матрица зрелости стала рабочим инструментом.

Роль AI в матрице зрелости

AI у нас оказался самым слабым доменом — 0,78. И это, честно говоря, ожидаемо. Многие команды уже пробуют AI точечно: кто-то использует для SQL, кто-то — для ревью, кто-то — для анализа, кто-то — для документации. Но между «мы иногда используем AI» и «AI встроен в аналитический процесс с понятными ограничениями и контролем качества» — большая дистанция.

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

Ценность аналитика перестает заключаться в возможности что-то посчитать. Она в том, что специалист отвечает за качество системы: какие данные использовать, каким метрикам доверять, где риск ошибки, как проверять выводы, как встроить аналитику в принятие решений. AI делает аналитику доступнее, но именно поэтому роль владельца становится важнее.

Вместо итогов: что изменилось для наших аналитиков 

После проделанной работы у нас стали заметны шесть изменений: 

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

• Появилась системная работа над аналитикой как развитием зоны, а не только как реакцией на запросы.

• Аналитики начали закладывать 15% времени на развитие зоны. Пока что это неустоявшаяся практика, но мы работаем над тем, чтобы ввести это в привычку. Так развитие аналитики точно будет запланировано. 

• Появились конкретные артефакты: процессы работы с дашбордами и ETL, роль Data Steward, деревья метрик, регулярные обзоры метрик.

• Часть проблем стала обнаруживаться быстрее. По резким отклонениям метрик мы отмечаем ускорение обнаружения примерно в 2–3 раза. Финальную цифру еще нужно аккуратно посчитать, но направление уже видно.

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

Для нас матрица зрелости стала способом увидеть состояние этой системы. TDDP — способом управлять ее развитием. А новая роль аналитика — способом закрепить ответственность не только за отдельные задачи, но и за качество аналитики в зоне. Впереди еще большая работа, но мы знаем, в какую сторону нужно двигаться. 

Расскажите, в каком состоянии ваша система аналитики, задайте вопросы и поделитесь фидбэком — буду рад пообщаться в комментариях.