> ## Content Index > Fetch the complete content index at: https://www.sfeir.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Les 12 défis d'un P.O. Data - URL: https://www.sfeir.dev/cloud/les-12-defis-dun-p-o-data/ - Published: 2025-01-14T09:38:32.000Z - Updated: 2025-01-14T09:46:57.000Z - Description: Être PO Data n'est pas de tout repos. Découvrez les 12 défis à relever pour être le nouvel Hercule de l'Agilité ! - Author: Haïlé DOS SANTOS - Tags: Agile, Data, Product, scrum, Cloud 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](https://www.sfeir.dev/data/historiser-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](https://www.sfeir.dev/cloud/delta-lake-sur-google-cloud-platform-gcp/) - flux - data warehouse Lorsqu'une organisation est de taille assez importante pour avoir plusieurs [PO](https://www.sfeir.dev/product/product-owner-un-role-indispensable-en-equipe/) 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. ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2025/01/data_exports.PNG) Exemples d'exploitations de données : SQL, Dashboard, Flux. ### 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**](https://www.sfeir.dev/data/a-28-ans-il-cartonne-dans-la-tech-parcours-inspirant-dun-data-scientist-passionne/) 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](https://www.sfeir.dev/data/data-build-tool/), code [Python](https://www.sfeir.dev/kesaco-python/), - **équipe business** : dashboard interactif, - **dirigeant** : dashboard KPI, - **application consommatrice** (ex : envoi dans une file de messages). ![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2025/01/data_exposition.png) Exemples d'exposition de périmètres Data via différents moyens ### 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 ! 💡 ****Maturité Data** Niveaux d'analyse et valorisation des données jusqu'au "Data Driven" : \- Descriptif : observer ce qui se produit \- Diagnostique : expliquer les liens de causes à effets \- Prédictif : anticiper ce qui devrait se produire \- Prescriptif : le cœur de métier bénéficie de la Data grâce à l'amélioration des décisions business et de l'expérience client #### 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. ![](https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfSZFM-A1P9wQeLxRWVgK1qgIIxzDq_KOqJuKZNroBcSMDFpXfK9t96khjM_fVvwCQIzqry3iPKW0LWH9Rf-KmzvgSAAPPO7_30LfSw2WulWIfL2hsaSzkDUsX8hZBAIZp9loJ2QT-sL1Wni4SwOHAG7kqJ3PMD=s2048?key=IuahcdDpwcTSjS43S9m7ng) Utilisateur du produit Data privé de documentation ![](https://lh7-rt.googleusercontent.com/slidesz/AGV_vUeRXDhcW2rEOp-ChpeYJTn-bZHrEAaG0AwgwCfbiE4jmAd_e2cd1C0Hn4CsK3_gi_h_jh-3W6qv1yVN_39cBWkSCIz5SGn8IbOgXkFD--y1otmxQdpglvYT7EQYwjqHpaqnWQ5h2R5d8bcS76werTeYrlN5tCQ=s2048?key=IuahcdDpwcTSjS43S9m7ng) L'adoption du produit : une lutte contre les résistances au changement ## 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**](https://www.sfeir.dev/data/data-build-tool/) et ne pas être effrayé par un système apparaissant complexe. 💡 ****Rappel du guide SCRUM** Le Product Owner a pour objectif de maximiser la valeur délivrée par les travaux de l'équipe. Il a la responsabilité d'identifier, clarifier et ordonner les éléments du backlog produit. ### 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](https://www.sfeir.dev/cloud/devenir-aws-authorized-instructor/), [GCP](https://www.sfeir.dev/cloud/gcp-associate-cloud-engineer-the-ultimate-guide-2/),[ Azure](https://www.sfeir.dev/cloud/comprendre-linscription-dapplication-et-lapplication-dentreprise-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.