Au début de la semaine dernière, je partageais une publication de The Cyber Security Hub™ qui est on ne peut plus familière et énonce les différentes raisons que l’équipe TI peut donner quand on fait affaires avec des bogues post-mep/post-prod. Cette satire est familière, comme BA, comme PO, mais en fait aussi comme client de services informatiques. Souvent, les projets numérique peuvent se retrouver dans ces situations.
Imaginez: vous allez au garage pour faire un changement d’huile, la voiture revient avec les pneus crevés. Le garagiste vous dit « J’ai pas touché à tes pneus, ils étaient probablement crevés avant, ça te prend des nouveaux pneus »… Quelle serait votre réaction, sachant que vous avez vous même amené le véhicule en parfait état à la porte du commerce?
Deuxième mise en situation: la voiture a atteint le 100 000 km de parcourus le jour du changement d’huile. L’ordinateur de la voiture exige un changement de batterie au premier changement d’huile passé 100 000km (j’invente). Le garagiste vous dit « J’ai pas touché à ta batterie, mais le véhicule ne démarre plus, il faut une nouvelle batterie et ça coute 5000$ + installation. » Quelle serait votre réaction, sachant que vous n’avez jamais entendu parlé de cette situation, et que vous aviez un budget de 50$ (normal pour un changement d’huile)…
Une solution numérique entièrement fonctionnelle peut être brisée par une simple virgule au mauvais endroit. Je vous entends! C’est la base de faire la révision du code et de trouver l’erreur en amont. Cependant, rappelez-vous que des chirurgiens oublient des outils dans les abdomens de leurs patients… pourtant c’est évident que ça ne va pas là.
Souvent (et c’est peut-être pour ça que les représentants « affaires » sont finalement apparus dans le décor de l’Histoire des projets numérique,) on a besoin d’un peu de diplomatie et de traduction pour bien faire passer le message/la nouvelle auprès d’un client. Parfois, les systèmes informatiques sont dépendants les uns les autres. Des fois, les dépendances sont « découvertes » en ouvrant le capot, d’autres fois les incidents post-prod sont provoqués par les modifications appliquées.
Heureusement, plusieurs techniques sont appliquées pour rendre improbables les mise en situations précédentes (le code review, les livraisons en continue, les tests automatisés etc). Selon moi, le nerf de la guerre dans tout cela reste la communication du problème découvert, ET sa gestion. Le client sera compréhensif si :
il a été informé des risques et des enjeux d’appliquer sa modification.
nous lui expliquons la conséquence de manière intelligible, mais sommaire.
il est mis en confiance de la prise en charge de la problématique.
Des contournements sont mis en place pour l’aider à maintenir ses opérations en attendant un correctif (ex: voiture de courtoisie).
Pour les situations critiques, c’est la capacité à se « retourner sur un 10 ¢ » qui va faire la différence. L’agilité, ça sert aussi à ça. Il faut piler sur son orgueil et aller dire au propriétaire du véhicule, « Il y a eu un pépin, laisse moi t’aider pour remettre ça en place. »
Et vous, comment gérez-vous les incidents post-prod?
