Posted by jc-Qualitystreet on 26 juin 2010
Certes mais est-ce suffisant ?
Définitivement NON !
Une fois, toutes les 3 semaines, le dernier jour du sprint, pour vous c’est peut être mieux qu’avant, mais c’est loin d’être suffisant.
Car le feedback c’est le cœur de l’Agilité, l’élément clé du dispositif Agile, celui qui évidemment va assurer l’avancement du projet mais aussi celui qui permet de toujours faire mieux notamment au travers de l’amélioration continue (« Plan-Do-Check-Act » / « Inspect & Adapt »).
Quel est le problème ?
La principale difficulté réside dans le fait que le FEEDBACK (à recevoir / à donner) n’est ni quelque chose de naturel, ni une habitude ancrée dans notre façon de travailler.
Loin de le rechercher, beaucoup d’équipes ont donc tendance à le fuir ou à le retarder, tout en rationalisant tant bien que mal une conduite de moins en moins justifiable …
- « Ça va nous ralentir »
- « S’il donne son feedback, on en finira jamais »
- « De toute façon il ne sera jamais content »
- « Il va rajouter des choses »
- « Dans le Sprint? on a pas le temps »
- « L’itératif ça marche comme ça…on se voit à la fin et les modifs c’est pour le sprint suivant »
- « Mais alors à quoi ça servirait de faire une demo? »
- …
Le feedback est déterminant et multiple
La qualité du Feedback est selon moi un indicateur majeur du caractère agile d’une équipe, signe d’une performance maîtrisée.
- Sans Feedback, ça ne marche pas…
- Plus vous intégrez tôt le feedback, mieux c’est…
- Plus le feedback est rapide, mieux c’est…
L’absence de feedback constitue donc une entrave à la performance de l’équipe qui nuit gravement à la dynamique collective ainsi qu’à la fluidité du « process » agile.
Son impact sur la qualité du produit est évident, à court ou moyen terme.
Maintenant, être prêt à recevoir (POSITIVEMENT) le feedback, et inversement, donner du feedback (DE MANIERE CONSTRUCTIVE), c’est un changement culturel majeur pour les Hommes et les organisations.
Plus qu’une question d’apprentissage, c’est d’abord une affaire de volonté et d’état d’esprit qui nécessite de s’appuyer sur trois ingrédients essentiels à cultiver sans modération :
- le courage,
- le respect
- la confiance.
Et Pour l’équipe Agile ?
- C’est solliciter des retours du Client (ou Product Owner) le plus tôt et le plus souvent possible, TOUT AU LONG DU SPRINT
- C’est multiplier les rencontres avec les utilisateurs finaux, dans une approche Guerilla Usability ou RITE
- C’est se donner en permanence du feedback dans l’équipe (Daily Scrum, workshops, Pair programming, Tests…)
- C’est recueillir en continu le feedback du produit (TDD, Intégration continue, Tests fonctionnels automatisés ou non : cela sert à ça !)
- C’est faire une demo plus formelle à chaque fin de sprint
- C’est finalement tenir compte de ces feedback et s’adapter en continu dans un esprit” kaizen”
Mon Challenge de coach Agile :
- Mettre la question du feedback au cœur des préoccupations de l’équipe et les amener à travailler ensemble sur cet axe
- Remettre les valeurs & Principes agiles sur le devant de la scène et cultiver des valeurs humaines fondamentales telles que le respect, le courage et la confiance
- Insister au niveau de l’organisation sur les vertus de la colocalisation (Product Owner / Equipe) et inciter le Product Owner à assister le plus souvent possible aux Daily Scrum
- Inciter l’équipe à « TERMINER » les choses et à les montrer en sollicitant aussitôt le Product Owner (client)
- Inciter le Product Owner (Client) à aller voir, à initier la conversation, à faire le premier pas sans attendre la demo de fin de sprint …
- Convaincre de l’intérêt de rencontrer les utilisateurs finaux
- Impliquer les acteurs et faciliter directement le feedback au travers de RDV collaboratifs
La conclusion me vient directement d’une équipe qui travaille dans un mode agile depuis quelques mois et de ses réponses plutôt éloquentes à cette question de retrospective « Qu’est ce qu’on a fait de bien sur ce sprint ? »:
1. « Les workshops techniques »
2. « Les workshops Business »
3. « Le maquettage (Balsamiq)
Chez eux, le feedback progresse ….
Mes autres Alertes:
Posted by jc-Qualitystreet on 11 février 2010
On me demande souvent quels éléments placer sur le radiateur d’informations du projet, de l’équipe. Le Taskboard (voire le Kanban Board, c’est à la mode) est une réponse évidente mais pas suffisante…
Version détaillée
Version simple
Souvent négligée (et on pourrait se demander pourquoi …), la liste des obstacles est l’un de ces éléments clés, l’outil indispensable de notre dispositif agile, au service de l‘Equipe et du ScrumMaster.
COMMENT ? VOUS NE L’AFFICHEZ PAS ENCORE SUR VOTRE MUR !
Pourtant, la liste des obstacles est Essentielle pour l’EQUIPE
Rappelez-vous la 3ème question du Daily Scrum : « qu’est ce qui t’empêche de faire ton travail ? », la liste des obstacles rend visible les éventuels blocages émis par les membres de l’équipe.
Le dire c’est bien, traiter le problème c’est mieux ! Et sentir qu’on s’occupe de lever ces obstacles, ça fait du bien.
Voilà quelques bienfaits du management visuel.
Pourtant la liste des obstacles est Essentielle pour le ScrumMaster (« chef de projet Agile »)
Garant du Process Scrum, facilitateur et protecteur de l’équipe, le rôle du ScrumMaster est justement de dégager les obstacles qui surgissent et entravent le travail de l’équipe. Son But : faire en sorte que la liste des obstacles redevienne vierge. Dans ce sens, elle est un très bel outil d’information et communication ; et surtout la preuve que le ScrumMaster (en particulier) et l’Equipe se battent pour le projet.
Au final la liste des obstacles est indissociable des valeurs agiles
Communication, Courage, Feedback, Simplicité : afficher la liste des obstacles, c’est un peu tout ça, c’est avoir l’esprit Agile. Et jouer la transparence, la rendre visible en permanence, la revisiter au quotidien n’est pas anodin !
Posted by jc-Qualitystreet on 15 décembre 2009
Seconde étape de mon parcours au travers d’un référentiel Agile CMMI, après REQM « Gestion des exigences »,
Pour rappel, ma posture est celle d’un coach agile qui accompagne une organisation cherchant à atteindre, pour diverses raisons, le niveau de maturité 3 CMMI, mais souhaitant garder un mode de fonctionnement agile fondé sur des pratiques SCRUM et XP.
Voici donc la marche à suivre pour RSKM, “Gestion des risques“, l’un des domaines du Niveau de maturité 3, dont l’intention est de « identifier des problèmes potentiels avant qu’ils surviennent de telle sorte que les activités pour traiter les risques puissent être planifiées et déclenchées au besoin tout au long de la vie du produit ou du projet afin que les impacts nuisibles à l’atteinte des objectifs soient atténués ».
La gestion des risques est une activité indispensable à tout projet informatique ou pas. D’ailleurs le risque est inhérent à toute activité. DANS LE CADRE D’UNE APPROCHE combinant AGILE et CMMI, la gestion des risques est encore PLUS EFFICACE : collective, omniprésente et facilitée !
Au programme donc, RSKM dans une perspective Agile CMMI :
- Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
- Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
- Quels sont les objectifs génériques à satisfaire OBLIGATOIREMENT ( Niveau 2 & 3), et comment se positionne l’agilité sur les pratiques génériques initialement recommandées?
1 OBJECTIF(S)SPECIFIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI
RSKM SG1 : Se préparer à la gestion des risques
OK AGILE CMMI
Un travail de préparation est requis. Ce travail consiste à documenter la stratégie d’identification, d’analyse et d’atténuation des risques. Agile ou pas : on doit le voir comme une aide. Un petit guide, incluant des checklists est toujours précieux au démarrage d’un projet. J’en ai moi-même rédigé il y a quelques années. Ce travail relève de ce que j’appelle le Process Agile : il est à disposition des équipes et du ScrumMaster quand le projet démarre. Dans un contexte Agile-CMMI, c’est indispensable sans être véritablement contraignant.
RSKM SG2 : Identifier et analyser les risques
OK AGILE CMMI
Passé la préparation, on entre dans le vif du sujet, cette fois au niveau du projet. Les risques doivent être identifiés et analysés. Les méthodes Agiles contribuent fortement au travail d’identification des risques, en particulier quand le projet est lancé : c’est un des premiers atouts d’une gestion agile des risques.
RSKM SG3 : Atténuer les risques
OK AGILE CMMI
Une fois identifiés et analysés, il faut tout simplement les gérer. Je conseille aux équipes de rendre cette gestion la plus visible possible en adoptant l’AGILE RISK BOARD, à placer au cœur du radiateur d’informations. Là encore, cette pratique est littéralement décuplée sur les projets Agiles.
Agile Risk Board - Jean Claude Grosjean
Voilà donc trois objectifs à atteindre. Est-ce un problème pour l’agilité ? Non, et bien au contraire. Un process, des pratiques (l’AGILE RISK BOARD) et des équipes Agile CMMI permettent d’atteindre largement ces objectifs d’une manière résolument différente : à la fois organique (intégrée) et spécifique (au travers de différents RDV)
2 PRATIQUES(S) SPECIFIQUES DE REFERENCE RECOMMANDEE POUR CMMI
Il s’agit des pratiques recommandées dans le modèle théorique. Non imposées, elles servent souvent de guide pour ceux qui démarrent leur projet d’amélioration des processus mais peuvent être remplacées par des pratiques alternatives, contextualisées à l’entreprise, pourvu qu’elles permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les risques! Les trois premières pratiques relèvent du process Agile et sont menées hors projet.
RSKM-SP1.1 Déterminer les sources et les catégories de risques.
OK AGILE CMMI
Rien de très agile la dedans en effet. Des bonnes pratiques existent en la matière. Cela passe par des rapides checklist, la connaissance des sources potentielles (externes ou internes) et l’émergence de catégories : technique, fonctionnels, métiers, fournisseurs …, le tout en capitalisant sur les projets passés. Pourtant, garder l’esprit Agile reste la clé de ce petit guide fondé sur l’expérience et adapté à ses destinataires : juste ce qu’il faut !
Qui : Coach Agile
Quoi : Guide de gestion des risques
RSKM-SP1.2 Définir les paramètres utilisés pour analyser et catégoriser les risques ainsi que les paramètres utilisés pour contrôler la charge de gestion des risques.
OK AGILE CMMI
Idem, nous sommes dans du Process Agile, et des bonnes pratiques existent : échelle de probabilité d’occurrence, échelle d’étendue de l’impact et sévérité. C’est du classique, c’est simple mais ça marche bien.
Qui : Coach Agile
Quoi : Guide de gestion des risques
RSKM-SP1.3 Etablir et maintenir la stratégie qui sera utilisée pour la gestion des risques
OK AGILE CMMI
Toujours du process Agile avec une description de la façon dont on va procéder sur les projets. On insistera ici sur l’aspect intégré et collectif de la gestion agile des risques mais aussi sur les points de contrôle et de surveillance beaucoup plus fréquents (réunion de planification, daily scrum, revue de sprint, Agile Risk Board…). Un rappel de ces éléments est nécessairement effectué dans le Plan de Projet.
Qui : Coach Agile
Quoi : Guide de gestion des risques - Plan de projet
RSKM-SP2.1 Identifier et documenter les risques.
OK AGILE CMMI
On est cette fois dans le projet. Le sprint 0 est le moment idéal pour compléter un travail probablement initié auparavant (business oblige !). J’insiste pour que cette démarche soit collective : l’identification des risques par des équipes pluri-disciplinaires est en effet généralement plus riche et plus efficace. L’autre avantage est de partager cette nouvelle connaissance sur les risques du projet. L’output de cet atelier de travail « Risques » est évident : une liste des risques.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Liste des risques (XLS, PPT ou Wiki)
RSKM-SP2.2 Evaluer et catégoriser chaque risque identifié en utilisant les catégories et les paramètres de risques établis et déterminer leur priorité relative.
OK AGILE CMMI
Cette pratique va de pair avec la précédente, et se traite au cours du même atelier de travail puisque les risques identifiés sont catégorisés et priorisés selon les paramètres établis dans le petit guide de gestion des risques.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Liste des risques priorisée (XLS, PPT ou Wiki)
RSKM-SP3.1 Développer un plan d’atténuation du risque pour les plus importants du projet tel que défini dans la stratégie de gestion des risques.
OK AGILE CMMI
RSKM SP3.1 , tout comme la pratique suivante RSKM SP3.2, ne se limite pas à l’atténuation des risques mais traite aussi du plan de contingence pour les risques avérés. Ces pratiques sont les forces de l’Agilité. Ce travail permanent est médiatisé par l’Agile Risk board qui fait de la gestion des risques l’affaire de tous. La pratique est donc collective même si le ScrumMaster y joue un rôle essentiel : facilitateur dans l’âme sur toutes ces questions, il est là pour lever (avec l’équipe) les obstacles se dressant devant elle. Il est par ailleurs aisé d’ajouter un volet Risques sur un Backlog de Sprint et d’y maintenir une sorte de Top Ten des risques. Sur les projets que je coache, c’est le ScrumMaster qui gère les Backlogs produit et de Sprint qui s’en charge. A tous les RDV de chaque sprint, les risques sont donc identifiés, analysés et gérés collectivement.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Agile Risk Board, Réunion de planification, Daily Scrum, Revue de sprint, Rétrospective
RSKM-SP3.2 Surveiller périodiquement le statut de chaque risque et mettre en œuvre selon les besoins, le plan d’atténuation du risque.
OK AGILE CMMI
Le management visuel : quel atout pour l’agilité !
l’Agile Risk Board permet beaucoup de choses mais plus formellement chaque début (réunion de planification) et chaque fin de sprint marquent des jalons essentiels pour la gestion Agile des risques: volet dédié dans l’ordre du jour, fiche de synthèse à chaque fin de sprint incluant une partie risque, ce sont des passages obligés dans une perspectivel Agile-CMMI.
Qui : ScrumMaster - Product Owner - Equipe
Quoi : Agile Risk Board, Réunion de planification, Daily Scrum, Revue de sprint, Rétrospective
3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES
RSKM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI
En somme pour RSKM, les 3 objectifs de préparation, d’identification, d’analyse et d’atténuation doivent être atteints.
RSKM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI
Cet objectif est nécessaire dans les contextes CMMI et Agile CMMI. Comme pas mal d’autres domaines de processus (par exemple La gestion des exigences), il ne nécessite pas forcement une adaptation des pratiques Agiles, mais plutôt un élargissement de celle-ci à l’entreprise : « J’ai réussi un projet agile, et je souhaiterais capitaliser et faire en sorte que mes autres projets en bénéficient ». Des expériences que je capitaliserais à nouveau pour les améliorer.
On parle donc de PROCESS AGILE et d’ENTREPRISE AGILE.
RSKM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des risques…
OK AGILE CMMI
C’est un élément incontournable de mon Process Agile. Je m’appuie généralement sur le sponsor pour travailler cette directive qui vient d’en haut. Le plus souvent, elle reste générique (portant sur les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la gestion « agile » des risques . C’est en quelque sorte officialiser ce mode de gestion dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes
RSKM-GP2.2 Planifier le processus Gestion des risques…
OK AGILE CMMI
Une adaptation des pratiques agiles est nécessaire puisqu’on doit introduire pour chaque projet un plan de projet ou charte projet qui décrira dans les grandes lignes le Qui, Quoi, Quand, Ou du projet. Dans ce document, un volet sera consacré à la gestion des risques, décrivant le Comment sur le projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger, en s’appuyant sur le guide de gestion des risques. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.
RSKM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des risques…
OK AGILE CMMI
Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies et que l’attribution de ces ressources fut suffisante. Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog de sprint qui pourrait intégrer le volet risques, et par l’organisation d’un workshop dédié au risques en Sprint 0.. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.
RSKM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des risques…
OK AGILE CMMI
C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? On s’attachera ici à décrire l’approche résolument collective de la gestion agile des risques (portée par l’équipe du début à la fin du projet) et la forte activité de facilitation du ScrumMaster sur cette activité.
Qui : ScrumMaster
RSKM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des risques…
OK AGILE CMMI
Cela fait partie de mon travail de coach Agile. J’aborde cette problématique dans les formations aux méthodes Agiles au sein de l’organisation. L’équipe devra prendre conscience de celle nouvelle gestion et du rôle qu’elle y joue mais un effort particulier devra être mené auprès du ScrumMaster, tant son rôle d’animation et de facilitation est intense sur le sujet.
Qui : Coach Agile.
RSKM-GP2.6 Placer les produits d’activité identifiés du processus Gestion des risques au niveau de contrôle approprié…
OK AGILE CMMI
Comme sur tous les projets informatiques … Il s’agit du niveau de configuration d’éléments comme la liste des risques, ou même des photos de l’Agile Risk board placées sur le wiki. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : ScrumMaster.
RSKM-GP2.7 Identifier et impliquer les parties prenantes concernées par le processus Gestion des risques…
OK AGILE CMMI
Comme pour la gestion des exigences, un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le ScrumMaster est le responsable du plan de projet et le facilitateur de l’activité « Gestion des risques ». Pourtant, je ne l’associerai pas à l’acteur principal tant l’équipe, au quotidien, est partie-prenante.
Qui : ScrumMaster.
RSKM-GP2.8 Suivre et contrôler le processus Gestion des risques …
OK AGILE CMMI
Cette pratique consiste à suivre l’avancement des activités de gestion des risques sur la base d’indicateurs, vis-à-vis de son plan de mise en œuvre. La fin du sprint est de ce point de vue un jalon essentiel. Cela fait partie « par défaut » des attributions du ScrumMaster (également garant du process) mais un coach agile peut aussi s’impliquer dans cette pratique.
Qui : ScrumMaster - (et Coach Agile)
RSKM-GP2.9 Évaluer objectivement le respect du processus Gestion des risques…
OK AGILE CMMI
Relié aussi au GP2.2. C’est du QA. Le ScrumMaster étant le garant de la bonne application du Process Agile sur le projet, cela fait partie « par défaut » de ses attributions. Un coach agile de l’organisation ou externe peut aussi se charger de cette évaluation. Maintenant attention, le Process Agile est adaptatif…il faut en tenir compte dans le cadre de cette pratique.
Qui : ScrumMaster - (et Coach Agile)
RSKM-GP2.10 Revoir l’état du processus Gestion des risques avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI
Il s’agit essentiellement de donner de la visibilité à la hiérarchie pour que celle-ci puisse entre autres résoudre les problèmes soulevés. Et c’est justement le rôle du ScrumMaster. Il peut s’appuyer sur des éléments de l’Agile Risk Board.
Qui : ScrumMaster, Hiérarchie
RSKM GG3 : Institutionnaliser le processus en tant que processus ajusté
OK AGILE CMMI
Comme précédemment, pas facile mais nécessaire (pour la maturité 3). On est plus que jamais dans du Process Agile… du standard certes mais dans une vision adaptative et non figée, fondée sur l’amélioration continue.
RSKM-GP3.1 Établir et maintenir un processus Gestion des risques ajusté
OK AGILE CMMI
Une description du processus Agile « standard » de l’entreprise doit être disponible (dont la gestion agile des risques). Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé), Une AGILITE en CONTEXTE requise par CMMI. Oui vous avez bien entendu !
Définir le Process Agile standard, de manière collaborative et participative, cela fait partie de mon travail. Quant à l’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe, le Product Owner et le Coach Agile si nécessaire. Cette adaptation sera documentée dans le Plan Projet.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes
RSKM-GP3.2 Collecter l’information d’amélioration du processus Gestion des risques
OK AGILE CMMI
Le projet doit se servir de retour d’expérience à la fois pour le Process Standard et pour les autres. C’est très agile, c’est très adaptatif (niveau organisation), et c’est la base de l’amélioration continue. Les agilistes doivent se féliciter de cette pratique. Revue de sprint, Rétrospective de sprint et de projet sont des moments privilégiés pour cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes
BREF VOUS L’AVEZ COMPRIS, CMMI RSKM et AGILE… C’EST SANS RISQUES !
Posted by jc-Qualitystreet on 29 juillet 2009
C’est indispensable, contexte
Agile ou pas !
A tout produit est nécessairement associée une Vision, fixant le cap, donnant du sens et décrivant ce qu’on entrevoit pour le produit à court, moyen ou long terme. La vision du produit (Vision + Personas), c’est aussi et de toute façon l’élément de base de toute notre Expérience Utilisateur.
Parfois peu détaillée, souvent liée à un problème et pilotée en termes d’objectifs (rappelez-vous la Vision d’Hawkins pour le Palm Pilot en 1994 : “Fits in a shirt pocket, syncs seamlessly with PC, fast and easy to use, no more than $299″), la vision produit n’aura de sens que si elle portée et partagée, pour fédérer les équipes et se projeter dans le futur. En Scrum, méthode agile la plus populaire, c’est le boulot du Product Owner, et cela doit être bouclé en Sprint 0.
Construire la Vision, la partager et la porter: vous avez là les 3 principaux challenges de nos clients… challenges qu’un mode collaboratif “Atelier de travail” (Vision workshops), un court document de Vision construit sur la base de différentes techniques vont permettre de relever.
Voici donc un focus sur ces techniques que j’utilise pour mes ateliers Vision:
PRODUCT VISION BOX (ma préférée)
D’après Highsmith (2004). La Product Vision Box est une technique ultra pertinente au démarrage d’un projet pour construire la Vision et la partager avec l’équipe chargée de concevoir le produit mais aussi ceux chargés de le vendre.
L’équipe créée une image visuelle, concrète du logiciel ou du service qu’elle est censée développer. Le résultat final n’est toujours constitué que d’une seule boite, même si dans le cadre de l’atelier, plusieurs boites intermédiaires sont créées du fait du découpage en mini groupes.
La Box finale, se construit collectivement sur la base des précédentes, dans le consensus et la collaboration. Cette “Product Vision Box” constitue la Vision Partagée, et intègrera obligatoirement les éléments suivants:
- Front : Nom - Image (si possible) - Slogan - 3/4 Bullets arguments pour Vendre le produit
- Back : Vue plus détaillée contenant plus de fonctionnalités, les pré requis …
L’atelier a un côté ludique. Il favorise les échanges, les arbitrages, la levée de certaines incompréhensions. Le format oblige les participants à aller à l’essentiel, à prioriser. Il doit s’accompagner le plus souvent d’un travail approfondi sur les cibles, souvent amené par les interrogations et limitations éprouvées par les participants (c’est un bon point d’entrée sur les buts Utilisateurs)
Voici à quoi pourrait ressembler la Product Vision Box de ce blog QualityStreet:
Vue Devant:
Vue de derrière:
ProductVisionBox-QualityStreet
PRODUCT BOX (la plus UX)
D’après Hohmann (2006).Technique à la fois très proche de la précédente dans son format et trés différente de par sa forte connotation “Expérience & Etude Utilisateurs“. L’atelier de travail “Product Box” est résolument orienté clients, tourné vers les utilisateurs du produit final dont on récolte le feedback : on leur demande de faire une boite pour notre produit, une boite et un produit qu’ils devront vendre ensuite.
Ce sont eux qui participent aux Ateliers de travail “Product Box”; l’équipe projet / produit n’y assiste qu’en observateur. La “Product Box” constitue la Vision Client, et intègre globalement les mêmes éléments que précédemment (et plus s’ils le souhaitent):
- Front : Nom - Image (si possible) - Slogan - 3/4 Bullets arguments pour le Vendre
- Back : Vue plus détaillée contenant plus de fonctionnalités, les pré requis…
On peut évidemment exploiter les côtés de la boite comme sur les boites de céréales qui sont de bons exemples à donner aux participants.
La technique “Product Box” est très pertinente pour l’innovation. Elle est trés utile dans perspective d’amélioration du produit, ou plus simplement dans un contexte d’exploration ou de recueil du besoins. L’atelier se joue généralement dans une dynamique collective. Mais cette fois, plus on a de boites, plus on est content !
Au programme,
- 45 minutes de conception de la boite en groupe (de 3 à 6 personnes même si un travail individuel est envisageable)
- et 10 minutes pour la vendre aux autres groupes.
Au sortir des ateliers, un bon travail d’analyse des boites attend le facilitateur avant de mesurer les écarts entre ces boites et par exemple notre produit existant.
L’intérêt de l’exercice est qu’il permet d’orienter la Vision en dessinant ce que veulent les clients, comment ils envisagent le produit, ce qu’ils en attendent, ce qu’ils y trouvent de plus intéressants, ce qu’ils mettent en avant, et aussi quels arguments ils utilisent pour le vendre (faites donc venir vos commerciaux …).
Si je reprenais l’exemple de QualityStreet, je convierais 16 d’entre vous, chers lecteurs, un samedi après midi, et vous demanderais dans un premier temps de construire par groupe de 4 vos “Product Box” QualityStreet. Ensuite, je demanderais à chaque groupe, de la vendre aux autres, comme s’il était sur le marché d’Antony le lendemain !
ELEVATOR STATEMENT: “la vision synthétique” (l’indispensable)
D’après Moore (1991). On l’appelle aussi Elevator Pitch; moi je l’appelle “Vision synthétique“. C’est pour moi un élément incontournable que j’utilise systématiquement avec mes clients sur ce type de mission pour faciliter l’exploration et la compréhension.
La vision synthétique se structure en 6 parties qui résument en moins de deux minutes la Vision du produit. Je l’accompagne invariablement d’une approche Personas pour travailler les cibles sur les dimensions “POUR” et “QUI SOUHAITENT”.
POUR (public concerné par le produit)
QUI SOUHAITENT (formulation du besoin des cibles)
NOTRE PRODUIT EST (ce qu’est le produit)
QUI (le bénéfice majeur, l’utilité de la solution)
A LA DIFFERENCE DE (pratique actuelle, concurrence)
PERMET DE (éléments différentiateurs majeurs)
Une présentation en tableau de deux colonnes est très efficace mais une version linéaire marche bien aussi. Avec l’exemple QualityStreet, cela pourrait donner:
“POUR toutes les personnes impliquées dans les projets IT, QUI SOUHAITENT,
- découvrir les meilleures pratiques d’ergonomie web et logiciels
- s’informer sur les Méthodes Agiles et le Lean Software Development
- apprendre de nouvelle techniques et méthodes de travail (Expérience Utilisateur, Gestion de projet, Qualité, AMOA…)
- être accompagnées dans la mise en place de l’agilité et la conduite de projet agiles dans leur organisation,
QUALITYSTREET EST un BLOG PRO francophone, QUI aborde sous un angle nouveau les questions d’ergonomie, d’Expérience Utilisateur et de Méthodes Agiles. A LA DIFFERENCE d’autres blogs, sites ou ouvrages spécialisés, QUALITYSTREET vous offre un contenu riche, varié et pointu. Ouvert à de multiples disciplines, Il vous permet de découvrir les meilleures pratiques et d’échanger sur les méthodes les plus innovantes au service de vos projets.”
