Каждая компания генерирует, обрабатывает и хранит данные. Маленькие компании пользуются excel-табличками, компании побольше – огромные хранилища данных и команды, которые их обслуживают.

«Данные – это новая нефть.» Клайв Хамби

Меня данные тоже не обошли стороной: я собираю количественную мотивацию по новой задаче, выбираю решение, опираясь на статистику, после релиза проверяю успешность фичи. За 3 года работы в Контуре я написала бессчетное количество SQL-запросов, сделала несколько дашбордов в Redash, описала десятки фронтовых и бэковых метрик в постановках и сломала свой мозг в попытках понять, как добывать данные из Касандры.

Работать с данными – это классно, но если они некачественные, то и результат работы получается такой же. И идти до результата приходится долго. Но оказывается, много проблем можно решить с помощью data governance. 

В этой статье я расскажу: что такое data governance, какие проблемы поможет решить data governance и как применить data governance на практике.

Начнем с определения

Data governance (DataGov) – это система по управлению данными, которая обеспечивает высокое качество, доступность, целостность и безопасность данных в организации.

Сразу хочу оговориться, что data governance – это масштабная, всеобъемлющая область, которая позволяет выстроить процессы и подходы работы с данными на разных уровнях. Поэтому я считаю, что каждый аналитик тоже может влиять на data-культуру и использовать подходы DataGov в масштабе своей команды и в разрезе своих задач.

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

Какие проблемы бывают с данными

1. Данных нет или их недостаточно

Раскатали фичу, но логи писать не стали. Как результат – не можем посчитать метрики и ответить на вопрос, взлетела ли фича, сложно проводить раскопки при факапах.

2. Данные есть, но они некачественные

В поляшку таблицы БД договорились писать строку в формате JSON. Волей случая разработчик поставил лишнюю кавычку и теперь в БД стали улетать невалидные JSON’ы. Получается, что данные есть, но распарсить и работать с ними проблематично.

3. Данные есть, они качественные, но их сложно достать

Команда находится в процессе переезда с MS SQL на PostgreSQL. Аналитику (мне) нужно сопоставить данные из разных СУБД. Как это сделать «красиво» – я понятия не имею. Все, что приходит в голову, – положить результаты запросов из разных источников в одну excel-табличку и колдовать. Большие объемы данных так не обработать.

4. Разночтение данных / отсутствие единого подхода

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

5. Долгий поиск данных

Аналитик может потратить 30-50% рабочего времени на поиск данных. Получается, что высокооплачиваемые специалисты тратят только половину рабочего времени на решение своих прямых задач. Это невыгодно бизнесу.

Да, в хранилище и табличках своего продукта аналитик, скорее всего, разбирается. Но лично у меня в работе всё чаще появляются сквозные интеграционные межпродуктовые задачи. И тут аналитику уже нужно лезть в чужой огород данных. Нет понимания, где их искать, поэтому приходится идти долгим путем: спросить знающего коллегу, написать в мотермост-канал продукта (подробно описать, что вам нужно достать и для каких целей), а потом ждать, пока до вашего вопроса доберется дежурный.

Это не все проблемы, которые несет в себе недостаточный уровень data-культуры. Есть еще утечка данных, нехватка железа и другие.

О data governance

После того, как мы прочувствовали всю боль, которую может причинить работа с данными, хочется дополнить приведенную выше цитату Клава Хамби:

«Данные – это новая нефть. Они могут быть такими же токсичными, если ими не управлять.»

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

Data governance состоит из 10 выделенных областей, в сторону которых можно развивать компанию/продукт. Все направления важны и нужны, но это не значит, что нужном разом прокачивать все. Эффективнее будет:

1. Понять, что из себя представляет каждое направление и зачем каждое из них нужно

2. Оценить, на каком уровне каждое направление сейчас

3. Приоритизировать направления с точки зрения трудозатрат и профита

4. Действовать!

Конечно, такая работа, даже на уровне команды, – это трудоемкий процесс, требующий компетенции и заинтересованности от всех ее членов.
Хорошая новость в том, что некоторые идеи и подходы DataGov можно начать применять уже сейчас, они помогут снять часть проблем при работе с данными.

Полезные советы

1. Лучше собирать лишние данные, чем страдать от того, что их не хватает.

2. Хорошая практика – подумать на этапе аналитики о том, какие данные и для чего хочется собирать в рамках задачи.

3. Чтобы не забыть подумать, можно зашить блок «Метрики» в шаблон постановки. Именно так сделали мы в моей команде: 

4. Полезно иметь правила по описанию данных/процессов/метрик. Важно, чтобы они были понятные и лаконичные.

5. Полезно следовать правилам и описывать данные/процессы/костыли на wiki или в других артефактах, которые создает ваша команда.

6. Полезно поддерживать единообразие в названиях. Это упрощает поиск. Например, у нас в команде есть статья о том как давать названия метрикам, которая призывает аналитика поумерить свое креативное мышление и диктует требования к названию:

7. Описывать таблички и поляшки в них можно прямо в БД, такая возможность есть во многих СУБД. Это поможет лучше ориентироваться в ваших табличках вам самим, новым членам команды и людям из других команд. Добавить описание к таблице, как правило, можно с помощью SQL-запроса.

8. Полезно фиксировать, как рассчитывался тот или иной показатель, чтобы другой человек мог это воспроизвести. Да и через какое-то время вам самим это поможет вспомнить, откуда взялись цифры.

9. Можно создать автоматический справочник, в котором будут лежать все метрики/данные. Это позволит ускорить поиск. Мы в команде реализовали его с помощью дашборда в Redash, в котором выведены все метрики, которые пишем. На дашборде есть возможность поиска по названию, выведена дата первой и последней записи по каждой метрике и есть возможность посмотреть пример записи по любой метрике. Как это выглядит:

Подведем итоги

Чтобы данные работали на нас, нужно ими управлять. Делать это можно в масштабах целой компании, а можно локально в своей команде и продукте. Системный аналитик трогает данные в своей работе, а значит, может влиять на уровень зрелости data-культуры.

Я приоткрыла дверь в дивный мир с data governance и засунула туда свой любопытный нос. Теперь я по-другому смотрю на процессы, связанные с управлением данными в своей работе, понимаю их важность, осознаю проблемы и знаю, как подобраться к их решению.

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