PO et équipe de développement, l’importance d’une bonne collaboration

Avec cet article, je souhaite illustrer à quel point la relation entre le Product Owner (PO) et l’équipe de développement est primordiale, et plus encore lorsque le PO est externe, du côté client. Les différences avec un PO interne sont nombreuses, mais parfois subtiles. Notez que je ne ferai aucune distinction entre les utilisateurs finaux internes et externes (développement d’outils internes par rapport à celui de produits logiciels) ; je pense que cela risquerait d’embrouiller les choses.

Pour tout dire, avant de cofonder Spiria en 2003, j’ai travaillé près d’une décennie sur des produits logiciels avec des PO internes, sauf qu’à l’époque, on les appelait simplement « chef de produit » ou « boss ». J’ai donc connu les deux côtés et peux offrir différentes perspectives.

Jouer dans la même équipe

Avec un PO interne, une appréciable différence est le sentiment généralement partagé que tout le monde joue dans la même équipe : c’est nous, l’équipe produit unie, contre eux, les hordes barbares qui frappent à la porte. Plus l’entreprise est petite, plus ce sentiment est important, particulièrement dans le cas de produits logiciels. Avec un PO externe, il y a souvent le danger que le « nous contre eux » se transforme en nous (le PO, le client) contre eux (l’équipe de développement, le prestataire de services).

De mon expérience de travail avec des clients externes, les projets les plus réussis ont toujours été réalisés avec une étroite collaboration entre le PO et l’équipe de développement, sans égard de la séparation client/fournisseur. En tant qu’équipe produit, nous avons fait des efforts concertés pour améliorer le produit final, y compris en reportant des fonctionnalités pour se concentrer sur la réduction de la dette technique, ou en faisant des coupes dans les coûts lorsque nécessaire.

De l’autre bord, lorsque le PO et l’équipe de développement ne travaillent pas complètement dans la même équipe, cela devient une partie de bras de fer permanente entre les deux. Avec le temps, l’équipe de développement s’impliquera moins dans le succès du projet et commencera à simplement obéir aux ordres du PO. Sur les projets à long terme, la qualité en souffrira, et des membres de l’équipe peuvent demander leur déplacement, ce qui est du gâchis pour le projet.

Des avis qui comptent

L’une des idées les plus fausses que j’ai entendues au sujet du travail avec un PO interne, c’est qu’on peut travailler comme on veut. Vous voulez passer de PHP à Node ? Pourquoi pas ! Ajouter un nouveau widget ? Bien sûr ! Vous avez vraiment besoin de rapports d’administrateurs avant de permettre à des usagers de se connecter ? Vous les avez.

Si les PO ne font que dire oui à tout, c’est qu’ils ne font pas un bon travail. Ils doivent orienter le projet dans la bonne direction, prioriser vraiment les idées et maintenir un contrôle serré du budget. Certains peuvent trouver qu’il est plus facile d’influencer un PO interne parce qu’ils sont du même camp, mais dans les entreprises bien gérées, les PO internes ont aussi des budgets et des délais à respecter.

D’un autre côté, les PO qui disent non à toutes les suggestions ne font sans doute pas non plus un très bon travail. Certes, vous avez parfois besoin de garder un contrôle très serré des fonctionnalités d’un MVP (produit minimum viable) en raison d’un salon professionnel à venir. Mais ce n’est pas toujours le cas. Et l’écoute des idées de tous les membres participe à la formation d’une équipe produit unie et fonctionnelle.

Gestion de la dette technique

J’admets qu’une version plus jeune de moi-même serait bien surprise à lire ce qui suit. Je considérais alors que toute dette technique était systématiquement mauvaise, que tout devait être conçu pour être à l’épreuve du futur, que tout devait être optimisé à la perfection et que tout devait être développé minutieusement comme il le faut.

Dans un monde idéal, peut-être. Nous avons sûrement passé beaucoup de temps à réusiner le code (refactoring) de fonctionnalités pratiquement pas utilisées ! Avec le temps, je me suis rendu compte qu’il n’y a parfois rien de mal à couper les coins ronds pour tester une fonctionnalité. Ce n’est pas aussi joli que ça pourrait l’être, mais c’est sans risque, ça ne vous donnera pas le cancer… Ensuite, laissez aller. Ajoutez une « story » de réusinage de code dans le « backlog » et passez à autre chose.

Il s’agit une fois de plus d’un exercice d’équilibre. De mon expérience, les PO externes ont tendance à être beaucoup moins indulgents à l’égard de la dette technique que les PO internes. « Déjà, pourquoi avez-vous laissé s’accumuler cette dette ? » Je ne saurais trop insister sur l’étroitesse de cette vision et comment cela peut mener à l’augmentation du temps de développement pour chacune des fonctionnalités demandées. Si vous n’avez qu’une seule chance pour coder quelque chose, vous voulez alors que ce soit d’emblée impeccable. Mais cela peut être du gaspillage si tout ce dont vous aviez besoin était de juste tester une fonctionnalité.

Flexibilité du budget et des délais

Avec un PO externe, il y a le sentiment que le budget est limité, alors qu’avec un PO et des développeurs relevant du même employeur, cela peut d’une façon ou d’une autre rendre le budget plus élastique. De même, avec un PO externe, des délais arbitraires deviennent par magie des dates gravées dans le marbre.

Il est cependant malheureux que cela se produise. Une possible cause est que les PO externes reçoivent généralement une copie de la facture de l’équipe de développement, et qu’ils sont ainsi incités à faire le suivi de projet en fonction de montants en dollars, alors que les PO internes se baseront avant tout sur le temps. Et parce que les délais arbitraires peuvent être modifiés, les budgets internes paraissent alors plus flexibles que les externes.

Cela dit, ça a pu être vrai avant, mais il y a de nos jours une pression accrue sur les PO internes pour qu’ils gèrent leurs projets avec la plus grande rigueur.

Pour conclure

Quel que soit le projet, un facteur clé pour s’assurer du succès est de faire travailler ensemble les membres de l’équipe produit (PO et équipe de développement). Chacun doit être conscient des délais, des contraintes et des objectifs du projet.

Lorsqu’il y a une bonne collaboration au sein d’une équipe produit, la dette technique demeure à un niveau raisonnable, les fonctionnalités sont classées par ordre de priorité, les délais sont respectés et le budget est maîtrisé. Et ceci reste vrai que le PO soit interne ou externe.