Em Oda, propriedade de dados distribuídos, governança de dados compartilhados é um dos seis princípios de como criamos valor a partir dos dados . Este princípio tem sido a chave para o nosso sucesso em escalar o Data & Insight de uma equipe de uma pizza para uma disciplina considerável e em ultrapassar os limites do que é possível quando os dados encontram problemas do mundo real no espaço de mercearia online. Nesta postagem, nos aprofundamos no que queremos dizer com propriedade de dados distribuídos, governança de dados compartilhados e como resolvemos isso na prática.

Dados são uma capacidade, não uma função

A maioria de nossos analistas de dados, cientistas de dados e alguns engenheiros de dadostrabalhe como parte de equipes multifuncionais de produtos com engenheiros de software, gerentes de produto, designers de UX e especialistas de domínio (como especialistas em logística, comerciais e de crescimento) em diferentes partes de nossa organização. A colocalização de habilidades de dados e problemas de domínio é apenas o primeiro passo - também queremos capacitar nossas equipes para se moverem de forma autônoma e com velocidade para resolver os problemas em mãos, e é aqui que a propriedade distribuída desempenha um papel importante. Inspirados pelo conceito de malha de dados, colocamos a maior parte da responsabilidade pelos dados nas diferentes equipes de produtos que assumem a propriedade total de “todos os dados” dentro de seu domínio de negócios. As equipes são apoiadas por equipes de plataforma central, que fornecem serviços de plataforma e capacitação, como infraestrutura, ferramentas, diretrizes e treinamento de que todos precisam para trabalhar com dados de maneira eficiente.

Na prática, isso significa que cada equipe é responsável por toda a cadeia de valor de dados em seu domínio. Isso inclui tudo, desde produção e ingestão de dados, pipelines e produtos de dados, bem como tópicos como alfabetização de dados e como agimos com base nos insights. No Oda, os dados são uma capacidade, não uma função. Não temos uma equipe central de dados que resolva “todos os problemas de dados”. Isso cabe a cada equipe.

No Oda, os dados são uma capacidade, não uma função. Não temos uma equipe central de dados que resolva “todos os problemas de dados”. Isso cabe a cada equipe.

As equipes de produtos são as novas equipes de dados

Nas próximas seções, usaremos a equipe de entrega como um exemplo de como funciona a propriedade distribuída. A equipe faz parte de nossa missão de fornecer a experiência de entrega mais despreocupada do mundo, e temos analistas de dados trabalhando ao lado de engenheiros de software, gerente de produto, designers e especialistas em distribuição para fazer isso acontecer. A equipe é responsável por coisas como gerenciamento de veículos, equipe de rota e devoluções de clientes, além de construir e operar a tecnologia e os aplicativos que dão suporte a esses processos.

As responsabilidades de uma equipe como a Delivery no modelo de propriedade distribuída podem ser resumidas em seis marcadores:

• Produzir e expor dados de aplicativos
• Tornar os dados facilmente disponíveis para si e para os outros
• Crie e execute pipelines de dados
• Crie e gerencie produtos de dados
• Impulsione o desenvolvimento de produtos com dados
• Capacite as equipes e as pessoas que estão apoiando

Produzir e expor dados de aplicativos

As fontes de dados mais importantes para a equipe de entrega são os aplicativos que eles criam e executam. Exemplos disso são o aplicativo móvel que os motoristas usam ao fazer suas entregas e o aplicativo que o escritório de despacho usa para planejar, monitorar e auxiliar os motoristas nas rotas. Ao criar e executar suas próprias fontes de dados, a equipe tem controle total sobre o que, como e quando os dados são gerados. Os analistas de dados trabalharão em conjunto com os engenheiros de software para garantir que os dados corretos sejam armazenados no formato correto nos sistemas de origem e que os dados de eventos relevantes sejam rastreados nos aplicativos. Esta é uma “mudança à esquerda” nos dados para as equipes de produto: os dados fazem parte de cada etapa do processo de design e construção, em vez de serem uma reflexão tardia. Os problemas de qualidade de dados são eliminados pela raiz, em vez de se acumularem no final da lista de pendências.

Esta é uma “mudança à esquerda” nos dados para as equipes de produto: os dados fazem parte de cada etapa do processo de design e construção, em vez de serem uma reflexão tardia. Os problemas de qualidade de dados são eliminados pela raiz, em vez de se acumularem no final da lista de pendências.

Tornar os dados facilmente disponíveis para si e para os outros

Cada equipe também é responsável por tornar seus dados disponíveis e interoperáveis ​​para uso por outras equipes. Isso não seria possível sem as equipes de plataforma apoiando as equipes de produto com infraestrutura, ferramentas e diretrizes compartilhadas. No Oda, usamos Fivetran para ingestão em lote de dados transacionais e Snowplow para dados de eventos da web, aplicativos e do lado do servidor, e todos os dados são desembarcados em nosso data warehouse, Snowflake. No Snowflake, os dados são disponibilizados para outras equipes consultarem e desenvolverem, tornando-os interoperáveis ​​com dados de outras equipes e domínios. Por exemplo, os analistas de dados na entrega são responsáveis ​​por extrair dados produzidos no processo de gerenciamento de veículos e configurar instantâneos regulares dos conjuntos de dados dos quais queremos manter um registro histórico.

Para garantir que os dados sejam interoperáveis ​​em toda a nossa pilha de insights, seguimos diretrizes compartilhadas sobre como definir nomes e estruturas de dados. Dessa forma, garantimos que os dados de diferentes equipes e domínios possam ser usados ​​juntos em diferentes camadas lógicas no Snowflake e na camada semântica (explorar) no Looker.

Crie e execute pipelines de dados

Os dados brutos raramente são fornecidos na forma e no contexto corretos de que precisamos para fins analíticos. Assim, uma parte importante do trabalho de nossos analistas de dados, cientistas e engenheiros é criar transformações de dados e transformações em cadeia em pipelines programados para execução em intervalos regulares. Usamos dbt para transformar dados em formato de esquema em estrela e conjuntos de dados amplos que são usados ​​para inteligência de negócios, análise ad hoc e entrada para modelos de aprendizado de máquina. Nossas equipes de plataforma garantem que cada equipe tenha as ferramentas, o treinamento e o suporte necessários para gerenciar todos os aspectos de seus pipelines de dados. Alguns exemplos de coisas que todas as equipes têm acesso:

• Canal Slack separado onde eles são notificados quando algo está errado ou quebrado em seus pipelines.
• Painel de custos onde eles obtêm uma visão geral dos gastos com crédito Snowflake de seus pipelines e dos trabalhos de dbt com pior desempenho.
• #data-platform-support Canal Slack onde eles podem entrar em contato com engenheiros de dados para obter assistência com tarefas como ajuste de desempenho.

Os analistas de dados na entrega estão em uma posição única para entender como os dados podem causar impacto no domínio da entrega e têm as habilidades para criar os produtos de dados que atendem às necessidades e oportunidades específicas da área de entrega. Faremos um mergulho profundo nos produtos de dados em um artigo de acompanhamento, mas, por enquanto, digamos que um produto de dados pode ser qualquer coisa, desde um data mart no Snowflake, um Looker explore, até um modelo de aprendizado de máquina e muitas coisas em entre. O ponto principal é que a equipe assume total responsabilidade pela descoberta, construção, execução e gerenciamento dos produtos de dados corretos, fazendo a jardinagem do portfólio de produtos de dados e garantindo que os produtos de dados sejam implementados e operacionalizados adequadamente.

Impulsione o desenvolvimento de produtos com dados

Em qualquer equipe de produto de alto desempenho, os dados estarão na frente e no centro ao descobrir, criar e gerenciar ótimos produtos. Ter os dados e produtos de dados corretos é apenas uma pequena parte do que é necessário para operar nesse nível. Igualmente importante é ter a competência, cultura, estruturas, métricas e maneira de trabalhar corretas. Isso significará coisas diferentes para as diferentes funções em cada equipe:

• O gerente de produto passará um tempo significativo revisando e analisando as métricas de produto da equipe e seu impacto nas métricas de negócios. Para um gerente de produto em Delivery, o tempo de carregamento da rota e as entregas no prazo são exemplos de métricas para rastrear e entender. Para equipes que desenvolvem as partes de nosso produto voltadas para o cliente, métricas como taxas de cliques, taxas de conversão, profundidade de rolagem e resultados dos experimentos mais recentes são mais relevantes. Como usamos objetivos e principais resultados (OKRs) para alinhar a estratégia com a execução da equipe , o Gerente de Produto também desejará medir e analisar o progresso em direção aos principais resultados em foco durante um período de OKR.
• Os engenheiros de software garantirão que seus aplicativos sejam devidamente instrumentados e criarão sinalizadores de recursos e rastreamento em todas as partes do aplicativo e em todos os novos recursos. Isso permite que a equipe execute experimentos e lançamentos graduais para entender quando as alterações do produto não são tão úteis, utilizáveis ​​ou eficazes quanto pensávamos que seriam e para minimizar o impacto de bugs e códigos incorretos. Eles também ficarão de olho nas métricas de tecnologia, como tempo de carregamento, tempo de inatividade e tempo médio de recuperação, para garantir que sempre enviemos código de qualidade.
• O UX Designer estará interessado em combinar aprendizados de sua pesquisa qualitativa com dados quantitativos sobre como nossos clientes estão realmente se comportando. Eles configurarão e executarão experimentos para garantir que todas as suposições sejam testadas e validadas e se aprofundarão nos dados de diferentes segmentos de clientes.
• Os Analistas de Dados, Cientistas e Engenheiros estão lá principalmente para ajudar a facilitar essa forma de trabalhar. Eles apoiarão a equipe criando produtos de dados úteis, ajudando a configurar experimentos e analisar os resultados, treinar e treinar sobre como analisar dados e praticamente tudo o mais que a equipe precisa para conduzir o desenvolvimento de produtos com dados. Para ler mais sobre as três funções diferentes e o que elas normalmente fazem, confira nossas três funções em Data & Insight na Oda .

É importante observar que, embora o Analista de Dados, os Cientistas e os Engenheiros sejam os “profissionais de dados” da equipe, a propriedade dos dados distribuídos é uma responsabilidade da equipe e não algo que diz respeito apenas a partes da equipe.

Capacite as equipes e as pessoas que estão apoiando

Outro de nossos princípios é valorizar a capacitação sobre as transferências . Em nosso exemplo, isso significa que a equipe de entrega trabalhará para impulsionar a alfabetização de dados, aprimorar seus colegas de trabalho em tópicos, ferramentas e metodologia de dados e fornecer a orientação e o treinamento de que precisam para serem autoatendidos e capazes de resolver a maioria de seus próprios problemas. problemas do dia a dia. Muitas de nossas equipes de produtos, incluindo Delivery, também são responsáveis ​​por dar suporte às equipes operacionais. Portanto, os colegas de trabalho não são apenas membros de sua própria equipe, mas também pessoas responsáveis ​​pelo gerenciamento de motoristas, controle de pátio e assim por diante.

Até certo ponto, as deficiências na alfabetização e competência em dados podem ser compensadas com o fornecimento de produtos de dados mais refinados: nem todos são capazes de criar o painel de que precisam e, em seguida, um analista de dados pode criá-lo para eles. O desafio é encontrar um equilíbrio entre quem e quanto habilitar versus o quê e quanto construir. Idealmente, nossos Analistas de Dados, Cientistas e Engenheiros passam a maior parte do tempo em tarefas de alto nível que realmente exigem todo o seu conjunto de habilidades especializadas e menos em tarefas que, com alguma capacitação, poderiam ser executadas por outros. Em todo o caso, e quem acaba por construir esses dashboards, a equipa é responsável por garantir que as áreas que suporta têm uma estrutura de dashboards bem definida, coesa e holística. responsabilidade da equipe.

Idealmente, nossos Analistas de Dados, Cientistas e Engenheiros passam a maior parte do tempo em tarefas de alto nível que realmente exigem todo o seu conjunto de habilidades especializadas e menos em tarefas que, com alguma capacitação, poderiam ser executadas por outros.

A capacitação também é importante ao operacionalizar modelos de aprendizado de máquina que nossos Cientistas de Dados criam. Para que nossas operações tomem boas decisões de pessoal com base nos resultados de nossos modelos de previsão de vendas e demanda, elas precisam de um bom entendimento dos mecanismos subjacentes e das entradas, suposições, pontos fortes e fracos dos modelos.

Para resumir nosso exemplo, a Entrega é responsável por todos os aspectos da criação de valor a partir dos dados no domínio da entrega, e isso vai muito além de executar seus próprios pipelines de dados. A mesma configuração se aplica a todas as outras equipes de produto no Oda e é, em essência, o que queremos dizer com propriedade distribuída.

Governança compartilhada: soluções para coesão e harmonia

Ao distribuir a propriedade de “todos os dados”, capacitamos todas as nossas equipes a se moverem de forma autônoma e rápida. Mas, embora valorizemos a liberdade e a autonomia de nossas equipes, também achamos importante alinhar alguns aspectos de nossa prática de dados. Fornecer uma experiência de usuário holística no Looker, usando os mesmos nomes para os mesmos conceitos de dados e usando as mesmas técnicas de modelagem de dados e padrões de codificação são exemplos de coisas que precisamos resolver entre as equipes. Até certo ponto, as equipes são capazes de se autogovernar e coordenar, e também há um elemento de autoridade intrínseca em uma equipe sendo a proprietária clara de um domínio de dados (a Entrega decide que os veículos são chamados de "veículos" e não “carros”, por exemplo).

Ferramentas e infraestrutura compartilhadas

Existem muitos bons motivos para alinhar em ferramentas comuns para trabalhos semelhantes a serem feitos. Normalmente, há alguma sobrecarga na aquisição e gerenciamento de ferramentas, pois geralmente exigem habilidades especializadas para integrar, operar e usar. O custo marginal de adicionar mais usuários ou casos de uso a uma ferramenta existente geralmente é menor do que comprar uma nova, e ferramentas comuns também atendem à mobilidade interna. Na Oda, é uma parte importante do mandato de nossas equipes de plataforma de dados entender as necessidades comuns de ferramentas em toda a organização e comprar, construir, integrar e operar as ferramentas que atendem a essas necessidades.

Diretrizes e práticas recomendadas compartilhadas

Ter diretrizes e práticas recomendadas documentadas sobre como executar tarefas semelhantes entre equipes nos ajuda a reduzir a complexidade técnica, melhorar a interoperabilidade e a experiência do usuário e diminuir a barreira para a mobilidade interna. Exemplos disso podem ser convenções de nomenclatura, padrões de codificação, práticas para lidar com dados históricos e paletas de cores padrão para usar em painéis.

Capacitação e treinamento

Ao fornecer o treinamento fundamental sobre nossos conceitos de ferramentas e dados, garantimos que nossas ferramentas, métodos e melhores práticas sejam bem compreendidos e usados, e que tenhamos um entendimento comum de nossos conceitos de dados mais importantes. Realizamos treinamentos regulares do Looker, fornecemos suporte ad hoc e facilitamos comunidades de prática. Como exemplo disso, a equipe da plataforma responsável por fornecer ferramentas de experimentação também é responsável por facilitar a comunidade de prática de experimentação , onde pessoas de toda a organização se reúnem para aprender sobre experimentação e chegar a um acordo sobre práticas comuns.

Por fim, vale destacar o valor de ter uma forte disciplina de Data & Insight, onde profissionais de dados de diferentes equipes se reúnem para aprender, hackear, colaborar, construir relacionamentos e se divertir. Por ter uma forte comunidade de dados, é mais fácil encontrar soluções comuns para problemas comuns, polinizar ideias e práticas, fazer crowdsourcing de diferentes abordagens para problemas complexos e formar equipes para resolver problemas que abrangem várias áreas. Também desempenha um papel importante no desenvolvimento profissional de muitos e na atração e retenção de talentos.

Juntamente com os outros cinco princípios, propriedade de dados distribuídos, governança de dados compartilhados desempenha um papel fundamental em como operamos e desenvolvemos nossa prática de dados em Oda e é, na melhor das hipóteses, uma abordagem muito poderosa para resolver dados em escala. Em essência, trata-se de ver os dados como um recurso, não uma função, e dar às equipes de produto grande liberdade (e com grande liberdade vem uma grande responsabilidade).

Se você gostou desta postagem, confira nosso blog Oda Product & Tech Medium para saber mais. Lá, você pode ler como a equipe de entrega passou de insight zero para prever o tempo de serviço com um modelo de aprendizado de máquina e como capacitar a ciência de dados de ponta a ponta em Oda com nossa plataforma de ciência de dados .