В Oda владение распределенными данными и управление общими данными являются одним из шести принципов создания ценности из данных . Этот принцип был ключом к нашему успеху в масштабировании Data & Insight от команды одной пиццы до крупной дисциплины, а также в расширении границ возможного, когда данные сталкиваются с реальными проблемами в продуктовом онлайн-пространстве. В этом посте мы углубимся в то, что мы подразумеваем под распределенным владением данными, управлением общими данными, и как мы решили эту проблему на практике.

Данные — это возможность, а не функция

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

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

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

Продуктовые команды — это новые команды данных

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

Обязанности такой команды, как Delivery, в модели распределенного владения можно свести к шести пунктам:

• Создание и предоставление данных из приложений
• Сделать данные легко доступными для себя и других
• Создавайте и запускайте конвейеры данных
• Создавайте информационные продукты и управляйте ими
• Управляйте разработкой продуктов с помощью данных
• Включите команды и людей, которых они поддерживают

Создание и предоставление данных из приложений

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

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

Сделать данные легко доступными для себя и других

Каждая команда также несет ответственность за то, чтобы их данные были доступны и совместимы для использования другими командами. Это было бы невозможно без групп разработчиков платформы, поддерживающих команды разработчиков общей инфраструктурой, инструментами и рекомендациями. В Oda мы используем Fivetran для пакетного приема транзакционных данных и Snowplow для данных о событиях из Интернета, приложений и на стороне сервера, и все данные помещаются в наше хранилище данных Snowflake. В Snowflake данные доступны другим командам, чтобы они могли запрашивать и использовать их, что делает их совместимыми с данными из других команд и доменов. Например, аналитики данных в отделе доставки отвечают за получение данных, полученных в процессе управления транспортными средствами, и настройку регулярных снимков наборов данных, которые мы хотим вести в архиве.

Чтобы обеспечить совместимость данных в нашем стеке аналитики, мы следуем общим рекомендациям по установке имен и структур данных. Таким образом, мы гарантируем, что данные из разных команд и доменов могут использоваться вместе на разных логических уровнях в Snowflake и на семантическом (исследующем) уровне в Looker.

Создавайте и запускайте конвейеры данных

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

• Отдельный канал Slack, куда они уведомляются, когда что-то не работает или ломается в их пайплайнах.
• Информационная панель затрат, где они получают обзор кредитных расходов своей воронки Snowflake и худших заданий dbt.
• #data-platform-support Канал Slack, где они могут обратиться к инженерам данных за помощью в таких задачах, как настройка производительности.

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

Управляйте разработкой продуктов с помощью данных

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

• Менеджер по продукту потратит много времени на просмотр и анализ показателей продукта команды и их влияния на бизнес-показатели. Для менеджера по доставке время загрузки маршрута и своевременная доставка являются примерами метрик, которые нужно отслеживать и понимать. Для команд, использующих те части нашего продукта, которые ориентированы на клиента, более актуальны такие показатели, как рейтинг кликов, коэффициент конверсии, глубина прокрутки и результаты последних экспериментов. Поскольку мы используем цели и ключевые результаты (OKR) для согласования стратегии с работой команды , менеджер по продукту также захочет измерять и анализировать прогресс в достижении ключевых результатов, находящихся в центре внимания, в течение периода OKR.
• Инженеры -программисты позаботятся о том, чтобы их приложения были должным образом инструментированы, и встроят флаги отслеживания и функций в каждую часть приложения и все новые функции. Это позволяет команде проводить эксперименты и постепенное развертывание, чтобы понять, когда изменения продукта не так полезны, удобны или эффективны, как мы думали, и свести к минимуму влияние ошибок и плохого кода. Они также будут внимательно следить за техническими показателями, такими как время загрузки, время простоя и среднее время восстановления, чтобы убедиться, что мы всегда продвигаем качественный код.
• UX -дизайнер будет заинтересован в объединении результатов своих качественных исследований с количественными данными о том, как на самом деле ведут себя наши клиенты. Они установят и проведут эксперименты, чтобы убедиться, что любые предположения проверены и подтверждены, и будут глубоко изучать данные о различных сегментах клиентов.
• Аналитики данных, ученые и инженеры в основном помогают упростить этот способ работы. Они будут поддерживать команду, создавая полезные информационные продукты, помогая проводить эксперименты и анализируя результаты, обучая и обучая тому, как анализировать данные, и почти всему остальному, что необходимо команде для управления разработкой продукта с использованием данных. Чтобы узнать больше о трех разных ролях и о том, что они обычно делают, ознакомьтесь с нашими тремя ролями в Data & Insight в Oda .

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

Включите команды и людей, которых они поддерживают

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

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

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

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

Подводя итог нашему примеру, Delivery отвечает за каждый аспект создания стоимости из данных в домене доставки, и это выходит далеко за рамки собственных конвейеров данных. Та же установка применяется к любой другой команде разработчиков в Oda и, по сути, является тем, что мы подразумеваем под распределенным владением.

Совместное управление: стремление к сплоченности и гармонии

Распределяя право собственности на «все данные», мы даем возможность всем нашим командам двигаться автономно и быстро. Но хотя мы ценим свободу и автономию для наших команд, мы также считаем важным согласовать некоторые аспекты нашей работы с данными. Предоставление целостного пользовательского опыта в Looker, использование одних и тех же имен для одних и тех же концепций данных и использование одних и тех же методов моделирования данных и стандартов кодирования — все это примеры того, что нам нужно решать в разных командах. В определенной степени команды способны к самоуправлению и координации, а также есть элемент внутренней власти в команде, которая является явным владельцем области данных (доставка решает, что транспортные средства называются «транспортными средствами», а не «автомобили», например).

Общие инструменты и инфраструктура

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

Общие рекомендации и лучшие практики

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

Включение и обучение

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

Наконец, стоит подчеркнуть ценность сильной дисциплины Data & Insight, когда специалисты по данным из разных команд собираются вместе, чтобы учиться, взламывать, сотрудничать, строить отношения и получать удовольствие. Имея сильное сообщество данных, легче находить общие решения общих проблем, обмениваться идеями и практиками, использовать различные подходы к сложным проблемам и объединяться для решения проблем, охватывающих несколько областей. Он также играет важную роль в профессиональном развитии многих людей, а также в привлечении и удержании талантов.

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

Если вам понравился этот пост, вы должны проверить наш блог Oda Product & Tech Medium , чтобы узнать больше. Там вы можете прочитать, как группа доставки прошла путь от нулевой аналитики до прогнозирования времени обслуживания с помощью модели машинного обучения, а также о том, как расширить сквозную науку о данных в Oda с помощью нашей платформы обработки данных .