Full stack Data analyst

    "Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.


    Типичный цикл работы по аналитической задаче выглядит так:


    1. Бизнес приходит с проблемой и просит получить ответ.
    2. Аналитики обсуждают с бизнесом, что надо сделать.
    3. Аналитики поняли, что от них хочет бизнес и понимают, что им примерно нужно в данных.
    4. Аналитики пишут запрос в DWH, чтобы получить данные.
    5. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
    6. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
    7. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
    8. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
    9. Повторяем п. 7 и п.8

    Однажды ребята из DWH говорят, что не могут дать данных или не готовы обрабатывать столько запросов от аналитиков. В ответ аналитики начинают копить свои данные в стороне от DWH в каких-то эксельках. Там же они начинают собирать свои ETL процессы, как умеют, на основе того, что они могут получить от DWH “без боя”.


    Что мы имеем в итоге:


    1. DWH неадекватно покрывает потребности потребителей (ну со стороны DWH выглядит так, что пользователи не знают, что хотят).
    2. Аналитики начинают писать плохие ETL процессы и создают псевдо DWH по своим объемом данных, но без резерва, управлением доступа, с низкой производительностью и т.п.
    3. Взаимодействие DWH и аналитиков страдает, т.к. Одним “плевать” на бизнес смысл, а вторым не комильфо понимать “птичий язык”.
    4. Процесс получения ответа на вопрос бизнеса затягивается, ведь теперь процесс обработки данных — это куча ручной работы за рамками DWH. А зачем мы строили DWH, разве не для того чтобы было одно хранилище?
    5. Мелкие изменения в постановке задачи от бизнеса запускает цикл анализа данных почти с нуля, т.к. DWH вновь не проявит гибкость, а у аналитиков не окажется данных в новом разрезе.

    Какое может быть решение? Если вы хотите избавится от проблемы взаимодействия DWH и аналитиков, то вы должны сблизить компетенции DWH и аналитиков. Человек, кто совмещает эти компетенции и можно назвать аналитиком данных.


    Что же должен уметь такой Full Stack Data Analyst?


    1. Работать с источниками данных в сыром виде, понимает, как устроено хранение данных.
    2. Сформулировать, что нужно изменить в хранилище в смысле содержания данных, какие данные добавить и как их методологически обрабатывать, чтобы hardcore разработчики DWH могли это имплементировать.
    3. Понять потребности бизнеса, обсудить требования и помочь своему заказчику, внутреннему или внешнему сформулировать проблему и решение к ней.
    4. Уметь дизайнить аналитическое решение, т.е. понять, как решать задачу, какие нужны данные, какие надо “придумать”, какие надо сделать допущения
    5. Уметь визуализировать свои результаты и докладывать своим заказчикам (внутренним или внешним)
    6. Уметь сделать “воспроизводимое” исследование, это такой анализ, который всегда можно повторить на тех же данных и получить тот же результат. Для этого нужно уметь работать с R/python или системами, которые позволяет формализовать процесс анализа.

    Если вы совмещаете в одном аналитике технические и аналитические компетенции, то вы получаете действительно цельного сотрудника, кто может решить проблему end-to-end. И это очень важно для аналитических задач, т.к. только у этого аналитика и есть понимание, что он делает и почему. Разделение же на тех, кто “анализирует” и тех, кто “обрабатывает данные” приводит к тому, что каждый из этих сотрудников как инвалид: аналитик как без рук, т.к. ничего не умеет получить и обработать в масштабе, а инженер данных как бы “без мозгов”, т.к. не думает, как это будет использоваться и какие есть гипотезы.


    Разделение труда очень важно, но оно должно проходить несколько в иной плоскости. Аналитик должен уметь получить все что ему нужно для анализа, а задача же Data Engineer построить системы, которые эффективно предоставляют данные в любых возможно интересных для аналитика данных разрезах. Для Data Engineer это означает, что данные должны хранится в достаточно гибком виде, но при этом в удобном для использования: частично денормализованные, частично с доступами через кубы, частично предварительно агрегированные и предрассчитанные.


    И уж если вы не можете найти для себя Full Stack Analyst, то хотя бы включите в состав команды аналитиков Data Engeneer, чтобы компетенция по работе с данными не была вынесена из анализа во внешнюю службу.


    Не дело аналитика данных поддерживать получение данных из API google adwords, но и не дело Data Engeneer писать селект, чтобы получить данные по выручке за прошлый месяц.

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 7

      0
      Как вариант решения при таком не отзывчивом отделе DWH можно посадить аналитика и программиста DWH за соседние столы.
        0
        А вы не думали, что у вас весь процесс не верный?
        Что аналитик должны не ad-hoc заниматься, а заниматься требованиями, а DWH в совокупе с BI должны выдать просто инструмент для бизнеса?
          0
          Не столько у нас, сколько это часто так работает в компаниях.
          Но аналитические вопросы реально распадаются на 2 типа: adhoc и регулярные отчеты. Классическая связка бизнес-аналитик + разработка более менее нормально заходит на регулярных отчетах. Правда до тех пор, пока у вас в понятие отчета не попадают АБ тесты, кластеризация, churn prediction и прочие data science штуки. Ad hoc это те задачи, в которых не требуется регулярная воспроизводимость или которые вообще не вписываются в BI, как в формат.
          0
          Какое может быть решение? Если вы хотите избавится от проблемы взаимодействия DWH и аналитиков, то вы должны сблизить компетенции DWH и аналитиков. Человек, кто совмещает эти компетенции и можно назвать аналитиком данных.

          Возможно проблема не в компетенциях рядовых сотрудников а в плохом взаимодействии.
          Тогда решать надо не добавлением еще одного более хорошего сотрудника а разбираться с менеджерскими компетенциями руководителей аналитиков и разрабов и с мотивированием их на более продуктивное взаимодействие.
            0
            Коммуникации — это дорогая штука, как показывает практика, на нее тратится куча времени, до 30-50% времени от рабочего. И она почти по дефолту у всех как-то хромает. Так что налаживать коммуникации так же сложно, а может и сложнее, чем повысить профессиональные компетенции. Я же топлю за то, чтобы задачей на аналитику данных владел один человек end-to-end, понимал как он ее делает, где и как берет данные, какие предпосылки использует, и как отдает пользователю.
              0
              Тут скорее вопрос в переключении между задачами.
              Программист получает задачу от аналитика, решает её, аналитик начинает пользоваться инструментом и тут не хватает каких-то данных. Аналитик обращается к программисту, а тот уже начал другую задачу и либо придётся аналитику ждать, либо вторая задача пострадает.

              Если же аналитик сам себе программист, доработки конвеера данных органично вплетаются в его задачу (там даже и доводить до решения с интерфейсом не нужно, достаточно пописать SQL/MDX)
                0

                На мой взгляд такое взаимодействие, иногда, добавляет слишком много накладных расходов.


                Возьмём задачу ежемесячной отчётности, у условных аналитиков есть срок "когда они должны выдать результат" пусть это, к примеру 23:59:59 n-го рабочего дня.
                У разработчиков/поддержки же есть текущие задачи/sla и тут на n-2 дне вдруг выясняется что витрина, на разработку которой потрачен человекомесяц и которая исправно работала пол года, выдаёт не то и нужно срочно что-то делать. :)
                ИМХО лучшее что я видел это когда люди и в бизнесе(аналитик) и в ИТ(базы данных) понимают, худший вариант это когда по требованиям ИБ на рабочей станции сотрудника работающего с финансовой информацией клиентов не должно быть установлено средств разработки (sql developer — да нельзя же), при этом, по моему, важно чтобы у сотрудников хватало времени на перевод быстрых решений(костылей) в регламентный etl.

              Only users with full accounts can post comments. Log in, please.