« Non mais là c’est vraiment de leur faute, ils nous ont construit un package qui ne fonctionne pas, ils auraient dû au moins le tester ! »

Un package est un logiciel conditionné pour être déployé massivement sur un grand nombre de machines. Plutôt que d’intervenir manuellement des centaines de fois, on crée un package et on donne un ordre, le déploiement à grande échelle est alors automatique. Nous reviendrons sur cette définition car tout est là.

J’avoue que j’ai hésité. Effectivement le package ne fonctionne pas, et visiblement l’équipe dans laquelle j’interviens n’y est pour rien car ce n’est pas elle qui le construit. Alors, rien d’autre à faire que de rejeter la faute sur les autres ?

Mon problème en tant que coach est double. D’une part un package qui ne fonctionne pas, donc un projet qui n’avance pas et nécessairement un client frustré à la clef, et d’autre part mon équipe qui s’apprête à tirer une conclusion qui ne lui apportera aucun enseignement et l’installera dans une posture opposée à la collaboration entre équipes.

Et en plus ce problème est important

Tout d’abord, du déploiement de ce package dépend l’avancement d’un projet de renforcement de la sécurité des postes de travail et des serveurs. Si le déploiement est arrêté, c’est tout le projet qui est arrêté. Si le déploiement introduit des failles, c’est toute la sécurité qui sera défaillante. Voilà pour les enjeux clients.

Pour l’équipe cet enjeu est aggravé du fait que si le projet est arrêté ou bien nécessite des corrections, il ne se terminera pas de sitôt et ira grossir les rangs des projets qui ne sortent pas. Une hantise pour toute équipe désireuse de stabiliser son activité et un vrai sujet pour eux.

Enfin, cette équipe démarrant son voyage Lean, il est important pour elle de saisir les occasions de pratiquer les gestes Lean. Au premier rang d’entre eux… le Gemba. Le dicton Lean dit « Si tu ne comprends pas le problème, retourne sur le Gemba », voilà sur quoi je décide de prendre appui.

Un Gemba de technique pure

Je ne sais pas bien dans quelle direction chercher, alors je commence naïvement. « Comment un package est-il distribué ? » demandé-je. L’équipe commence à me raconter l’histoire. Très vite je perds le fil, alors je passe au tableau avec un stylo. Les explications s’enchaînent et je dessine au fur et à mesure. Au final, nous avons un schéma qui représente l’infrastructure de déploiement d’un package, avec notre package en instance de déploiement.

Bien sûr il s’agit ici seulement d’une forme de Gemba, car nous ne pouvons pas aller physiquement voir comment un package est déployé. Mais nous produisons un schéma technique, ce qui n’a rien à voir avec la représentation d’un processus. C’est beaucoup plus concret.

Cette représentation technique me suggère alors une nouvelle question : « qui l’opère, dans le cas d’un déploiement de package ?« . Répondant à cette question, l’équipe place alors deux actions humaines sur le schéma. D’une part une personne chargée de construire le package, et d’autre part une personne chargée de donner l’ordre du déploiement. Aucune de ces 2 personnes n’appartient à l’équipe.

Est-ce là l’impasse que je redoutais ?

La découverte

Loin de là, et en fait d’impasse, c’est plutôt la bonne voie !

Car les deux personnes que nous avons identifiées travaillent avec des éléments et des instructions qui leur sont fournis. Et qui leur donne ces éléments et ces instructions ? … Eh oui, voilà où mon équipe entre en contact avec le problème.

L’élément déterminant dans cette histoire est la construction du package. La personne en charge de conditionner le logiciel (on dit « packager ») le fait avec la version de base du logiciel et une suite de tâche précises. Cette suite de tâche lui est communiquée par mon équipe, lui se contente de les rendre automatiques en vue d’un déploiement sans intervention humaine.

C’est l’instant de vérité. Car il n’y a pas que l’automatisation des tâches qui entre en compte dans la construction d’un package, il y a aussi la séquence de tâches elle-même. Et cette séquence de tâches est élaborée par mon équipe. Cette dernière s’arrête dans la discussion, et s’interroge sur la validité de la séquence de tâches qu’elle a communiquée.

Avec cette découverte s’achève notre histoire de ce jour, car l’équipe est sortie de sa posture « c’est de leur faute » et entre dans une réflexion sur sa propre qualité. Deux résultats que je visais au départ.

Elle finira par conclure que sa séquence est source d’erreurs dans le déploiement, mais ceci est une autre histoire.

En conclusion

La définition d’un package est désormais beaucoup plus intéressante et utile : il s’agit d’un logiciel avec une séquence d’instructions automatisées. Ces trois éléments (logiciel, instructions, automatisations) sont chacun exposés à des risques de mauvaise qualité. Tous les contributeurs à ces éléments sont impliqués dans la qualité de l’ensemble.

Notre Gemba a été de faire un schéma technique de l’infrastructure de déploiement et des actions humaines pour l’opérer. Cette façon de faire a été un véritable révélateur, pour l’équipe et pour moi. L’équipe a formalisé des choses qu’elle savait mais n’avait pas liées au problème rencontré. Quant à moi, j’ai mieux compris l’intérêt d’entrer dans les détails techniques pour résoudre un problème.

« C’est un problème de qualité », comme toujours, et cette fois l’équipe l’a identifié à l’aide d’un schéma technique.

Personnellement je retiens l’intérêt de ce type de schéma dans une résolution de problèmes. Qu’en pensez-vous ?

Contactez-nous si vous souhaitez vous aussi, aller voir (avec des lunettes « lean ») ce qui se passe dans vos logiciels : contact at operaepartners point com