-
Jouer avec les clients pour innover #5
Posté le décembre 6th, 2010 2 commentairesD
ernier article de la série « Innovation Games ® » avec les 4 derniers jeux. Si cette série vous a plu ou déplu, merci de rédiger un petit commentaire
Give Them a Hot Tub
Objectifs : Utiliser des fonctionnalités hors de propos (excessives) pour découvrir des besoins réels
Préparation : Etablir une liste de fonctionnalités excessives pour votre produit (par exemple un lecteur MP3 pourrait « faire du café », ou « casser du béton » ou encore « toiletter les chiens »). Faire cela en 2 réunions en interne espacées de quelques jours pour avoir des idées sympa et vous donner le temps d’être à l’aise avec ces fonctionnalités surprenantes, car il faudra tenir le choc devant vos clients.
Activités : Le facilitateur est primordial pour cet exercice, son rôle est de présenter chaque fonctionnalités puis de demander aux utilisateurs s’ils acceptent la fonctionnalité en l’état, la refuse totalement comme quelque chose dont ils n’ont pas besoin ou la transforment en quelque chose qui pourrait leur être utile. Les bénéfices du jeu sont majoritairement récoltés dans cette action de transformation d’une idée excessive en quelque chose d’utile, et il était nécessaire de surprendre vos utilisateurs pour les faire réfléchir dans une direction qu’ils n’auraient pas imaginé.
Lire la suite »
-
Jouer avec les clients pour innover #4
Posté le décembre 3rd, 2010 1 commentaireQuatrième billet dans lequel je décris 4 jeux supplémentaires
Buy a Feature
Objectif : Prioriser les futures fonctionnalités du produit
Préparation :
Listez les fonctionnalités que vous envisagez de mettre dans votre produit et associez un prix à chacune d’entre elles (vous pouvez demander au préalable à votre équipe technique d’évaluer l’effort de réalisation pour vous aider à mettre un prix mais ce n’est pas indispensable). Préparez également des faux billets de 1 ou 5 euros aux couleurs de votre entreprise/produit et les remettre aux participants en quantité égale, et faite en sorte que plusieurs fonctionnalités soient trop chères pour être achetées par 1 seul participant.Activités : Ce jeu fonctionne mieux avec un groupe réduit de 4 à 7 joueurs car la discussion est essentielle. En effet, les joueurs vont devoir discuter et s’associer pour acheter les fonctionnalités chères qui leur sont réellement utiles. Plutôt que d’avoir la réponse « je veux tout », vous mettez vos participants dans l’obligation de définir les priorités des futures fonctionnalités. Les fonctionnalités achetées en premier sont bien entendu celles qui doivent être dans la prochaine release. Bien entendu, il ne faut pas qu’il y ait suffisamment d’argent au total pour acheter toutes les fonctionnalités.
PS : C’est la technique que je pense utiliser lors des mes sessions « Mes échecs avec Scrum ! » que je présenterais en France en 2011
Lire la suite »
-
Jouer avec les clients pour innover #3
Posté le décembre 1st, 2010 1 commentaireTroisième billet de cette série dans lequel je vais vous décrire les 4 premiers Jeux Innovants dans l’ordre dans lequel ils sont présentés dans le livre de Luke Hohmann (dont il y aura 5 billets au total et non 4 comme prévu initialement … je gère le changement en mode agile pour m’adapter à ma vélocité mesurée
).Prune the Product Tree
Objectif : Mettre en forme votre produit ou service pour qu’il s’adapte aux besoins de votre marché (la traduction de « prune » est « tailler » et non « couper »)
Préparation : Demander à vos utilisateurs de dessiner un arbre sur une grande feuille de papier ou faire imprimer une image stylisée d’un arbre. Les branches épaisses représentent les parties principales de votre produit et les feuilles qui leurs sont associées sont les fonctionnalités actuelles de votre produit (à l’aide de postIT simple ou mieux encore, des postIT en forme de feuille d’arbre). Le bas du tronc et les racines de l’arbre représentent vos activités de support et d’assistance clientèle. Lire la suite »
-
Jouer avec les clients pour innover #2
Posté le novembre 28th, 2010 1 commentaireDeuxième billet de cette série qui donne les raisons pour utiliser un « Innovation Game® », des critères pour choisir le jeu qui correspond à votre besoin et comment organiser et pratiquer ces jeux. Les 2 prochains billets décriront les 12 jeux.
Pourquoi des « Jeux Innovants » ?
Pour collaborer avec vos utilisateurs de façon ludique pour mieux comprendre leurs besoins.
Choisir le bon jeu
Certains jeux donnent de meilleurs résultats suivant ce que vous cherchez à comprendre de vos utilisateurs.
- Les besoins du marché que votre produit ne satisfait pas ou ceux qui seraient idéaux pour vos clients
- Product Box, Me and My Shadow, Buy a Feature, Give Them a Hot Tub, Remember The Future
- La façon dont vos clients utilisent vos produits et les relations entre votre produit et d’autres produits utilisés chez un même client
- Spider Web, Start Your Day, Me and My Shadow, Show and Tell, The Apprentice
- Quels sont les fonctionnalités et services, offerts par votre produit, qui sont réellement utilisés par vos clients
- Product Box, 20/20 vision, Me and My Shadow, Speed Boat, Start Your Day, The Apprentice, Buy a Feature
- Comment faire évoluer votre produit dans le futur
- Remember The Future, 20/20 vision, Buy a Feature; Prune the Product Tree
Lire la suite »
- Les besoins du marché que votre produit ne satisfait pas ou ceux qui seraient idéaux pour vos clients
-
Jouer avec les clients pour innover #1
Posté le novembre 26th, 2010 1 commentaire
Tous les acteurs en charge de la définition d’un produit (Directeurs Produit, Product Owner, Business Owner, Marketing …) souhaitent répondre aux attentes de leurs clients et proposer LE produit qui va répondre à tous leurs besoins. S’ils y arrivent, le succès commercial est assuré et tout ce qui en découle sur le plan financier pour leur organisation et eux-mêmes.Il y a plusieurs façons de définir LE produit qui vous garantira le succès :
- Avoir une idée géniale
- Demander aux clients ce qu’ils veulent
- Faire contribuer les clients à la définition du produit
L’idée géniale consiste à utiliser une nouvelle technologie innovante ou une façon différente des technologies existantes, mais elle n’est pas donnée à tout le monde et son apparition reste aléatoire.
Demander aux clients est une méthode qui relève du bon sens mais qui, malheureusement, ne se révèle pas suffisamment performante car bien des clients n’arrivent pas à exprimer réellement leurs besoins avec une question aussi ouverte, ou alors reste limitée à un petit périmètre qui est constitué des problèmes immédiats des clients sans vision à moyen et long termes.
La troisième option se révèle être la plus performante et parfaitement en phase avec les approches agile. Le livre de Luke Hohmann (« Innovation Game ® ») est un recueil de 12 exercices ou jeux à pratiquer avec les clients, et qui, comme le dit Luke régulièrement, sont « des jeux qui font le travail ! » – Games that make the Job!
L’objet de cet article et des 3 suivants est de vous présenter l’approche de Luke, que j’apprécie également en tant que personne et avec qui j’avais longuement discuté à l’issue de sa présentation à Chicago, et de vous décrire les 12 jeux qui sont détaillés dans son livre.
-
Comment créer un produit que les utilisateurs détestent !
Posté le novembre 16th, 2010 4 commentaires
Article librement traduit de l’anglais : Article d’origine chez Pichler (Merci à Romain pour le pointeur)Voici une liste de comportements qui partent d’une bonne volonté mais qui sont en fait des erreurs assez classiques lors de l’application de Scrum et qui influencent négativement la réalisation du produit, et qui de plus, lorsqu’elles sont combinées peuvent conduire à un échec cuisant du produit.
- Etre trop pragmatique dans l’application du rôle de Product Owner : Pour essayer de répartir la charge de travail sur plusieurs individus ou un comité représentatif
- Viser à maximiser la diffusion du produit : Pour essayer d’avoir un produit qui contienne un maximum de fonctionnalités et qui puisse être distribué à un maximum d’utilisateurs différents Lire la suite »
-
Sessions retenues pour Agile France à Paris
Posté le avril 28th, 2010 Pas de commentaire
Après être venu en touriste l’année dernière à cette superbe manifestation, j’ai décidé en 2010 de proposer quelques sujets et 2 d’entre eux ont été retenus :- Une présentation+atelier sur les métriques pilotées par le comportement (Behaviour Driven Metrics) que j’animerais avec Manu
- Les bonnes pratiques du Product Owner mise en œuvre sur un projet qui a très bien réussi
Ce sont des créations faites spécifiquement pour cet évènement, souhaitez moi bonne chance
Voir ci-dessous pour plus de détails
-
Jouer à être le Product Owner
Posté le mars 17th, 2010 1 commentaireVenez nous rejoindre ce soir au Club Agile Rhône Alpes pour jouer à être un Product Owner en pratiquant le Business Value Game … vous verrez que ce n’est pas si facile que cela
Plus d’information sur le site du CARA : http://clubagile.org/2010/03/rencontre-agile-a-grenoble-17-mars-2010/
-
Suis-je un Product Owner Agile ?
Posté le mars 11th, 2010 2 commentaires
Dernièrement j’ai eu la question suivante :« Je suis Product Owner d’un produit réalisé en mode Agile depuis plus d’un an, est-ce que vous pensez que j’ai besoin d’une formation de Product Owner Agile ? »
La question est intéressante puisque le principe de l’agilité est un peu « d’apprendre en marchant » et donc il est tout à fait raisonnable de se poser la question de l’intérêt de se suivre une formation pour se faire expliquer le travail que l’on pratique au quotidien
-
Agilité pour MOA
Posté le mars 4th, 2010 5 commentaires
Dernièrement un client m’a demandé un court argumentaire pour inciter une MOA (le représentant du client) à se renseigner sur l’agilité. La problématique était présentée de la façon suivante : « La MOA veut savoir ce qu’est l’agilité avant de consentir à se la faire présenter ! » et il fallait donc proposer quelque chose de court, concis et percutant.Après quelques jours de réflexion, j’ai proposé le questionnaire suivant :
- Votre besoin fonctionnel est-il parfois incomplet au T0 du projet ?
- Identifiez-vous de nouveaux besoins en cours de réalisation ?
- Attendez-vous longtemps pour voir une première version ?
- Avez-vous des difficultés à vous faire comprendre de la MOE ?
- Voyez-vous vos planning dériver avec le temps ?
- Vous demandez-vous parfois ce que fait la MOE ?
- Découvrez-vous beaucoup de bugs en fin de cycle ?
- Souhaitez-vous augmenter votre productivité ?
Si vous avez répondu OUI à l’une de ces questions, alors les méthodes Agiles peuvent vous aider à mieux faire car
- La possibilité de changer le besoin fonctionnel est intégré structurellement dans la méthode
- Une version démontrable est livrée régulièrement (tous les 2 ou 3 semaines)
- Les échanges entre MOA et MOE sont permanents et riches d’enseignements
- La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression
- La visibilité est totale et permanente sur toutes les activités
- Les tests sont faits en continu pour éviter les effets « Big Bang » de fin de cycle
- Les gains de temps sur l’ensemble du cycle (de l’expression de besoin au déploiement) sont très significatifs
Avec quelques recommandations pour passer à l’Agilité
- Se former, car même si la méthode semble simple, c’est plus complexe qu’il n’y parait
- Se faire accompagner, car c’est plus difficile qu’il n’y paraît et les bénéfices seront obtenus plus rapidement
- Démarrer au plus tôt en mode Agile, c’est-à-dire dès la collecte des besoins, car tous les acteurs sont concernés et pas seulement la MOE
- Accepter et mettre en œuvre les changements induits par la méthode (réunions en présentiel, disponibilité en continu …)
- Comprendre que l’agilité est avant tout un état d’esprit et non juste une « autre méthode »
Qu’en pensez-vous ?



Commentaires récents