4sStylZ-II
2021-02-01 15:16:36
Salut,
Je suis consultant et j'officie souvent comme PO et coach agile « junior » (je ne m'occupe pas de large structure avec du Safe etc…)
Plusieurs infos en vrac :
Un PO est le visage des utilisateurs pour l'équipe -> Il doit prendre toutes les décisions sur le produit, trancher quand c'est nécessaire, sur la roadmap, les features, parfois même le design ou la solution que l'on veut livrer.
Un PO est aussi le visage de l'équipe pour les utilisateurs -> Il doit avertir, expliquer la progression et les choix pris sur le produit. Il doit communiquer sur les évolutions… et aussi avertir des problèmes / risques.
PO c'est un rôle dans une équipe (en général une équipe Scrum) ce n'est pas un intitulé de poste, à la base, alors que Chef de projet est à la base un intitulé de poste.
On oppose généralement la logique projet à l'approche produit :
- Approche Projet : On fixe un résultat attendu en identifiants le périèmètre du projet. On évalue le temps que ça vas prendre : On se lance dedans, on livre à la fin (souvent… mais parfois à interval plus cours) mais l'examen du livrable est réalisé à la fin.
- Approche Produit : Le produit n'est pas un objectif en soit mais une manière de répondre aux enjeux des utilisateurs. On s'interesse à comment fournir la meilleur expérience utilisateur, à fournir de la valeur aux utilisateurs, et à faire les choix les plus pragmatiques. Ça implique donc de se poser en permanence cette question : Que peut on livrer maintenant qui apporte le plus de valeur ?
La logique de l'approche produit est très différente, et étroitement liées (et facile à mêtre en place) aux méthodes agiles qui favorisent la remise en question permanence : Lier l'amélioration continue des manières de travailler avec le « re » questionnement du produit en permanence ça fait sens pour beaucoup de société qui veulent réduire le time to market et réagir vite aux opportunités.
Les taches courantes d'un PO :
- Identifier les besoins utilisateurs et faire la différence entre ce qu'ils veulent de ce qu'ils ont besoin.
- Prioriser selon la valeur et le prix : Maximiser le retour sur investissement.
- Maintenir le product backlog : À ne pas confondre avec « il doit créer tous les items et les écrires ».
- Identifier les releases.
- Tester, car en agile « tout le monde teste ». Ce n'est pas un QA, ce n'est pas non plus un dev ou data scientiste. Il doit cependant faire des tests réguliers / ou les organiser avec des vrais utilisateurs pour vérifier que la valeur que l'on veut délivrer fait sens. Ce n'est pas quelqu'un qui doit mettre un coup de tampon sur chacun des items développés.
En terme de formation…
Un bon business analyste, un Data Scientist, un Dev, un Chef de projet, tous peuvent être de bons PO. Cela dépend de leurs soft skill, de leur habilité à communiquer et a initier des climats de confiance que ce soit avec les devs ou les utilisateurs. Ils doivent aussi s'adapter énormément aux attentes des devs (notamment sur le rédactionnel des users stories qui dépend énormément selon les équipes).
À l'opposé, il y a pleins de gens qui ne sont pas de bons PO car par préparé : Aucune conaissance sur l'approche produit ou alors ils n'y croient pas du tout. Mauvais communiquants, n'arrivent pas à cadrer le produit, n'arrive pas à trancher vite les décisisons pour qu'ils puissent avancer, sont de mauvais rédacteurs / manager de backlog etc…
Dites moi si la réponse vous a intéressé. Bye