neoDSI   CTO & Développeur back-end symfony
+33 6 62 75 87 89 Contact

En tant que CTO, je considère que le nombre de bugs résolus ne sera jamais un bon KPI.

En tant que CTO, je considère que le nombre de bugs résolus ne sera jamais un bon KPI. Et quel rapport avec cette image d’un cobra ? (patience jeune padawan ou petit scarabée pour les plus anciens comme moi)

Déjà, il n’y a rien qui se ressemble moins que deux bugs !

1/ La criticité
Il faut identifier l’impact réel d’un bug : combien d’utilisateurs sont touchés et quelle est la perte pour le business ?
Par exemple, un bug sur le système de paiement sera bien plus critique qu’une faute d’orthographe au milieu des CGV.
Cependant, une faute d’orthographe dans le titre h1 de la page d’accueil de ton site vitrine, ce n’est pas ultra critique, mais ça donne quand même une mauvaise impression.

2 /Le temps de résolution
Un bug peut être résolu en 10 secondes (chrono et déploiement inclus) ou nécessiter plusieurs jours de travail (lorsque tu réalises que tout est à refaire).

Tu vois où je veux en venir ?
Si ton KPI se base sur le nombre de bugs résolus, il devient très tentant de ne traiter que les bugs peu critiques et rapides à corriger. Puisque de toute façon, ton compteur s’incrémente de 1, que tu y passes 10 secondes ou plusieurs jours.

Et mon cobra dans tout ça ?
L’effet cobra est un phénomène indésirable qui se produit lorsqu’une tentative de résolution d’un problème aggrave ce même problème. En Inde, sous l’empire britannique, pour lutter contre la prolifération des cobras, une prime était offerte pour chaque cobra mort. Résultat : certaines personnes se sont mises à en élever pour toucher la prime.

⁉️ Toujours pas ?
Eh bien, un développeur « malin » pourrait coder de façon approximative, introduire quelques erreurs de frappe, puis les corriger rapidement pour faire monter ses KPI.

Alors, inutile de me parler de formules savantes pour évaluer la valeur d’un bug en tenant compte de sa criticité et du temps de résolution, qui devrait être comparé au temps « normal » de correction. Franchement, en tant que CTO, j’ai autre chose à faire que de calculer la valeur d’un bug pour un KPI qui ne veut rien dire.

Je n’ai jamais rencontré un développeur qui m’ait dit que le nombre de bugs résolus était un bon indicateur (ni le nombre de commits, ni les lignes de code écrites).


Source : https://www.linkedin.com/feed/update/urn%3Ali%3Ashare%3A7248711813465272321