Situation n°1 : Vous regardez votre agenda, combien de réunions ont déjà été posées pour résoudre les problèmes en cours. Vous vous dites que « Ca fait beaucoup pour la journée » en terminant votre tasse de café. Et d’ailleurs combien de fois avez-vous posé une réunion pour comprendre ce problème sur la vélocité de cette équipe ? Une vélocité qui ne décolle toujours pas, mais ces réunions vous auront permis, au choix, de rajouter des développeurs, de changer des développeurs, de changer d’architecture. Beaucoup de décisions pour, au final se rendre compte que la vélocité n’augmente toujours pas … Bref, le problème est toujours là.
Situation n°2 : C’est la fin de l’année, combien de produits avez vous lancé ? Combien de ses produits ont apportés de la satisfaction pour un client ? Et combien de réunions avez vous fait pour définir ces produits ? Combien de brainstorms et d’ateliers ? Beaucoup et à chaque fois énormément d’idées et de concepts sur comment tout ça va s’articuler, pour au final se rendre compte que peu de personnes utilisent vos produits …
Si vous avez rencontré l’une des situations présentées, et qu’après toutes ces réunions vous vous demandez encore ce qui se passe réellement, alors il est temps de sortir votre chapeau de détective privé pour aller enquêter sur le terrain !
Aller sur le terrain, mais pour faire quoi ? Pour résoudre les problèmes et trouver de nouvelles idées pardi ! En Lean Management (et plus particulièrement chez Toyota) on parle de Gemba, que l’on peut traduire en français par « Là où se trouve la réalité ». Essayons de déconstruire le mot « réalité » tout en gardant une perceptive liée au lean management. Cela signifie que c’est l’endroit où la valeur ajoutée est créée, c’est aussi l’endroit où les problèmes apparaissent et enfin c’est là où votre client obtient de la satisfaction.
Et pour bien comprendre ce qu’il se passe sur le Gemba, il va falloir utiliser votre chapeau de détective !
Comment utiliser le chapeau de détective ?
- Quand le problème apparaît, ne tentez pas de le résoudre tout de suite, en travaillant à distance.
- Vérifiez les éléments corrects du terrain en faisant une collecte méthodique des données.
- Investiguer en ayant l’attitude d’un détective privé, d’un enfant curieux ou d’un journaliste.
- Poser des questions de préférences ouvertes.
- Souligner les différences sans heurter.
Exemples 1 : Pour comprendre cette histoire de vélocité qui n’augmente pas, allez binômer avec un développeur. Il est fort possible qu’il travaille sur du code legacy qui a une forme similaire à celle-ci :
try { final String[] proprietes = Synonymes.AppelSynonyme("fourchette"); for (final String element : prop) { for (final String element2 : proprietes) { final RE exp = new RE(digit + "\\s?" + element2 + "\\s?" + digit + "\\s?" + element, RE.REG_ICASE); final REMatch fourchette = exp.getMatch(texte); if (fourchette != null) { final RE num = new RE(digit, RE.REG_ICASE); final REMatch[] data = num.getAllMatches(fourchette.toString()); v[0] = data[0].toString(); v[1] = data[1].toString(); } } } } catch (...) {
Posez les questions suivantes :
- « Peux-tu m’en dire plus sur le code que tu es en train de refactorer ? »
- « Quelle est l’intention du refactoring sur lequel nous sommes en train de binômer ? »
- « Quel est la plus petite amélioration du que tu souhaites introduire dans le logiciel ? »
- « Quelles sont les règles de développement de l’équipe ? »
- …
Exemples 2 : Sur le prochain incrément à développer, passer une journée chez votre client, celui qui utilise votre application :
- Restez un observateur passif et noter ce que vous voyez
- Participez à leurs différentes activités
- Binômer avec eux sur leurs tâches quotidiennes
Posez les questions suivantes :
- « Peux-tu m’en dire plus sur l’utilisation que tu as du logiciel ? »
- « Quelles sont les types utilisateurs de cette application ? »
- « Quelle serait l’idée complètement farfelue qu’il serait intéressant de développer ? »
- « Quel est le comportement que tu trouves le plus aberrant dans ce logiciel ? »
- …
Source du pattern : « More Secrets Of Consulting » Gerald Weinberg
A Retenir :
Nom : Le chapeau du détective
Motivation : Le chapeau du détective nous permet, sans jugement, d’observer et collecter des données, d’analyser, de trier des entrants et des options, de chercher à comprendre et de venir avec des explications rationnelles.
Forces : Permet d’obtenir l’information la plus riche sur votre projet avec le plus grand respect pour l’équipe que vous observez.
Applicabilité : Utiliser le chapeau du détective quand vous manquez d’information pour résoudre un problème.
Conséquences :
- Permet à un manager, un coach ou un tech-lead de trouver la source d’un problème
- Permet à un manager, un coach ou un tech-lead de connaître les points de satisfaction d’un client
- Permet à un manager, un coach ou un tech-lead de fonctionner en empathie avec son équipe
Implémentations :
- Le demandeur débute en posant la question par « Peux tu m’en dire plus à propos du [sujet important sur lequel il faut plus d’information] ? »
- Continuer en ne posant que des questions ouvertes
- Celui qui répond aux questions peut en passer certaines si ça l’embarrasse trop
- Le demandeur s’arrête quand il n’a plus de question
- A la fin si le demandeur a une suggestion à proposer, il demande à la personne si elle souhaite l’entendre
Suggestion d’articles :