Soyons en contact

 

Le bon Product Owner est un mouton à cinq pattes

24-10-2016 - 23:2029-11-2019 - 21:04

agile, po, product owner, business, exigences, requirements

5m30s

Voilà maintenant 34 ans que je fais du logiciel. Je suis passé par beaucoup d'étapes, certaines considérées aujourd'hui comme complètement dépassées.

J'ai connu l'avènement des méthodes agiles. Comme beaucoup, j'en faisais avant qu'elles n'aient le vent en poupe, un peu comme monsieur Jourdain disait de la prose, à savoir … sans le savoir!

Cela me paraissait tout simplement naturel, et vachement plus productif que ce que j'avais l'habitude de faire dans une grande institution financière (la Générale de Banque). Nous sommes quelque part que je situe en 1988-1989.

Puis, en 2001, je me frotte à toute une série d'articles qui parlent d'eXtreme Programming (XP). Je me mets donc à étudier la matière. J'y trouve le concept de travail rapproché avec le client. Tiens donc, exactement ce qu'on faisait – sans le savoir – avec la société FastWrite et la création de la collection “Je Gère”. Mais quand même pas facile de mettre cela en oeuvre! Allez donc trouver des clients pour un produit qui n'existe pas encore ! Sont-ils enclins à vous consacrer du temps ?

De notre côté, nous avions une position finalement privilégiée : nous avions un magasin d'informatique situé au centre de Bruxelles (rue des Colonies, en face de la Générale de Banque), uniquement software. Nous en avons vu passé des clients, chacun avec ses besoins propres.

Pour sûr, nous avions en magasin tout ce qui aurait pu satisfaire le chaland, mais tout était trop compliqué, pas assez facile pour le commun des mortels. C'est de ce constat qu'est née la collection "Je Gère…" : un logiciel pour gérer des adresses (et pas plus), un pour gérer des disquettes (et pas plus), un autre pour gérer des cassettes vidéo (et pas plus), pour gérer les disques (et …), les cassettes, les recettes de cuisine, des factures, un stock, des clients et des fournisseurs, etc. Tous titres qui étaient directement ou indirectement issus des demandes des clients qui entraient dans notre magasin.

Il n'y a pas un logiciel que nous n'ayons construit que nous n'ayons utilisé nous-mêmes ! Nous étions nos propres clients et nous étions absolument tournés vers la simplicité extrême, ce qui est finalement très compliqué et ce qui nous a obligés à construire et déconstruire souvent.

Au-delà de l'activité de développement logiciel avec focalisation exclusive sur la fonctionnalité il nous fallait aussi supporter nos applis, entendez mettre au point un support technique, une hotline quoi! Ce besoin s'est manifesté très tôt dans le cas de FastWrite, en fait dès que SONY nous a acheté 10.000 "Je Gère … Mes disquettes" à offrir en bundle sur des boîtes … de disquettes : SONY n'avait pas l'intention d'organiser le support technique que diable! Mais dès avant de parler du deal commercial, les ingénieurs de chez SONY ont passé notre programme au crible. Nous étions confiants, car après tout nous utilisions nous-mêmes le logiciel pour gérer tous les softs dont nous disposions (et il y en a un paquet dans la toolbox de programmeurs) et ce programme fonctionnait à merveille. SONY n'a donc jamais eu à faire appel à notre embryon de support technique!

Ceci m'amène tout doucement au titre de ce billet, le Product Owner! Revenons-en aux années 2000 et plus tard, donc bien après la collection "Je Gère…". Après m'être frotté à XP, me voilà maintenant en contact avec DSDM et avec Scrum. Là, plutôt que d'avoir des clients, on parle de Product Owner, un représentant de toutes les personnes qui ont un intérêt au logiciel construit. Même si j'ai toujours considéré qu'avoir le client à côté de soi était idéal, et donc que les recommandations d'XP étaient désirables, il faut bien reconnaître que l'utilisateur final n'est pas le seul stakeholder dont il faut tenir compte. Dans le cas de la collection "Je Gère…" il fallait pouvoir tenir compte des besoins de SONY, des besoins de la mise en place d'un support technique parfaitement op?rationnel et efficace (et donc de la mise au point de logs qui pouvaient nous mettre sur la poste de problèmes potentiels), des besoins de la grande distribution (GB, Tandy, Colruyt, Fnac, ...) comme par exemple l'impossibilité d'entrer dans un linéaire de grande surface avec un seul produit (entendez un logiciel unique), des contraintes de fabrication et de la réalité des économies d'échelle, des coûts de promotion, de transport et de mise en place en rayons, etc.

Cela m'amène donc à dire qu'il y a bien d'autres "clients" dont il faut s'occuper. Et cela m'amène à claironner qu'il y a bien d'autres points dont il faut s'occuper que la seule fonctionnalité logicielle. Par exemple, il n'y a aucune fonctionnalité pour l'utilisateur final à mettre un code-barres sur le produit, et pourtant c'était obligatoire pour nous pour entrer dans la grande distribution. Par exemple, il n'y a aucune fonctionnalité pour l'utilisateur final à assembler nos releases en 3 ou 4 titres afin de pouvoir faire jouer les économies d'échelle, pas davantage dans la mise au point du packaging (ce qui était pourtant essentiel pour effectuer le shelf-filling de manière efficace et en accord avec les contraintes physiques de plusieurs points de distribution : GB n'avait pas les mêmes procédures que la Fnac, que Colruyt, que Tandy, ...), et les exemples sont vraiment nombreux, innombrables devrais-je dire, et encore je n'ai rien dit des décisions architecturales sans lesquelles nous n'aurions jamais pu développer du logiciel à grande échelle à cadence soutenue (nous avons mis sur le marché 29 titres en 4 ans à une équipe de maximum 5 développeurs, mais plus souvent 2 à 3): notre librairie de fonctions "Do It!", notre générateur d'écrans "The Builder", notre toolbox de développement (avec mêmes quelques petits générateurs de code pour nous aider à aller plus vite), etc., etc.

Tiens je ne résiste pas à la tentation de vous donner l'exemple d'un besoin technique essentiel - bien que cela ne nous soit pas paru essentiel lors de l'édition de nos premiers titres : la mise au point d'une base de données de messages. Cette base de données centrale à nos logiciels, sauf les tout premiers, n'apportait aucune fonctionnalité supplémentaire ou différente aux utilisateurs finaux. Pourtant nous avons vite détecté que nous reprenions les mêmes libellés et les mêmes tournures de phrase de logiciel en logiciel. C'était particulièrement dans les textes d'aide par exemple. Plutôt que d'avoir à reproduire les m?mes messages de logiciel en logiciel, de langue en langue (nos logiciels ?taient multilingues), nous avons pris la d?cision technico-architecturale d'avoir une base de donn?es centrale, laquelle ?tait mise à jour avec les nouveaux titres qui apparaissaient sur le march?. Cela nous permettait de diminuer consid?rablement l'occupation m?moire de nos applications mais encore cela nous permettait de corriger les quelques fautes d'orthographe que nous avions malheureusement laiss? ?chapper dans les titres pr?c?dents. Je me souviens d'un client qui avait appel? le support technique pour nous informer de ce qu'une typo avait disparu ! Cet exemple devrait vous amener ? r?fl?chir ?galement aux besoins techniques et architecturaux. Dans notre exemple nous avons eu un gain de performance, un avantage pour l'utilisateur ? pouvoir corriger des messages pr?c?dents, et un gain financier car plut?t que d'avoir ? faire tout retraduire de logiciel en logiciel, nous ne traduisions plus que le strict nécessaire (cela ne sonne-t-il pas comme l'?limination d'un waste au sens de Lean?)

Et alors donc, quoi, ce fameux Product Owner? Et bien le bon Product Owner doit ?tre capable de jouer avec toutes ces dimensions. Cela va bien au-del? des simples fonctionnalit?s business, cela inclut la vision op?rationnelle du logiciel ? construire et ? op?rer, ses liens avec tout un ?cosyst?me (dans notre cas les logiciels s'int?graient les uns aux autres, ils dialoguaient oserais-je dire), cela n?cessite une vision technique et architecturale, produit et entreprise- et ceci entre en conflit ouvert avec tout un pan de la litt?rature Agile, justifiant bien son apparition dans le {-BA}-, cela n?cessite d'excellentes qualit?s de gestion de projet, d'un sens aigu de l'optimisation de toute la ch?ine de valeur, un sens de l'?coute et de surveillance du march?, etc., etc.

Le bon Product Owner est vraiment un mouton ? cinq pattes, un r?le d'une importance capitale dans un monde Agile ou DevOps. Et vous savez quoi ? C'est singuli?rement plus facile quand toute l'?quipe s'y met ! Maintenant, vous faites de ce billet ce que vous voulez en faire.

? bient?t, et surtout pas de complications!


Top
Le Blog Apocryphe utilise des cookies pour sauver vos préférences et RIEN d'autre. Je vous demande de bien vouloir accepter les cookies qui sont positionnés sur mon blog et je vous promets en retour de ne RIEN laisser transparaître de votre parcours de visite, dont d'ailleurs vous me faites l'honneur. Au cas où néanmoins vous n'accepteriez pas d'utiliser les cookies, vous aurez probablement une navigation LÉGÈREMENT dégradée sur le Blog Apocryphe. Bonne visite!X