Une expérience de Product Owner, ça donne quoi ?

Product Owner et Workflow
Accueil » Mon Notebook » Une expérience de Product Owner, ça donne quoi ?

Avant d’aborder mon expérience quotidienne en tant que Product Owner (PO), je souhaiterais mettre en avant ma vision. En effet, chacun à sa propre vision sur la manière dont il souhaite exercer son métier et dans quel but.

Ma vision

Je me positionne en tant que facilitateur et j’accompagne les projets numériques en construisant un climat bienveillant avec mes partenaires. Le but est de satisfaire toutes les parties prenantes du projet en capitalisant sur l’humain et les savoir-faire.

Comment ?

L’humain doit occuper une place prédominante dans nos prises de décisions. Je crois en l’intelligence collective et c’est ensemble que nous pouvons répondre aux enjeux organisationnels.

Être Product Owner au quotidien, ça donne quoi ?

Daily Meeting
Sprint Planning
  • A 9h00 c’est Daily ! Une réunion quotidienne où on aborde les projets en cours avec toutes les équipes. Chacun nous fait part de ce qu’il a fait la veille, ce qu’il compte faire aujourd’hui et les sujets sur lesquels il pourrait avoir des zones d’ombres.
  • Suivi du Workflow : tous les matins je parcours Jira (notre outil de gestion de projet) pour faire un état des lieux des tâches à faire, en cours, à tester ou terminées.
  • Le suivi du Workflow s’accompagne de l’analyse des KPIs : vélocité, évolution du projet, point budgétaire
  • Recetter (Tester) les fonctionnalités produites par les dévs.
  • Cleaner le Backlog : Parcourir le backlog et le prioriser pour le prochain Sprint. Parfois certaines tâches sont imprécises, plus d’utilité ou plus d’actualité. Il faut nettoyer tout ça !
  • Préparation du Sprint Planning : Pour anticiper au mieux le Sprint à venir, il est important de prioriser les projets et les tâches à produire. En fonction de la charge et de la Vélocité de chacun, nous pourrons établir les objectifs du prochain Sprint.

Ça c’est dans les grandes lignes.

Il y a également beaucoup d’appels avec les partenaires, beaucoup ! Des questions sur les règles métiers, beaucoup de questions. Il faut savoir parfois se poser, prendre du recul et se demander : “Quels enjeux?” “Pourquoi?” “Pour qui?” “Comment ?” . Le but est d’offrir LA solution qui répond au besoin de l’utilisateur.

Les grandes étapes d’un projet

Étape 1 : Dénicher et comprendre LE besoin

C’est un travail fastidieux mais qui est primordial ! Evidemment, il  ne se fait pas seul mais avec tous les partenaires et parties prenantes concernés : les équipes métiers comme les utilisateurs. 

Donnons du sens à nos projets !

Les ateliers de cadrage

Ces ateliers permettent aux Product Owner, au Lead Tech de se réunir avec leurs partenaires qui ont un besoin. Il faut savoir que leur besoin n’est peut-être pas LE véritable besoin. D’où l’intérêt de ces ateliers : Prendre le temps de se poser les bonnes questions, d’échanger, de faire intervenir l’intelligence collective, en se centrant sur l’utilisateur final.

Pour cela, nous pouvons utiliser une méthode innovante : Le Design Thinking

Étape 2 : Concevoir

Une fois le périmètre bien cadré et les besoins soulevés, nous pouvons entrer dans la phase de conception du projet. 

Cette phase se réalise en étroite collaboration avec nos partenaires. Elle permet de relever les règles métiers, les “Must Have”, “Should Have”, “Could Have”, “Won’t Have” du projet. L’intérêt est d’élaborer ensemble le MVP (Minimum Viable Product) du projet.
En savoir plus sur la Méthode MoSCoW ?

La conception se concrétise également par le biais de prototypages (Wireframe, Zoning, Story Map, etc.) tout cela en ne perdant pas de vue le besoin de l’utilisateur final.

Étape 3 : Produire

Une fois la conception terminée, le cadre est posé.

Il n’y a plus qu’à…

Le but des projets agiles est de livrer le plus rapidement de la valeur au produit. Cela ne fait pas itération que nous appelons Sprint. Au cours d’un Sprint, l’équipe technique développe les fonctionnalités qui auront été proposées par le Product Owner. Une fois développées, elles pourront être testées par le Product Owner ainsi que les partenaires. 

En fin de Sprint, c’est ensemble que nous validons les fonctionnalités produites. 

Si certaines tâches n’ont pas été achevées alors elles pourront être intégrées dans le prochain Sprint. 

Lignes de codes

Étape 4 : Capitaliser

L’étape de la capitalisation ne doit pas être une fin en soi. 

Tout d’abord, il est bon de capitaliser tout au long du projet et de se nourrir des feedbacks

  • Les feedbacks des utilisateurs sur les fonctions produits. Cela peut se faire lors des Sprints Review.
  • Les feedbacks de la team sur le déroulement du projet et les processus internes. Ce temps d’échange est formalisé par le Sprint Retrospective qui se déroule après le Sprint Review, sans les partenaires du projet. 

Ensuite, une fois que toutes les fonctionnalités du produit ont été produites et validées, il est temps de se réunir pour échanger sur le déroulé du projet dans sa généralité. Nous pouvons évoquer aussi bien les processus internes que les petits moments de doutes ou les petites victoires. L’important est de capitaliser. 

C’est aussi l’occasion d’évoquer les améliorations potentielles du produit et d’une future V2. 

Ça bouge vite dans le numérique !  

Laisse un commentaire