Pourquoi ai-je envie de recommencer à programmer depuis que je suis Product Owner?

Par Mathieu Boisvert

Imaginez que vous êtes le Product Owner d’une application de Sudoku : vous seriez probablement capable de décrire les règles du jeu à votre équipe de développement et de lui fournir comme condition de succès, une grille résolue à partir d’une grille de départ valide. Mais il serait plus difficile de spécifier une grille de départ sans la référence d’une grille résolue. Pour y parvenir, vous auriez probablement recours à plusieurs expériences pour découvrir des grilles de départ valides. Et c’est sans compter la conception de grilles avec des difficultés multiples : comment savoir si une grille sera difficile à résoudre si vous ne connaissez pas la solution et les étapes requises pour y arriver?

C’est un peu comme cela que je me sens dans mon nouveau rôle de Product Owner…

Je suis nouvellement le Product Owner d’un produit interactif dont la mission est de rendre plus pertinent l’enseignement en ligne des approches Lean. J’ai une grande expérience dans l’enseignement de ces approches et j’ai la chance de travailler avec Christian Bélisle, un programmeur d’expérience qui possède des connaissances dans le développement de jeux vidéo.

J’ai abordé mon rôle de Product Owner de la façon habituelle : en faisant mes demandes de développement via la rédaction d’un carnet de produit. Cependant, je me suis rapidement aperçu que même si la création de matériel pédagogique est facile pour moi, et même si Christian est en mesure de programmer les exercices Lean, il est difficile de connaître les configurations de départs dysfonctionnels sans faire des expériences.

Nous avons donc commencé un genre de partie de ping-pong : je lui décris les paramètres de mes expériences et il les programme. Mais c’est assez inefficace, car :

  • Christian attend après moi lorsque je réfléchis aux paramètres des expériences.
  • Sans les résultats des expériences, j’ai de la difficulté à poursuivre la rédaction du matériel pédagogique.
  • Nous ne savons pas combien de tentatives seront requises pour trouver des paramètres satisfaisants.

Puisque je suis un ancien programmeur Java, j’ai maintenant envie de programmer mes expériences de mon côté afin de briser notre dynamique d’échange inefficace. Et cela m’ennuie, parce que je suis persuadé que normalement, un Product Owner ne devrait pas programmer.

bad idea

Pourquoi est-ce une mauvaise idée pour un Product Owner de programmer?

Sans que cela soit une règle absolue, on préfère généralement les Products Owners ayant un bagage d’affaires plutôt que technique, parce que :

  • Ils comprennent la valeur du produit à construire, ainsi que les besoins des clients/utilisateurs.
  • Ils incarnent la réalité des utilisateurs.
  • Ils ont l’information et l’autorité pour prendre des décisions de manière plus autonome.
  • Ils ont un réseau de contacts pour trouver l’information manquante, confirmer leurs hypothèses et présenter les résultats.

Nous pouvons donc déduire qu’un candidat qui possède des connaissances sur le développement de produit et le marketing, ainsi qu’une compréhension de la clientèle et de la concurrence, aurait tout ce qu’il faut pour bien faire son travail.

“In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out.”

L’équipe s’attend donc à ce que le client exprime un besoin d’affaires qu’il faut résoudre et qu’il ne participe pas trop aux choix techniques, sauf lorsque ceux-ci ont une incidence sur le succès d’un produit.

Pire, une expertise dans le domaine technique pourrait devenir un dysfonctionnement au sein d’une équipe Scrum :

“It could be disastrous if they had worked as a programmer 15 years ago and pretended that their understanding of technical tradeoffs remained perfectly relevant today. I’ve worked with product owners who had stopped programming 15 years earlier and couldn’t understand why something that was easy to do on a Green Screen application took longer to do with Enterprise Java. This led in some cases to fights over cost estimates. It might help to know what’s feasible, but if they work with programmers that they can trust, then that becomes less of an issue.”

Billet No, a Product Owner doesn’t need programming skill de J.B. Rainsberger

Alors que puis-je faire ?

Voici les quelques options qui me viennent à l’esprit pour améliorer la dynamique entre Christian et moi :

  • Programmer : Je suis chanceux, je sais programmer, au moins en Java. Et je ne suis pas le seul, de nombreux Product Owners sont d’excellents programmeurs Excel ou Access. Tant que cette programmation sert à spécifier le besoin plutôt qu’à programmer la solution logicielle, cela respecte l’esprit du rôle du Product Owner. Christian pourrait même apprécier le fait de recevoir les spécifications sous la forme de tests unitaires exécutables, et pas seulement sous forme textuelle.
  • Rédiger des tests d’acceptation automatisés: Avec des plateformes comme SpecsFlow, Cucumber ou Selenium, il serait possible pour moi de rédiger les paramètres de mes expériences et de les exécuter directement sur le code de Christian. Cela réduirait les coûts de programmation, car je pourrais tester le moteur logique de Christian sans lui demander de mettre à jour l’interface de la solution finale. En plus, ces tests serviraient de spécifications pour Christian, et cela réduirait probablement les cycles de rétroaction entre nous.
  • Utiliser une console : Les tests d’acceptation automatisés peuvent être intimidants pour un Product Owner moins technique. Si Christian me développait une console pour interagir avec son code, sans utiliser l’interface de la solution finale, alors je pourrais conduire mes tests de manière indépendante et je réduirais l’effort de développement pour Christian. Par contre, je devrais continuer à spécifier de façon textuelle.

Et VOUS, que me recommanderiez-vous?

Vous avez peut-être vécu des situations similaires comme développeur ou comme Product Owner. Comment avez-vous fait face à la situation?

Lectures complémentaires

Autres articles qui pourraient vous intéresser

transformations numériques

Leadership dans les transformations numériques, un rôle critique!

Avec les transformations numériques incessantes à notre époque, le leadership émerge comme le catalyseur essentiel du changement et de la réussite organisationnelle. Plongeons dans les différents aspects du leadership dans ce contexte pour découvrir comment, à travers sa vision stratégique, sa culture d’innovation et son investissement dans les talents numériques, il est le moteur indispensable...
Votre partenaire de solutions logiciels sur mesure | Done Technologies

logiciel sur mesure avec un petit budget : 5 conseils de pro

La décision d’utiliser un logiciel existant ou d’investir dans le développement d’un logiciel sur mesure fait toujours l’objet de nombreux débats. L’utilisation d’un logiciel existant possédant déjà certaines fonctionnalités de base peut sembler tentante, mais nous oublions souvent de la comparer aux avantages de développer un logiciel sur mesure. Depuis plus de 17 ans, Done...
Votre partenaire de solutions logiciels sur mesure | Done Technologies

L’importance de l’environnement de travail EN TI

Les employés d’organisations qui oeuvrent dans le domaine des TI, plus particulièrement les développeurs, traînent souvent la vieille réputation de ne pas accorder beaucoup d’importance à leur environnement de travail physique. Bien sûr, il est important qu’ils aient un espace de travail adéquat et soient situés près des collègues avec qui ils doivent collaborer régulièrement,...