Pardonnez ma question à l’avance. En tant que Freelance j’ai souvent collaboré de manière naturelle entre les corps de métiers pour arriver à livrer les solutions.
Si je prends le manifeste Agile le rôle du PO le voici :
Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. La manière de procéder peut varier considérablement selon les organisations, les Scrum Teams et les individus.
Le Product Owner est également redevable de la gestion efficace du Product Backlog.
Ce qui inclut :
Formuler et communiquer explicitement l’Objectif de Produit
Créer et communiquer clairement les éléments du Product Backlog
Ordonner les éléments dans le Product Backlog
S’assurer que le Product Backlog est transparent, visible et compris
Un PO n’est pas un UX. Il me semble logique aussi que le PO possède des wireframes au moins pour visualiser le produit (ne pas rester dans l’abstrait) et collaborer avec le N+1 sur son objectif.
Le PO pour réaliser toutes ces tâches collabore donc avec le :
Product Designer (UX / UI)
Product Marketing
Product Research
A partir de là, la vision du produit sera plus juste (fonctionnalités, nombre de page, …) et il pourra échanger de manière efficace avec le Scrum Master ?
Bonjour Xavier, et bienvenue sur le forum de Scrum Life !
Je pense qu’il y a ici une petite confusion classique entre le rôle d’un UX et celui d’un UI.
Le rôle d’un UI (graphiste en français), est de perfectionner l’interface utilisateur. C’est donc lui qui travaille habituellement avec les maquettes et toute la partie visualisation du produit. Le terme UX n’a pas vraiment de traduction en français, mais l’une des UX designer les plus connus dans le monde est une française, bien connue sur ses travaux sur Fortnite. Elle s’appelle Celia Hodent, et elle est docteure en psychologie cognitive.
Le rôle d’un UX est de perfectionner l’expérience utilisateur. Bien sûr, les visuels jouent un rôle primordial dans cette expérience, car le sens visuel est l’un des plus influent sur le comportement. Pour autant, un bon UX designer ne cherche pas toujours à faire les meilleurs visuels. Amazon est un excellent exemple. Leur site est moche et désorganisé au possible mais ce n’est pas par incompétence ou paresse : de cette manière ils augmentent le temps passé par les prospects sur le site, augmentant les chances d’achat compulsif. De plus, lors qu’un client trouve le bon produit, comme cela a nécessité un effort significatif, il ressent une plus grande satisfaction à l’achat. Cela renforce l’association de l’acte d’achat avec sentiment positif qui va influencer le client et l’inciter à revenir achter chez Amazon plutôt que chez un concurrent.
Un rôle d’UX est donc très proche de celui d’un PO. Ou plus précisément, un bon PO devrait avoir des compétences en UX design. Ensuite c’est une histoire de taille et de structure de l’organisation dans laquelle le produit est développé. Dans une petite structure, le PO va faire un peu de tout, alors qu’ailleurs, on peut avoir une équipe d’experts en UX design qui sont partagés entre différents produits, en soutien des différents PO.
Cette vision part de l’hypothèse qu’un PO sait concevoir le produit « juste ».
Or l’expérience montre que, sauf gros coup de pot, on se trompe systématiquement.
Si pour une raison X ou Y on a la certitude absolue qu’on sait ce qu’il faut développer, comment le développer et que ça ne va pas changer dans toute la durée de vie du produit, alors Scrum n’est pas la bonne méthode. A ce moment là, il est bien plus simple et efficace de faire un projet au forfait sur un mode V classique.
Le PO n’est effectivement pas un UI designer, et ce n’est pas un BA non plus. Ce n’est pas de lui qu’on attend la conception technique. C’est pourquoi il est important que le PO se présente en planning avec un besoin utilisateur, décrit en mode boîte noire, et non une solution à base de wireframes dessinés en amont. La conception n’est pas non plus le rôle du SM non plus. C’est le rôle de l’équipe entière.
Cette équipe s’appuye alors sur les expertises qui la composent pour faire le meilleur produit possible :
L’expertise marketing du PO (qui devrait avoir une composante UX) ;
L’expertise technique des devs (qui inclut une composante UI) ;
L’expertise organisationnelle du SM.
Il n’y a pas plus grande frustration pour une équipe de développement compétente de recevoir des « spec-story » à implémenter qui sont issues du travail de conception préalable, même « high-level », réalisé par un PO. On sait d’avance que ça ne va pas marcher comme ça, parce qu’on découvre toujours des choses pas anticipables au cours du développement.
Par ailleurs, Scrum est une méthode empirique, c’est-à-dire qu’on travaille sur ce qu’on mesure, et non pas ce qu’on a imaginé. Ce sont les utilisateurs qui décident si le produit qu’on a développé leur convient ou non. Et ils sont parfois incohérents, capricieux et surtout leurs besoins peuvent changer. Pour ça, on accepte quelques petites choses du point de vue business :
Tout ce qu’on développe est jetable : on peut parfaitement décider après coup de s’en débarrasser si les hypothèses de départ ne sont pas atteintes lors des mesures ;
Puisque jetable, on limite la quantité de travail en jeu : on développe la fonctionnalité en mode MVP, on la fait utiliser, et si c’est rentable on peaufine dans un sprint subséquent.
Merci BEAUCOUP pour ta réponse complète. Effectivement j’ai peut-être tendance parfois à voir le PO comme un chef de projet alors que la méthode agile est horizontale et collaborative. En fait, si je comprends bien ce que tu dis, le PO est coté produit :
Echanger / Comprendre le(s) / Analyse / cadrer les besoins du client
Les formaliser à travers un Product Backlog
Ordonner les éléments dans le Product Backlog
S’assurer que le Product Backlog est transparent, visible et compris
Une fois cela, il collabore avec l’ensemble des membres, chacun dans leurs spécialités afin de produire le produit final et livrer les élèments réalisés. Comme tu le dis à juste titre, cela dépend de la taille des équipes et des compétences existantes.
Les différents nom donné (PO/PM) sont en fait plus des rôles au sein d’une équipes que des fonctions (dans le sens hiérarchique).
Le corolaire de tout cela, c’est qu’il faut une parfaite complicité au sein de l’équipe, une bonne entente pour atteindre les objectifs ensemble et de manière commune.
L’arbitre (priorisation des élèments en fonction des objectifs du client) au sein d’une équipe, c’est le PO ?
En général on évite de parler de client, car souvent l’utilisateur (celui qui manipule) n’est pas la même personne que le sponsor (celui qui paie). Parfois on a même une distinction entre ces deux rôles et le bénéficiaire.
Le PO est responsable du backlog produit, et comme disait un interlocuteur dans un podcast « être responsable ça veut dire qu’on peut vous dire non ». Dans son contexte il parlait de la DSI face au COMEX de son entreprise, ça avait fait son petit effet. C’est donc le PO qui a le mot final sur le backlog produit, au même titre que le SM a le mot final sur l’organisation, et que les devs ont le mot final sur la technique.
Mais le fait d’avoir la responsabilité et le mot final sur un sujet n’implique pas qu’on doive gérer cet aspect seul. Il faut garder en tête que Scrum se traduit par le mot « mêlée ». L’équipe forme donc une mêlée pour produire le meilleur produit tous ensemble. Il ne s’agit pas d’additionner les efforts individuels chacun dans son coin, en espérant que ça s’emboite magiquement à la fin.
@ArwynFr Merci beaucoup pour les précisions sur les rôles. Le PO à le mot final sur les backlog produit, qui aura été construit en équipe.
Est-ce qu’il est possible de dire que le PM est le PO dans certaine entreprise selon leur taille et leur volume ?
Les Product Marketing, le Product Hardware,…ont-ils la même mission que le PO (valider le backlog en équipe) mais axé sur chacune de leur spécialité ? ou bien ils font partie de l’équipe d’un PO ?
Ce n’est pas expliqué clairement dans le guide mais dans Scrum il y a 2 backlogs.
Le product backlog est maintenu sous la responsabilité du PO qui a donc le mot final sur son contenu et son ordonnancement. Ce backlog est une sorte de roadmap produit, construite sous forme d’une liste ordonnée de product backlog items (PBI). Les PBI sont rédigés et construits avec tous les acteurs habituels du product/marketing : management, experts métier, direction marketing, UX designer (les vrais), architecte solutions, …
A cette étape, on ne s’intéresse surtout pas à la technique, seulement à identifier les fonctionnalités et exigences non-fonctionnelles (performance, sécurité) sur lesquelles on voudrait travailler. Quand les devs sont présents, ils abordent un point de vue fonctionnel et non technique : « la fonctionnalité X marche vraiment bien », « la fonctionnalité Y est vraiment fragile, il faudrait y passer plus de temps si vous voulez l’ouvrir à plus de monde », « la fonctionnalité Z semble difficile à mettre en oeuvre », etc …
Ce qui change par rapport à une gestion de produit traditionnelle c’est l’autorité absolue du PO sur le backlog produit, bien sûr, mais également l’utilisation d’un maximum de métriques et de vrai feedback utilisateur : si on hésite sur une fonctionnalité, c’est précisément là qu’on en fait un incrément utilisable, et on regarde ce qui se passe vraiment quand les utilisateurs one une vraie appli avec des vraies données dans les mains.
Ensuite, le PO se présente en sprint planning avec un PBI à transformer en incrément.
Toute l’équipe scrum (PO + SM + devs) se met alors d’accord sur le sprint backlog.
Ce backlog comprend 3 points :
Le sprint goal : à quelles conditions on considère l’incrément fonctionnel
La definition of done : les conditions pour considérer l’incrément utilisable (techniquement)
Le plan prévisionnel : la liste des actions à accomplir pendant le sprint
C’et là qu’on effectue le design technique et qu’on imagine la solution à implémenter. Ce backlog n’est pas sous la responsabilité d’une seule personne, mais de toute l’équipe qui est auto-organisée. Le SM donne un point de vue extérieur et des conseils sans diriger l’équipe.
Merci beaucoup d’avoir abordé ce concept « d’expérience utilisateur ».
Rapport intéressant entre le PO et le design UX.
Intéressé récemment par ce métier il est bon pour moi d’en lire le questionnement PO UX car une chose me convainc sans le savoir avant de m’y intéressé : « l’empirisme ». Ces 2 orientations ont ce but commun de tenir compte du ressenti utilisateur pour une amélioration continue du produit.
Je rejoins à 100% la notion UI ≠ UX.
Ils sont complémentaires (voire pas obligé). Excellent exemple Amazon bien que je n’en aime pas le design sur certains aspects mais je ne débute seulement depuis ce mois sur le savoir faire UX.
Le PO est donc le chef d’orchestre qui connait l’enjeux du produit, les contraintes du client ou des représentants. Il s’appuie donc sur un certain nombre de métier - qui ne maitrise pas - (échange, interviews utilisateurs, feedback existants,…) afin de constituer les différentes fonctionnalités, qui priorisera selon les enjeux qu’il connait !
C’est celui qui pilote l’équipe, qui est « responsable » du produit !
Le rôle du PM qui n’apparaît pas dans Scrum c’est en quelque sorte un PO mais ayant une vision plus globale des produits ?
@Johann_HARGUINDEGUY Totalement d’accord avec toi et @ArwynFr sur la différence entre un UX et un UI (qui selon la taille des organisations sont parfois identique).
Dans tous les noms des métiers que je vois, qui n’existaient pas encore il y a 10 ans, il est important de comprendre le role de chacun quand cela existe dans l’entreprise ^^
Pour résumer, SCRUM est ultra collaboratif, horizontale et repose sur équipe qui doit s’entendre parfaitement !
