Les 12 défis d'un P.O. Data

En tant que Product Owners, nous sommes impactés par les spécificités de nos environnements techniques et fonctionnels. Voici un retour d'expérience sur les défis que j'ai rencontrés lors de mes missions sur des produits et environnements liés à la Data !

Le produit Data

I. Comment le définir ?

On peut considérer qu'on a un produit Data à partir du moment où on dispose d'un ensemble de données. Ces données sont typiquement stockées dans des structures telles que :

• datalake
• flux
• data warehouse

Lorsqu'une organisation est de taille assez importante pour avoir plusieurs PO Data, il existe plusieurs façons de définir les différents produits Data qui leur seront attribués :

• Périmètres fonctionnels : ils se distingueront par les types de données contenues ou par les usages métiers qui en sont faits. Exemples : données CRM, données financières, usages RH, …
• Périmètres par couches : socle, plateforme, BI, …

Outre les données elles-mêmes, les différents moyens de mise à disposition sont à considérer comme faisant partie du produit Data. Une même donnée peut, par ailleurs, être mise à disposition via plusieurs canaux. Exemples :

• requêtes en bases de données,
• dashboards,
• flux d'envoi externe.

Contraintes techniques

II. Dépendance aux sources

La disponibilité des sources de données et leur qualité peuvent avoir de gros impacts sur la capacité du PO à répondre aux besoins exprimés par les parties prenantes. En effet, il sera difficile de se projeter et d'annoncer des délais de réalisation tant qu'on n'a pas les données entre les mains.

D'autre part, le format des sources sera structurant pour l'architecture de la solution technique. On observera souvent une organisation des données en silos par source.

Solution : l'accompagnement par le tech lead / architecte est souvent une nécessité lors des échanges avec l'équipe en charge des données sources. Les contraintes fonctionnelles et techniques sont entremêlées, et le PO risque de ne pas parvenir à toutes les identifier lors de l'expression des besoins.

III. Données hétérogènes

Parmi les missions du Product Owner, il y a le fait d'établir clairement une vision et un objectif produit. Or, notre produit Data peut se révéler être un agglomérat de données relativement hétérogènes.

IV. Gouvernance

Normes de sécurité, directives et pratiques propres à l'entreprise, législation. Normalement dévolu au DPO (Data Protection Officer), mais en l'absence de ce dernier, le Product Owner doit avoir ces contraintes en tête.

V. Obsolescence programmée

La valeur de la donnée peut dépendre de sa "fraîcheur". Il faudra considérer les deux notions suivantes :

• délai de mise à disposition,
• fréquence de rafraîchissement.

Il faudra faire comprendre aux utilisateurs que leurs besoins doivent être précisément exprimés à ce niveau. Les conséquences sur la stratégie d'implémentation technique peuvent être grandement impactées.

Corollaire : il faudra savoir identifier la profondeur d'historique à conserver, à la fois pour des raisons légales et pour les usages identifiés. Un travail de gouvernance est nécessaire pour s'assurer de ne pas conserver plus de données anciennes que nécessaire, pour des raisons d'économie, de législation et de "propreté" des données.

Les utilisateurs

VI. Multiples canaux d'accès

Comme dit précédemment, une donnée peut avoir un certain nombre d'usages différents en fonction des contextes et des personnes. Pour identifier et différencier ces cas d'usage, on fait appel au concept de "persona", c'est-à-dire un archétype d'utilisateur qui permet de caractériser un groupe et ses besoins.

Typiquement, on observera les associations persona et type d'accès suivantes :

• data analyst/scientist : requêtes SQL, code Python,
• équipe business : dashboard interactif,
• dirigeant : dashboard KPI,
• application consommatrice (ex : envoi dans une file de messages).

VII. Particularités des utilisateurs

Contrairement à une application web ou mobile, notre utilisateur est la plupart du temps interne à l'entreprise. De ce fait, il est fréquent que l'utilisateur soit aussi le demandeur direct, supérieur hiérarchique, voire sponsor financier du produit. L'objectivité dans les négociations sur la priorisation des développements n'est pas garantie. D'autant que la synergie entre les demandes de diverses parties prenantes est parfois simplement impossible, faute d'interdépendance ou de logique commune identifiable. On sera face à une vraie concurrence. Vos seules armes : transparence, diplomatie et pédagogie !

Leurs besoins seront par ailleurs fonction de la maturité Data de l'entreprise. On pourra aborder des usages de données plus ambitieux en termes de valeur ajoutée à mesure que se baser sur la Data devient un réflexe. Mais cela peut s'accompagner d'une certaine complexité.

Les utilisateurs sont parfois des applications : application front, outil métier, autre produit Data… Des utilisateurs presque comme les autres du point de vue de notre produit Data !

VIII. Leur perception du produit

Mettre à disposition un produit Data utile et performant n'est malheureusement parfois pas suffisant ! Un travail de promotion et de pédagogie est souvent nécessaire. Il existe différents niveaux de communication qu'il faut s'assurer de couvrir :

• Visibilité : faire en sorte que l'existence du produit ou d'une fonctionnalité soit connue (par exemple, en l'annonçant en Sprint Review),
• Compréhension :
  • considérer que, sans documentation, rien n'est instinctif,
  • expliquer les opportunités d’exploitation de la donnée permettra aux utilisateurs de se projeter sur les usages ciblés mais aussi potentiels.
• Adoption :
  • comprendre les raisons d'une potentielle résistance au changement,
  • avoir conscience de la concurrence de solutions alternatives préexistantes,
  • limiter les accès aux données brutes,
  • mettre en avant l'intérêt du produit Data face au shadow IT de manière générale.

Les postures du PO Data

IX. Un produit technique

Faut-il comprendre la technique pour être Product Owner Data ?
Il faut, au minimum, être capable d'écrire et d'exécute des requêtes SQL et ne pas être effrayé par un système apparaissant complexe.

X. Un produit non visuel

Prendre en main un nouveau produit Data peut mener à une impression d'opacité et de complexité inextricables. Une certaine frustration peut en découler lors d'une montée en compétence qui peut être longue.
Mes expériences m'ont montré que cette perception tend forcément à décroître à mesure qu'on se familiarise avec notre environnement de travail.

Pour accélérer la familiarisation, je conseille de s'aider autant que possible de supports visuels, par exemple en représentant, sous forme de schémas, les données, leurs dépendances ou leur organisation.

XI. Un écosystème technique subi

Il est très fréquent que l'équipe de développement n'ait pas intégralement le choix dans ses solutions techniques. En effet, certains choix d'outils ou de solutions sont faits à l'échelle de l'entreprise. On devra composer avec l'écosystème présent et parfois abandonner une solution pourtant identifiée comme idéale.

Exemple typique : le Cloud Provider.
AWS, GCP, Azure… Il y a peu de chances d'être autorisé à utiliser les services d'un autre cloud que celui déjà utilisé dans l'entreprise.

XII. Accumulation de rôles

Un Product Owner est déjà souvent amené à cumuler les rôles de Scrum Master, manager, testeur. C'est encore plus vrai avec l'ajout de rôles propres à un environnement Data :

• Data steward : guider les utilisateurs dans les fonctionnalités, bonnes pratiques et usages potentiels des données,
• QA : tester les fonctionnalités avant leur présentation aux utilisateurs,
• Data analyst : explorer les données pour les comprendre et être capable de proposer de nouvelles fonctionnalités ou des améliorations,
• Évangéliste : promouvoir l'usage de la Data / du produit.

Récap' & Recommandations

• Accompagnement par un tech lead / architecte,
• Patience et familiarisation progressive avec l’environnement :
  • fonctionnel,
  • technique,
• Challenger les parties prenantes,
• Évangéliser : être le meilleur promoteur de son produit,
• Innover : bousculer, si nécessaire, les habitudes de l'entreprise.