Dans Oda, la propriété distribuée des données, la gouvernance partagée des données est l'un des six principes sur la façon dont nous créons de la valeur à partir des données . Ce principe a été la clé de notre succès pour faire évoluer Data & Insight d'une équipe de pizza à une discipline de taille, et pour repousser les limites de ce qui est possible lorsque les données rencontrent des problèmes réels dans l'espace de l'épicerie en ligne. Dans cet article, nous approfondissons ce que nous entendons par propriété distribuée des données, gouvernance partagée des données et comment nous avons résolu cela dans la pratique.

Les données sont une capacité, pas une fonction

La plupart de nos Data Analysts, Data Scientists et certains Data Engineerstravailler au sein d'équipes produit interfonctionnelles avec des ingénieurs logiciels, des chefs de produit, des concepteurs UX et des experts du domaine (comme des spécialistes de la logistique, du commerce et de la croissance) dans différentes parties de notre organisation. La colocalisation des compétences en matière de données et des problèmes de domaine n'est que la première étape - nous voulons également permettre à nos équipes de se déplacer de manière autonome et rapide pour résoudre les problèmes en cours, et c'est là que la propriété distribuée joue un rôle important. Inspirés par le concept de maillage de données, nous avons placé la majeure partie de la responsabilité des données sur les différentes équipes de produits qui s'approprient pleinement « toutes les données » dans leur domaine d'activité. Les équipes sont soutenues par des équipes de plate-forme centrales, qui fournissent des services de plate-forme et d'activation tels que l'infrastructure, les outils, les directives et la formation dont tout le monde a besoin pour travailler efficacement avec les données.

En pratique, cela signifie que chaque équipe est responsable de l'ensemble de la chaîne de valeur de la donnée dans son domaine. Cela inclut tout, depuis la production et l'ingestion de données, les pipelines de données et les produits, ainsi que des sujets tels que la littératie des données et la façon dont nous agissons sur les informations. Dans Oda, les données sont une capacité, pas une fonction. Nous n'avons pas d'équipe de données centrale qui résout « tous les problèmes de données ». Cela dépend de chaque équipe.

Dans Oda, les données sont une capacité, pas une fonction. Nous n'avons pas d'équipe de données centrale qui résout « tous les problèmes de données ». Cela dépend de chaque équipe.

Les équipes produit sont les nouvelles équipes data

Dans les sections suivantes, nous utiliserons l'équipe de livraison comme exemple du fonctionnement de la propriété distribuée. L'équipe fait partie de notre mission de fournir l'expérience de livraison la plus sans souci au monde, et nous avons des analystes de données travaillant aux côtés d'ingénieurs logiciels, d'un chef de produit, de concepteurs et de spécialistes de la distribution pour y parvenir. L'équipe est responsable de choses telles que la gestion des véhicules, la dotation en personnel des itinéraires et les retours des clients, et elle construit et exploite la technologie et les applications qui prennent en charge ces processus.

Les responsabilités d'une équipe comme Delivery dans le modèle de propriété distribuée peuvent être résumées en six points :

• Produire et exposer des données à partir d'applications
• Rendre les données facilement accessibles pour eux-mêmes et pour les autres
• Créer et exécuter des pipelines de données
• Créer et gérer des produits de données
• Pilotez le développement de produits grâce aux données
• Habiliter les équipes et les personnes qu'ils soutiennent

Produire et exposer des données à partir d'applications

Les sources de données les plus importantes pour l'équipe de livraison sont les applications qu'elle crée et exécute. Par exemple, l'application mobile que les chauffeurs utilisent lors de leurs livraisons et l'application que le bureau de répartition utilise pour planifier, surveiller et aider les chauffeurs sur les itinéraires. En créant et en exécutant leurs propres sources de données, l'équipe a un contrôle total sur quoi, comment et quand les données sont générées. Les analystes de données travailleront avec les ingénieurs logiciels pour s'assurer que les bonnes données sont stockées dans le bon format dans les systèmes sources et que les données d'événement pertinentes sont suivies dans les applications. Il s'agit d'un « virage à gauche » sur les données pour les équipes produit : les données font partie de chaque étape du processus de conception et de construction au lieu d'être une réflexion après coup. Les problèmes de qualité des données sont étouffés dans l'œuf au lieu de s'accumuler au bas de l'arriéré.

Il s'agit d'un « virage à gauche » sur les données pour les équipes produit : les données font partie de chaque étape du processus de conception et de construction au lieu d'être une réflexion après coup. Les problèmes de qualité des données sont étouffés dans l'œuf au lieu de s'accumuler au bas de l'arriéré.

Rendre les données facilement accessibles pour eux-mêmes et pour les autres

Chaque équipe est également responsable de rendre ses données disponibles et interopérables pour que d'autres équipes puissent les utiliser. Cela ne serait pas possible sans les équipes de plate-forme soutenant les équipes de produit avec une infrastructure, des outils et des directives partagés. Dans Oda, nous utilisons Fivetran pour l'ingestion par lots de données transactionnelles et Snowplow pour les données d'événements provenant du Web, des applications et du côté serveur, et toutes les données arrivent dans notre entrepôt de données, Snowflake. Dans Snowflake, les données sont mises à la disposition des autres équipes pour les interroger et les exploiter, ce qui les rend interopérables avec les données d'autres équipes et domaines. Par exemple, les analystes de données en livraison sont chargés d'extraire les données produites dans le processus de gestion des véhicules et de créer des instantanés réguliers des ensembles de données dont nous voulons conserver un historique.

Pour nous assurer que les données sont interopérables dans l'ensemble de notre pile d'insights, nous suivons des directives communes sur la façon de définir les noms et les structures de données. De cette façon, nous nous assurons que les données de différentes équipes et domaines peuvent être utilisées ensemble dans différentes couches logiques dans Snowflake et dans la couche sémantique (exploration) dans Looker.

Créer et exécuter des pipelines de données

Les données brutes sont très rarement fournies sous la forme et le contexte dont nous avons besoin à des fins d'analyse. Ainsi, une partie importante du travail de nos analystes de données, scientifiques et ingénieurs consiste à créer des transformations de données et des transformations en chaîne dans des pipelines programmés pour s'exécuter à intervalles réguliers. Nous utilisons dbt pour transformer les données en format de schéma en étoile et en vastes ensembles de données qui sont utilisés pour l'informatique décisionnelle, l'analyse ad hoc et l'entrée dans les modèles d'apprentissage automatique. Nos équipes de plate-forme s'assurent que chaque équipe dispose des outils, de la formation et du support dont elle a besoin pour gérer chaque aspect de ses pipelines de données. Quelques exemples de choses auxquelles toutes les équipes ont accès :

• Canal Slack séparé où ils sont avertis lorsque quelque chose est éteint ou cassé dans leurs pipelines.
• Tableau de bord des coûts où ils obtiennent un aperçu des dépenses de crédit Snowflake de leurs pipelines et des travaux dbt les moins performants.
• #data-platform-support Canal Slack où ils peuvent contacter les ingénieurs de données pour obtenir de l'aide sur des tâches telles que le réglage des performances.

Les analystes de données en livraison sont dans une position unique pour comprendre comment les données peuvent avoir un impact dans le domaine de la livraison, et ils ont les compétences nécessaires pour créer les produits de données qui répondent aux besoins et opportunités spécifiques du domaine de livraison. Nous ferons une plongée approfondie sur les produits de données dans un article de suivi, mais pour l'instant, disons qu'un produit de données peut être n'importe quoi, d'un magasin de données dans Snowflake, une exploration Looker, à un modèle d'apprentissage automatique, et bien d'autres choses dans entre. Le point principal est que l'équipe assume l'entière responsabilité de la découverte, de la construction, de l'exécution et de la gestion des bons produits de données, du jardinage du portefeuille de produits de données et de la garantie que les produits de données sont correctement mis en œuvre et opérationnalisés.

Pilotez le développement de produits grâce aux données

Dans toute équipe produit performante, les données seront au premier plan lors de la découverte, de la création et de la gestion de produits de qualité. Avoir les bonnes données et les bons produits de données ne représente qu'une petite partie de ce qu'il faut pour fonctionner à ce niveau. Il est tout aussi important de disposer des compétences, de la culture, des cadres, des mesures et de la méthode de travail appropriés. Cela signifiera différentes choses pour les différents rôles dans chaque équipe :

• Le chef de produit passera beaucoup de temps à examiner et à analyser les métriques de produit de l'équipe et leur impact sur les métriques commerciales. Pour un chef de produit en livraison, le temps de chargement de l'itinéraire et les livraisons à temps sont des exemples de mesures à suivre et à comprendre. Pour les équipes qui s'appuient sur les parties de notre produit destinées aux clients, des mesures telles que les taux de clics, les taux de conversion, la profondeur de défilement et les résultats des dernières expériences sont plus pertinentes. Étant donné que nous utilisons des objectifs et des résultats clés (OKR) pour aligner la stratégie sur l'exécution de l'équipe , le chef de produit voudra également mesurer et analyser les progrès vers les résultats clés ciblés au cours d'une période d'OKR.
• Les ingénieurs logiciels s'assureront que leurs applications sont correctement instrumentées et intégreront des indicateurs de suivi et de fonctionnalité dans chaque partie de l'application et toutes les nouvelles fonctionnalités. Cela permet à l'équipe d'effectuer des expériences et des déploiements progressifs pour comprendre quand les modifications du produit ne sont pas aussi utiles, utilisables ou efficaces que nous le pensions, et pour minimiser l'impact des bogues et du mauvais code. Ils surveilleront également de près les mesures techniques telles que le temps de chargement, les temps d'arrêt et le temps moyen de récupération pour s'assurer que nous poussons toujours un code de qualité.
• Le concepteur UX sera intéressé à combiner les enseignements tirés de ses recherches qualitatives avec des données quantitatives sur le comportement réel de nos clients. Ils mettront en place et exécuteront des expériences pour s'assurer que toutes les hypothèses sont testées et validées, et ils approfondiront les données sur différents segments de clientèle.
• Les analystes de données, les scientifiques et les ingénieurs sont principalement là pour aider à faciliter cette façon de travailler. Ils soutiendront l'équipe en créant des produits de données utiles, en aidant à mettre en place des expériences et à analyser les résultats, en encadrant et en formant sur la façon d'analyser les données, et à peu près tout ce dont l'équipe a besoin pour piloter le développement de produits avec des données. Pour en savoir plus sur les trois rôles différents et ce qu'ils font généralement, consultez nos trois rôles dans Data & Insight chez Oda .

Il est important de noter que même si l'analyste de données, les scientifiques et les ingénieurs sont les « professionnels des données » de l'équipe, la propriété des données distribuées est une responsabilité d'équipe et non quelque chose qui ne concerne que des parties de l'équipe.

Habiliter les équipes et les personnes qu'ils soutiennent

Un autre de nos principes est de valoriser l'habilitation plutôt que les transferts . Dans notre exemple, cela signifie que l'équipe de livraison travaillera pour favoriser la littératie des données, améliorer les compétences de ses collègues sur les sujets, les outils et la méthodologie des données, et leur donner le mentorat et l'encadrement dont ils ont besoin pour être autonomes et capables de résoudre la plupart de leurs propres problèmes. problèmes au jour le jour. Bon nombre de nos équipes de produits, y compris la livraison, sont également chargées de soutenir les équipes opérationnelles. Par conséquent, les collègues ne sont pas seulement des membres de leur propre équipe, mais aussi des personnes responsables de la gestion des chauffeurs, du contrôle de la cour, etc.

Dans une certaine mesure, les lacunes en matière de littératie et de compétence en matière de données peuvent être compensées en fournissant des produits de données plus raffinés : tout le monde n'est pas en mesure de créer le tableau de bord dont il a besoin, puis un analyste de données peut le créer pour lui. Le défi consiste à trouver un équilibre entre qui et combien activer et quoi et combien construire. Idéalement, nos analystes de données, scientifiques et ingénieurs passent la plupart de leur temps sur les tâches à fort effet de levier qui nécessitent vraiment l'ensemble de leurs compétences spécialisées et moins sur des tâches qui, avec une certaine habilitation, pourraient être effectuées par d'autres. Dans tous les cas, et quelle que soit la personne qui construit ces tableaux de bord, l'équipe est chargée de s'assurer que les domaines qu'elle prend en charge ont une structure de tableau de bord bien définie, cohérente et holistique. responsabilité de l'équipe.

Idéalement, nos analystes de données, scientifiques et ingénieurs passent la plupart de leur temps sur les tâches à fort effet de levier qui nécessitent vraiment l'ensemble de leurs compétences spécialisées et moins sur des tâches qui, avec une certaine habilitation, pourraient être effectuées par d'autres.

L'activation est également importante lors de l'opérationnalisation des modèles d'apprentissage automatique créés par nos scientifiques des données. Pour que nos opérations prennent de bonnes décisions en matière de dotation en fonction des résultats de nos modèles de prévision des ventes et de la demande, elles ont besoin d'une bonne compréhension des mécanismes sous-jacents et des intrants, hypothèses, forces et faiblesses des modèles.

Pour résumer notre exemple, Delivery est responsable de tous les aspects de la création de valeur à partir des données dans le domaine de livraison, et cela va bien au-delà de la gestion de ses propres pipelines de données. La même configuration s'applique à toutes les autres équipes produit d'Oda et correspond essentiellement à ce que nous entendons par propriété distribuée.

Gouvernance partagée : résoudre pour la cohésion et l'harmonie

En répartissant la propriété de « toutes les données », nous donnons à toutes nos équipes les moyens d'agir de manière autonome et rapide. Mais si nous valorisons la liberté et l'autonomie de nos équipes, nous pensons également qu'il est important de s'aligner sur certains aspects de notre pratique data. Offrir une expérience utilisateur holistique dans Looker, utiliser les mêmes noms pour les mêmes concepts de données et utiliser les mêmes techniques de modélisation des données et normes de codage sont autant d'exemples de choses que nous devons résoudre au sein des équipes. Dans une certaine mesure, les équipes sont capables de s'auto-gouverner et de se coordonner, et il existe également un élément d'autorité intrinsèque dans une équipe étant le propriétaire incontesté d'un domaine de données (la livraison décide que les véhicules sont appelés "véhicules" et non "voitures", par exemple).

Outils et infrastructure partagés

Il existe de nombreuses bonnes raisons de s'aligner sur un outillage commun pour des travaux similaires à effectuer. Il y a généralement des frais généraux dans l'achat et la gestion des outils, car ils nécessitent souvent des compétences spécialisées pour être intégrés, exploités et utilisés. Le coût marginal de l'ajout d'utilisateurs ou de cas d'utilisation à un outil existant est souvent inférieur à l'achat d'un nouvel outil, et les outils communs permettent également la mobilité interne. Chez Oda, c'est une partie importante du mandat de nos équipes de plate-forme de données de comprendre les besoins d'outillage communs à travers l'organisation, et d'acheter, de construire, d'intégrer et d'exploiter les outils qui couvrent ces besoins.

Lignes directrices et meilleures pratiques partagées

Le fait d'avoir des directives et des meilleures pratiques documentées sur la façon d'effectuer des tâches similaires entre les équipes nous aide à réduire la complexité technique, à améliorer l'interopérabilité et l'expérience utilisateur, et à réduire les obstacles à la mobilité interne. Des exemples de cela pourraient être les conventions de dénomination, les normes de codage, les pratiques de gestion des données historiques et les palettes de couleurs standard à utiliser dans les tableaux de bord.

Habilitation et formation

En fournissant la formation fondamentale sur nos outils et concepts de données, nous nous assurons que nos outils, méthodes et meilleures pratiques sont bien compris et utilisés, et que nous avons une compréhension commune de nos concepts de données les plus importants. Nous organisons régulièrement des formations Looker, fournissons une assistance ad hoc et facilitons les communautés de pratique. À titre d'exemple de ce dernier, l'équipe de la plateforme chargée de fournir les outils d'expérimentation est également chargée de faciliter la communauté de pratique de l'expérimentation , où des personnes de toute l'organisation se réunissent pour en savoir plus sur l'expérimentation et s'entendre sur des pratiques communes.

Enfin, il convient de souligner la valeur d'avoir une solide discipline Data & Insight où les professionnels des données de différentes équipes se réunissent pour apprendre, pirater, collaborer, établir des relations et s'amuser. En disposant d'une solide communauté de données, il est plus facile de trouver des solutions communes à des problèmes communs, de croiser des idées et des pratiques, de regrouper différentes approches de problèmes complexes et de faire équipe pour résoudre des problèmes couvrant plusieurs domaines. Elle joue également un rôle important dans le développement professionnel de plusieurs et dans l'attraction et la rétention des talents.

Avec les cinq autres principes, la propriété distribuée des données, la gouvernance partagée des données joue un rôle clé dans la façon dont nous opérons et faisons évoluer notre pratique des données dans Oda et constitue, au mieux, une approche très puissante pour résoudre les données à grande échelle. À la base, il s'agit de considérer les données comme une capacité, et non comme une fonction, et de donner aux équipes de produits une grande liberté (et une grande liberté implique une grande responsabilité).

Si vous avez aimé cet article, vous devriez consulter notre blog Oda Product & Tech Medium pour en savoir plus. Vous pourrez y lire comment l'équipe de livraison est passée d'une vision nulle à la prévision du temps de service avec un modèle d'apprentissage automatique et comment renforcer la science des données de bout en bout dans Oda avec notre plate-forme de science des données .