Comment une histoire de cadrage a fait collaborer toute une organisation pour construire un produit – partie 2

Précédemment dans notre quête du graal..

Après notre prise de conscience et un travail acharné pour trouver l’équilibre entre les enjeux techniques, business et les besoins utilisateurs, la sentence tombe : sur les deux sujets sur lesquels on a travaillé, on se retrouve avec un go pour le sujet mineur et un no-go sur le majeur. C’est le drame. Que faire maintenant ? 

Deuxième étape : embarquer la technique, jusqu’à arracher les développeurs de leur code pour co-concevoir avec nous 🧑🏻‍🎨

Nous voilà repartis pour une deuxième édition ! Cette fois un peu plus light : en effet, on avait déjà la majorité des infos qu’il nous fallait : le parcours cible, les retours utilisateurs et une première version des écrans. 

On se met d’accord sur un nouveau challenge : répondre au besoin utilisateur en 5 sprints. On redéfinit l’équipe cœur : UX/UI, PO, PM, représentants opérationnels, sans oublier cette fois le Tech Lead (ou a minima un développeur). 

On est parties sur une nouvelle série d’ateliers : 

  • On re-sketch avec une vision tech : plusieurs développeurs de l’équipe se sont libérés pour “dessiner” avec nous. 
  • On prend le temps de faire un MoSCoW (Must have Should have Could have Won’t) : on priorise les user stories et on définit notre MVP (Ou plutôt Minimum Viable Feature en l’occurrence). 
  • C’est enfin le moment pour l’équipe technique de passer en extreme quotation puis de nous partager les différents scénarios envisageables : du plus rapide au plus coûteux. 🤑

Enfin, arrive le moment fatidique, on se réunit avec : l’UX designer qui porte la voix des utilisateurs à travers les tests effectués, le directeur produit qui porte la vision stratégique et les enjeux business et le Product owner qui a en tête les scénarios techniques et peut donc imaginer comment répondre à l’objectif sur le planning envisagé.

Et PAF ! On en sort avec un go sur un incrément produit à forte valeur business, qui répond aux besoins des utilisateurs et qui est réalisable sur une période de 5 semaines : on tient notre méthode, que l’on a appelé PIF (Product Increment Framing). 

On en sort avec une méthode ou en tout cas un ensemble d’outils et d’ateliers mis à jour et qui s’articulent de la manière suivante. 🥳


TAKE AWAY 🧳

  • SURTOUT INCLURE L’ÉQUIPE TECHNIQUE DÈS LE DÉPART
  • Anticiper un éventuel NO GO : prévoir le temps de réitérer
  • Considérer les enjeux tech, au même niveau que les utilisateurs et le business.

À suivre : la troisième et dernière étape de notre épopée, nous nous attaquerons à la mise en place du changement avec les enchanteurs de l’accompagnement au changement.

Leave a Reply

Your email address will not be published.


This form is protected by Google Recaptcha