Faut il prioriser les bugs ?

A la suite du post “Comment prioriser” j’avais promis de parler de la priorisation des bugs.
Dans cet article j’aborde un sujet que nous mettons tous bien souvent de côté et qui est pourtant capital.

Objectif zéro bug : le mythe

A première vue, si on ne connaît rien au monde du développement, on pourrait se dire que la question est stupide.

Si vous vous placez à la place d’un utilisateur, il ne devrait avoir aucun bug, point à la ligne.

Du coup, en partant de ce principe, chaque bug est forcément prioritaire sur tout le reste.
On ne fait rien de nouveau tant que l’on n’a pas réglé tous les bugs.

Dans la réalité, cette philosophie est absurde. On ne peut pas tout corriger sinon on n’avance jamais. 

Il y a toujours un détail et petit bug que l’on peut détecter en cherchant bien.

Ainsi, afin de faire la part des choses entre les bugs à corriger tout suite, plus tard et potentiellement jamais, la notion de priorisation prend tout son sens.

Mais sur quels critères prioriser ?

Les bugs en prod

Un bug en prod est un bug visible par vos utilisateurs.
Par définition ce type de bug est forcément prioritaire car son impact est immédiat.

Les bugs reportés par les utilisateurs

Un bug en prod doit être prioritaire mais parmi ceux ci, les plus prioritaires sont ceux reportés directement par vos utilisateurs.

En effet, il est possible d’avoir des tonnes de bugs en prod invisibles ou ignorés par vos utilisateurs.

Dans ce cas, à vous de juger l’impact potentiel de ces bugs.

En revanche, si vous recevez des signaux forts venant de vos utilisateurs qui se plaignent sur tous vos canaux (réseaux sociaux, reviews AppStore et PlayStore, service clientèle, emails etc…) alors il ne faut pas hésiter, il s’agit d’une urgence.

La valeur perçue Vs la valeur réelle 

Dans l’exemple ci-dessus j’indique que les bugs reportés par les utilisateurs doivent être gérés en priorité.

Pourtant il y a des cas où ça parait déconnant :

Par exemple :

• Vos utilisateurs se plaignent d’un bug du style “la fonction désabonnement à la newsletter ne fonctionne pas”.
• De l’autre côté, vous avez identifié un bug que personne n’a remarqué mais qui peut impacter potentiellement le renouvellement automatique des abonnements clients.

Dans cet exemple, vous allez me dire

“Le 2eme est beaucoup plus important car il impacte potentiellement le CA de l’entreprise tandis que le 1er n’a aucun impact immédiat sur le business”.

Oui mais… ne négligez jamais la valeur perçue de vos clients sur votre produit.
Le premier bug impacte votre réputation et si vous ne réglez pas ce problème en urgence vous allez dégrader l’image de votre entreprise.

Le sentiment de fiabilité c’est ce qui fait que les gens restent chez vous et vous recommandent.
A terme cet indicateur a plus de poid sur le business que n’importe quel autre paramètre.

PS: Cela n’empêche pas de régler le 2eme bug dans la foulée.

Les bugs en cours de dev

En tout dernier, il y a des bugs sur des fonctionnalités que vous êtes en train de développer et que vous avez détecté en phase de recette.

Ces bugs ont également leurs importances mais tant qu’ils ne sont pas en prod, leurs impacts sont nuls.
Vous devez par conséquent les considérer moins urgents que les bugs en prod.

Prioritaires par rapport à quoi au final ?

Pour conclure, les bugs sont des éléments surprises qui viennent nous interrompre dans nos plans.

Pour ces raisons, on a bien souvent envie de les ignorer pour réussir à terminer ce que l’on à faire.

Quel développeur ou PO ne sait jamais dit :

“Je le réglerai après mon sprint ou cette issue”

Si vous voulez éviter de mauvaises surprises, ayez toujours en tête de prioriser les bugs en temps réel.

C’est la seule méthode pour savoir si vous devez changer vos plans ou maintenir votre cap.