Pourquoi vouloir s'orienter vers le métier de Data Product Owner ?

Avant de devenir Data Product Owner, j’ai moi aussi envisagé d’autres rôles : data analyste, consultant, data scientist… Après 3 projets de Data Science et 2 projets de Data Engineering, j’aimerais partager mon avis sur ce rôle en donnant des exemples concrets de mon quotidien. J’espère pouvoir en éclairer certains dans leurs questionnements sur ce rôle.

Bonne lecture !

Que fait un Data Product Owner ?

Sur les projets data, le product owner est responsable de la qualité et de la livraison du produit que l’équipe construit. Qualité et Livraison ?
Concrètement, on entend par “qualité” que le produit réponde bien aux besoins des utilisateurs finaux. Pour ce qui est de la “livraison”, il s’agit de livrer le produit dans le temps et le budget imparti et avec une bonne visibilité pour le client.

Pourquoi devenir Data Product Owner

Vous voulez des responsabilités 

Chez Sicara, on aide nos clients à concevoir et développer des solutions sur-mesure pour répondre à leurs besoins. La notion de conception introduit une grande responsabilité pour le data product owner : celle de pousser son client à formaliser sa vision !

Pour votre client, vous serez responsable de la qualité du produit que vous livrez. C’est votre produit ! Voici un exemple concret de cette responsabilité.

Nous développions depuis trois mois un outil de computer vision quand nous avons appris une super nouvelle : notre outil allait être implémenté dans d’autres usines partout en France ! Notre interlocuteur nous a encouragé à continuer nos développements, mais selon nous, ce n’était pas une bonne idée.

Pourquoi ? Notre modèle était habitué à reconnaitre des éléments sur les vidéos issues d’une seule usine. Ce jour-là, l’objectif de mon client avait totalement changé : il ne fallait plus améliorer la performance de ce modèle, mais le rendre industrialisable !

Mon rôle en tant de Data Product Owner a été de placer un nouvel enjeu au centre de la discussion : le modèle devait garder un bon niveau de performance, indépendamment de l’organisation des machines de l’usine. Voici un résumé des tâches que nous devions prioriser pour atteindre cet objectif :

• Estimer le temps nécessaire à la récolte des vidéos d’autres usines et au ré-entraînement du modèle
• Repenser nos indicateurs de performance du nouveau modèle pour qu’ils reflètent la qualité de notre produit installé dans le parc industriel
• Estimer le temps nécessaire pour rendre le modèle compatible avec les infrastructures de chaque usine

Ces responsabilités, le data product owner doit être en mesure de les assumer pour apporter de la valeur à son client. Elles font la différence entre un cabinet d’experts et une équipe de développeurs en régie !

P.S. Le passage d’une phase de développement à celle de production est fascinant. Si vous voulez l’approfondir, je vous invite à lire l'article conseils d'un product owner rédigé par Nicolas Saulet !

Vous voulez développer votre culture tech

En tant que Data Product Owner, vous serez exposé à des problématiques tech différentes à chaque projet et à une panoplie d’outils pour y répondre. Ce rôle permet donc de construire un bagage solide pour continuer votre carrière dans la data.

Le choix des technologies, c’est la responsabilité du Tech Lead. Mais les data product owner doit comprendre comment les technologies répondent aux besoins des utilisateurs, et constamment maximiser cette valeur ajoutée. Je veux illustrer ce point avec un exemple de technologie ultra-performante : dbt.

dbt : un outil open source qui permet de structurer et d'automatiser des transformations de données, mais aussi leur documentation.

C’est une techno moderne que les DE rêvent de manipuler tellement elle change leur vie. Je n’en connaissais rien avant ma mission et je ne peux toujours pas l’implémenter moi-même d’ailleurs, ce n’est pas mon rôle ! Par contre, j’ai eu l’occasion de comprendre les métiers de Data Engineer et Data Anlayst dans la data factory de notre client.
J’ai dû identifier des axes d’améliorations dans leurs quotidiens et grâce à une étroite collaboration avec mon Tech Lead, je sais pourquoi dbt est la techno qui répond à ces besoins.

Voici deux exemples :

1. dbt permet de créer des fonctions en SQL réutilisables pour créer toutes les transformations. Sur la durée, c’est un gain de temps et de qualité énorme pour les data engineers !
2. dbt génère automatiquement de la documentation sur les données, et la rend accessible sur une application web. Cette documentation est cruciale pour les data analystes pour connaître les données. dbt, c’est l’assurance d’une documentation à jour et correcte !

En tant que PO, vous devrez identifier et synthétiser cette valeur pour vos clients. En faisant ça, vous développerez une vraie expertise technique qui vous servira toute votre vie professionnelle !

Vous voulez devenir un maître de la gestion de projet

C’est une compétence qui vous servira toute votre vie : l’art de mener un projet du début à la fin. Il y a évidemment plusieurs éléments à maitriser pour devenir un expert en la matière, et je ne peux pas témoigner pour tous. Un élément clé que mon rôle de Data Product Owner m’a appris, c’est d’être capable de donner un bon niveau de visibilité aux bonnes personnes.

Savoir donner la visibilité

C’est un enjeu continu du développement d’un produit data : savoir si les fonctionnalités seront développées dans les temps, connaître l’impact de bugs sur la date de livraison du produit…

Chez Sicara, on a remarqué que la visibilité était un point clé de la satisfaction de nos clients. Ça leur permet de communiquer en interne sur le produit dont ils sont responsables. Elle maintient aussi la motivation de l’équipe tout au long du projet en donnant un sentiment de progression et d’accomplissement.

Voici 3 outils qui me permettent de donner cette visibilité :

• Commencer la journée par un point d’équipe. L’ordre du jour est simple : ce qu’on a réussi et ce qui nous a bloqué la veille, les objectifs de la journée. Même en restant synthétique, ça offre une visibilité continue.

• Avoir des critères de succès clairs lors des points de synchro hebdomadaires avec le client. C’est crucial pour rationaliser les discussions sur la qualité du travail de l’équipe. Pour ça, on termine chaque semaine avec un point d’équipe. Là aussi, l’objectif est simple : s’accorder en équipe sur les développements de la semaine à venir avant de les présenter au client.
• La roadmap… Outil indispensable pour appuyer une discussion structurante sur les chantiers restants : que ce soit pour en ajouter ou re-prioriser les existants ! L'agile, ce n'est pas l'absence de plan long terme, mais l'acceptation d'un plan qui évolue !
  
  Pour illustrer ce point, reprenons l’exemple sur l’industrialisation du modèle de computer vision dont je parle plus haut. Mon rôle de Data Product Owner était de donner de la visibilité sur le travail qu’il restait à faire pour que notre produit fonctionne dans toutes les usines.
  Pour cela, j’ai placé les différents chantiers nécessaires sur une roadmap. On constatait alors visuellement (en 5 secondes) que l’équipe n’avait plus de temps à consacrer aux améliorations du modèle.
  
  La roadmap a permis de maximiser la valeur ajoutée de l’équipe en donnant de la visibilité sur un problème de priorités !

Roadmap d'un projet data

Chaque projet est différent et apporte de nouveaux challenges. C’est à chaque fois une nouvelle opportunité de perfectionner ces gestes de la gestion de projet qui vous serviront probablement toute votre carrière, data ou pas !

Bonus Sicara : vous voulez mettre en place une dynamique d’amélioration continue

Qu’est-ce que je veux dire par “amélioration continue” et pourquoi voudriez-vous mettre ça en place ? Chez Sicara, on a adopté une philosophie axée sur l'apprentissage à partir de nos erreurs et de nos expériences. Ça concerne tous les aspects d’un projet : comment standardiser les développements que l’on fait souvent pour qu’ils prennent moins de temps, comment comprendre efficacement ses utilisateurs… Grâce à elle, on améliore nos processus pour livrer rapidement des produits ultra-performants et robustes.

Ce qui m’a surpris, c’est à quel point je pouvais avoir un impact fort sur ce point. Voici quelques éléments qui me permettent d’identifier des axes d'amélioration et des solutions pratiques.

• Mesurer le travail de l’équipe chaque semaine. Premièrement, ça permet de suivre l'évolution de la vitesse de développement avec un chiffre concret. Deuxièmement, ça permet de mesurer l'impact des problèmes rapidement pour y trouver des solutions.
• Prendre du temps pour analyser les problèmes, et suivre l’impact des actions qu’on a prises. Je vous conseille vivement "Leaning to Scale at Theodo Group" si vous voulez des méthodes concrètes pour instaurer une culture d’apprentissage continue.
• Prendre du recul grâce à des points de rétrospectives d’équipe hebdomadaires. C’est une invitation explicite à la réflexion sur le travail d’équipe : “Qu’est-ce qui était bien / pas bien ? Qu’est-ce qu’on devrait commencer / arrêter ?”. C’est simple, pourtant ces discussions ouvertes sont des vecteurs de changement redoutables !

J’espère vous avoir donné des éléments pour vous projeter dans ce rôle. Je vous invite également à lire l'article Pourquoi devenir data engineer si c’est une option que vous considérez !

Si le rôle de Data Product Owner chez Sicara vous intéresse, n’hésitez pas à consulter nos offres sur notre page carrière ou à me contacter par email !