Dans un article précédent sur les Data Products, nous avons défini, listé les caractéristiques fondamentales et donné des exemples de Data Products. Nous avons également abordé la nécessité de passer au product-thinking pour transformer des jeux de données en Data Products viables. Au sein de ce pivot vers une architecture de Data Mesh, il est important de souligner une facette très importante de la gestion des Data Products – leur ownership. En effet, il est crucial de désigner les bonnes personnes en tant que parties prenantes pour les Data Products de votre entreprise.
Dans cet article, nous abordons le côté humain des Data Products – le rôle, les responsabilités et les compétences requises d’un Data Product Owner.
Le rôle et les compétences clés d’un Data Product Owner
Comme son nom l’indique, le Data Product Owner est le garant du développement et du succès des Data Products au sein d’une organisation. Il agit comme un pont entre les équipes data, les parties prenantes et les utilisateurs finaux, traduisant des concepts de données complexes en informations exploitables. Pour ce faire, les Data Product Owners possèdent un ensemble de compétences techniques, comprenant la capacité à extraire des informations des données, à identifier des modèles, à comprendre des langages de programmation tels que Python ou R, et à avoir une solide base dans les technologies de données telles que les data warehouses, les bases de données, les data lakes, etc.
En plus des compétences techniques, un Data Product Owner doit posséder une grande acuité business, avec la capacité de comprendre le contexte économique, les objectifs, les tendances et le paysage général, et de développer des stratégies data alignées avec ce contexte. Ils utilisent donc les données pour la prise de décision.
Enfin, les Data Product Owners possèdent d’excellentes compétences en communication, avec la capacité de transmettre des informations sur les données aux différentes parties prenantes de l’entreprise telles que les data scientists et les développeurs, mais aussi aux rôles non techniques tels que les utilisateurs métier et les analystes. Ils ont généralement également de l’expérience dans les méthodologies agiles et des compétences en résolution de problèmes pour livrer des Data Products utiles en temps voulu.
Quelles sont les responsabilités principales d’un Data Product Owner ?
La nature multifacette d’un Data Product Owner, telle que décrite ci-dessus, lui confère diverses responsabilités. Dans Data Mesh in Action de J. Majchrzak et al., les tâches des Data Product Owners sont répertoriées comme suit :
- Définition de la vision : ils sont responsables de déterminer le but de la création d’un Data Product, de comprendre ses utilisateurs et de capturer leurs attentes à travers le prisme du product-thinking.
- Planification stratégique du développement du produit : ils sont chargés de créer une feuille de route complète pour le parcours de développement du Data Product, ainsi que de définir les indicateurs clés de performance (KPI) associés.
- Garantie de satisfaction des exigences : garantir que le Data Product répond à toutes les exigences est une responsabilité cruciale. Cela inclut une description détaillée des métadonnées et la garantie de la conformité aux normes et aux règles de gouvernance en vigueur.
- Gestion et hiérarchisation du backlog : le Data Product Owner prend des décisions tactiques concernant la gestion du backlog du Data Product. Cela implique de hiérarchiser les exigences, de les clarifier, de scinder les stories et d’approuver les éléments mis en œuvre.
- Gestion des parties prenantes : ils doivent recueillir des informations pour comprendre les attentes et clarifier les incohérences ou les exigences contradictoires afin d’assurer un alignement.
- Collaboration avec les équipes de développement : interagir avec l’équipe de développement des Data Products est essentiel pour clarifier les exigences et prendre des décisions éclairées sur les défis affectant le développement et la mise en œuvre.
- Participation à la gouvernance des données : le Data Product Owner contribue activement à la gouvernance des données, influençant l’introduction de règles au sein de l’organisation et fournissant des commentaires précieux pour leur mise en œuvre pratique.
Bien que par principe un Data Product Owner soit associé à un Data Product spécifique, un seul “owner” peut superviser plusieurs Data Products, surtout s’ils sont plus petits ou nécessitent moins d’attention. La taille et la complexité des Data Products varient, entraînant des différences dans les responsabilités spécifiques assumées par les Data Product Owners.
Quelles sont les différences entre un Data Product Owner et un Product Owner ?
La relation entre un Product Owner et un Data Product Owner peut varier en fonction de caractéristiques et d’exigences spécifiques. Alors que dans certains cas, ces rôles se chevauchent, dans d’autres, ils divergent clairement. Dans le livre Data Mesh in Action, trois scénarios différents sont distingués :
Cas 1 : Le Rôle Double
Dans ce scénario, le Data Product Owner sert également de Product Owner, et les équipes de développement pour le Data Product et le produit global sont alignées. Cette configuration est la plus adaptée lorsque le Data Product s’étend du système source, et la complexité est gérable, ne nécessitant pas d’efforts de développement distincts.
Un exemple serait un module d’achat d’abonnement fournissant des données sur les achats intégrées de manière transparente dans le système source.
Cas 2 : Double Propriété, Équipes Séparées
Ici, le Data Product Owner assume un double rôle en tant que Product Owner, mais les équipes responsables du Data product et du développement global du produit sont distinctes. Cette configuration est appliquée lorsque les données analytiques dérivées de l’application sont étendues, nécessitant un backlog distinct et une équipe spécialisée pour l’exécution.
Un exemple serait un module d’achat d’abonnement offrant des données analytiques soutenues par un modèle de machine learning (ML), permettant des prédictions de comportement d’achat.
Cas 3 : Entités Indépendantes
Dans ce scénario, les rôles du Data Product Owner et du Product Owner sont distincts, et les équipes responsables du Data Product et du développement global du produit opèrent indépendamment. Cette configuration est choisie lorsque le Data Product est une solution complexe demandant des efforts de développement indépendants.
Un exemple serait la construction d’un data mart soutenu par un modèle ML pour prédire le comportement d’achat.
Par essence, l’interaction entre les rôles de Product Owner et de Data Product Owner dépend des subtilités du Data Product et de sa relation avec le système global. Qu’ils convergent ou divergent, la configuration choisie est alignée sur les demandes spécifiques posées par la complexité et les exigences d’intégration du Data Product en question.
Conclusion
En conclusion, à mesure que les organisations adoptent la gestion des Data Products au sein d’une architecture Data Mesh, l’efficacité des Data Product Owners dédiés devient essentielle. Leur capacité à connecter les complexités techniques aux objectifs commerciaux, combinée à une compréhension approfondie des technologies de données en évolution, les positionne comme des figures centrales pour libérer tout le potentiel des Data Products d’entreprise.
