Симулейтив

📌 Вызовы в работе аналитика данных Привет! На связи Павел Беляев — автор канала Тимлидское об аналитике и ментор Симулейтив 👋🏻 На днях я писал о конвейере, который проходят данные, чтобы принести пользу. Конечно, это грубая схема, скрывающая под собой массу нюансов. Хочу немного дополнить её, описав некоторые вызовы, с которыми может столкнуться дата-аналитик в реальной работе.

1️⃣ Формулировка требований Зачастую заказчики аналитики знают о своём предмете не сильно больше, чем вы. Во всяком случае, о том, что надо измерять, чтобы понять, например, эффективность затраченных усилий. Они могут выразить интуитивное желание получить некую ясность, а вам придется помочь им облечь его в конкретные метрики и продумать, как их вычислить. Это потребует от вас некоей эмпатии, умения интервьюировать, и, конечно, знания метрик.

2️⃣ Качество данных Причин недостоверности данных много: технические, организационные, человеческие... Конвейер длинный — на каждом шагу может что-то пойти не так. Например, пользователь накосячил с вводом, отвалилось API третьестепенных данных, на которых, внезапно, завязаны расчеты, кто-то что-то закостылил, а аналитикам не сказали — всё это требует постоянного неустанного слежения за качеством данных, желательно автоматического. Поэтому полезно завести привычку ничему не доверять и постоянно всё проверять.

3️⃣ Техническая реализуемость И дело даже не в том, что далеко не все пожелания можно реализовать, а в том, что не все они заслуживают того ресурса (вашего времени), который потребуется для реализации.  Бывает, что заказчики прямо фонтанируют идеями — громкими, но сомнительными. Я не сторонник того, чтобы «обламывать» такие порывы. Но долг аналитика — выслушать, оценить, внести коррективы, которые позволят исполнить более удобное или недорогое решение.

4️⃣ Внезапные изменения в источниках Работа аналитиков сильно завязана на источниках данных: база данных, сторонние сервисы и др. Если база данных находится в ведении других команд (у разработчиков приложения, например), то нужно иметь в виду, что у них свои цели и процессы. Вы им не нужны, это они вам нужны 🙂 Из-за этого они могут просто забыть сообщить вам, что, например, у них изменилась структура таблицы, которую вы привычно тянете, или что база вовсе переезжает, причем, послезавтра. К таким орг. нестыковкам нужно быть готовыми и постоянно напоминать руководству, что переориентация на новые источники требует времени, а аналитики должны обязательно узнавать о грядущих изменениях сильно заранее.

5️⃣ Как себя проверить? Вы, как аналитик, обрабатывающий данные, тоже влияете на их качество. Проверка того, что ваша витрина выдает достоверный результат — не всегда простая задача. Особенно, если логика сложна или применяется множество источников. Часто бывает, что время на проверку результата сильно превышает время разработки SQL-запроса для его получения. Читайте в моей статье несколько советов о проверке витрин данных.

6️⃣ Как это работает?! Бывает, что встречается код, который рассчитывает какие-то метрики, но никто уже не знает, почему именно так. Кто писал — уволился, документации не оставил, а конечные пользователи не задумываются, как оно измеряется и что означает. Это не только к вопросу об обязательном документировании, но и к тому, что я писал в начале поста — потребители данных иногда слабо понимают, что за цифры они смотрят. Будьте готовы к этому, помогать пользователям разбираться в метриках — одна из задач дата-аналитика. Ну а код возможно, стоит переделать заново, но с прозрачной для всех логикой.

В общем, будни дата-аналитика — штука весёлая. И всё же, в эту сферу войти проще, чем в хардкорное программирование. Начать свой путь до оффера в аналитике можно после обучения на курсе «BI-аналитик», где я буду вашим ментором. 📈 Узнать больше о курсе 📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS