badges_flammes.jpg

Concrètement :

  • Bombe nucléaire = ça va nous exploser à la figure un jour et ça va faire mal
  • Pompier = ça a explosé, à réparer sans trainer

Il a vu l'idée dans Lean from the trenches. C'est tout nouveau donc je n'ai pas encore de feedback sur son système. Mais j'ai hâte de voir !

Des bombes pour la gestion des problèmes

J'utilise aussi le principe de bombe pour des sujets plus moyen-long terme, également sur le tableau.

Concernant la gestion des problèmes de fond, une feuille A5 avec une bombe nucléaire [1] est affichée pour chaque sujet qui risque de nous exploser à la figure. A chaque fois qu'on a un incident à ce sujet, je rajoute un petit post-it avec le numéro du ticket dessus.

exemple_probleme.jpg

Quand la feuille commence a être pleine, il devient vraiment urgent d'arrêter de juste contourner l'incident pour passer à la résolution de fond. Par exemple, pour un traitement qui plante parce que l'export dure un peu plus longtemps, un contournement consiste à augmenter le timeout. Rapide, pas cher, pertinent car il faut rétablir le service le plus vite possible. Quand c'est "résolu", ni l'équipe ni la direction n'a vraiment envie de revenir sur le sujet.

Le problème est qu'à force de faire des patchs à l'arrache sans changer les mécaniques (trop cher!), on fini par payer le prix fort. C'est dur de mettre la nouvelle fonctionnalité qui déchire en standby "juste" pour remplacer le logiciel en C que personne ne peut maintenir. Après tout, "ça marche là".

Typiquement, les bombes de chez nous concernent les dettes techniques sur l'architecture, en général des briques transverses, donc difficile à faire évoluer car impliquant plusieurs équipes.

Et pour les demandes insistantes de l'équipe

Les bombes me permettent aussi de noter certaines demandes des équipes pour monter des dossiers auprès de ma direction, comme des besoins en recrutement sur des outils particuliers.

L'autre avantage est de sortir du ressenti "je dis qu'on a besoin de ça depuis 2 ans et tout le monde s'en fout" dans la mesure où l'on note des conséquences concrètes de ces manques. Nous partons sur des impacts négatifs concrets, des faits. Par exemple, tel jour, j'ai perdu 1/2 journée à cause de la base de dev qui ne répondait pas.

L'avoir sous les yeux empêche le manager d'oublier ce sujet, ainsi que l'équipe.

C'est surtout utile pour les demandes un peu touchy qui nécessitent plus d'arguments, ou qui sont récurrentes mais sur lesquelles la réponse peut tarder à venir. Cela peut concerner des machines à remplacer ou un DBA à recruter.

Et vous, quelles sont les particularités de votre tableau ?

[1] Le template est sur github.