Il existe un rôle de PO technique (product owner technique) dont nous parlons très peu. Certains vont être surpris en voyant ce titre, d’autres vont dire « enfin on en parle ». En effet, dans certains cadres, le concept de PO technique peut être fort utile.
Mais le Product Owner est fonctionnel ?
Absolument pas ! Le scrum guide ne définit jamais les cases : « technique », « fonctionnel », « technico-fonctionnel »… Et il y a une bonne raison à cela. Tout dépend des produits à réaliser.
Donc en réalité, quand nous parlons de po technique, nous parlons d’un product owner travaillant principalement sur les items techniques. Et sur certains produits, il n y a pas d’utilisateur « final ».
Cependant avoir un po technique, ne veut surtout pas dire qu’il y a aussi un po fonctionnel. Il y a un seul product owner dans chaque équipe si nous suivons scrupuleusement le scrum guide.
Alors comment définir ce PO technique ?
Le product owner technique est un product owner qui a toutes les responsabilités attendus par un product owner mais sur un backlog qui sera principalement technique.
Article à lire : le product owner
Exemple pour comprendre
Une équipe travaille sur la refonte d’une plateforme micro-service se retrouvant au centre du système informatique. L’objectif de cette refonte sera de proposer un système plus performant et répondant aux nouvelles attentes des autres systèmes.
En effet, dans ce cadre, les clients de cette plateforme micro-service proposant des API complètes, seront les autres outils.
Le PO devra ainsi écrire des items très techniques pour répondre aux différentes attentes des autres outils liés à son système. Comme vous le voyez sur l’image ci-dessous, seuls d’autres systèmes sont utilisateurs de cette plateforme. Les autres systèmes sont eux pris en charge par d’autres équipes.
Mais nous comprenons vite aussi, que ce dit « po technique » peut également utiliser les user-stories pour créer son backlog. En effet, il ira questionner les autres équipes du système d’information pour comprendre au mieux les besoins de chacun.
Autre exemple
Une équipe architecture a un po technique pour créer et gérer le backlog de l’équipe. Il lui sera en général nécessaire d’avoir de réelles connaissances techniques pour réellement aider l’équipe.
Prenons une demande particulière au sein d’un hôpital :
En tant que docteur, je souhaite avoir accès aux images du scanner à partir de la salle de surveillance afin de pouvoir vérifier les résultats en direct
Bien que le product owner pourrait constamment amener un technicien spécialisé pour venir l’aider, il paraitrait plus simple qu’il ait des connaissances techniques minime pour avoir rapidement une première vision du travail qui est attendu. Ce n’est certes pas obligatoire mais cela permet de faire gagner considérablement du temps aux techniciens de ce types d’outils qui ont déjà très peu de temps libre.
Donc le PO technique en fait, ça n’existe pas ?
En effet, même si le terme est souvent utilisé, il n’est en réalité qu’un product owner normal qui est 100% compatible avec ce fameux scrum guide.
Par contre mettre un PO technique en plus d’un PO dit normal n’a pas vraiment de sens. Vous pouvez mettre une personne ayant des compétences de business analyst technique pour l’épauler mais cela n’en fera pas pour autant un product owner.
Soyez le premier à commenter