Ca marche pas, démerde toi ! Ou comment mieux déclarer un bug ?

0
142
ca marche pas demerde toi - perenniser vos devs it

Ah cette fameuse phrase : ça marche pas. Vous la connaissez non ?
Combien de fois, on peut la lire ?! Combien de fois on peut la voir ! A travers cet article, je commence une série autour de la déclaration des problèmes, des fonctionnalités d’un projet. Et ainsi comment améliorer la cohésion de l’équipe et du projet.

Je tiens à remercier Dimitri Ashikhmin, patron de FWA, pour m’avoir proposé cette thématique. Thématique qui lui tient à coeur, et qu’il considère comme un point clef dans la réussite d’un projet informatique.

Pour précision, Dimitri a été mon tout premier patron, voilà presque 15 ans. Il a été et reste toujours pour moi un mentor.

Ca marche pas, démerde-toi ! Je sais pas faire autrement

Le client, la cliente qui saisit le fameux « ça marche pas », n’a pas un mauvais fond, ne l’oublions pas.
Il-elle exprime avant tout ce qu’il-elle constate et aussi, ce qu’il ressent.

Car oui, rappelons-le, souvent le « ça marche pas » est peu documenté sur le pourquoi, le comment, le où ….

En fait, personne n’a appris, de base, à bien déclarer un ticket.
Et j’irai même plus loin, personne n’a dit que c’était important … enfin, au début.

Donc, on dit ça marche pas, et c’est tout …

Ca marche pas, j’ai pas envie de t’aider, mais aidez-moi !

Ou bien c’est aussi le ça marche pas, je suis en colère.

J’ai payé pour avoir un logiciel qui fonctionne, et là … c’est le ponpon (pour ne pas être vulgaire).
Oh .. on me demande d’utiliser cet outil, et t’as vu les bugs qu’il y a ….

On voit bien ici, que c’est plus lié à du sentiment, ce « ça marche pas », plutôt qu’à un vrai ticket, avec un vrai but de décrire.

Le ticket devenant un exutoire de ce que l’on ressent, à cause de ce ticket.

Apprendre à bien déclarer

Comme je le disais plus haut, souvent, personne n’a indiqué au client, à la cliente, comment bien déclarer un ticket.
Du coup, on a oublié de dire ce que l’on attend, nous équipe de développement, nous support du contenu du ticket.

Ainsi, on voit souvent qu’on attend de l’autre ce que l’autre ne sait pas.
Et comme je dis toujours en formation de cohésion d’équipe : il faut tuer l’implicite !

Plusieurs stratégies pour y arriver

Pour avoir un bon ticket, selon l’équipe de dev, ou de support, plusieurs stratégies peuvent être mises en place. (D’ailleurs, elles peuvent se cumuler) :

  • Vous pouvez déjà proposer un patron de rédaction au client, à la cliente, aux utilisateurs et utilisatrices.
  • Vu qu’ils risquent de ne pas le renseigner tout le temps, vous pouvez aller plus loin : leurs proposer un outil (mobile, web) pour bien déclarer un problème. Par exemple, il existe l’outil proposé par Azure dev ops Test et qualité, qui le fait très bien.
  • Vous pouvez aussi empêcher la saisie en ligne, et avoir des personnes dédiées au support qui sauront poser les bonnes questions et donc sauront bien rédiger les tickets à envoyer aux équipes de développement.

On peut même y aller encore plus fort en ajoutant un parcours gamifié : récompenser les utilisateurs, les utilisatrices, avec des points, de l’expérience gagnée, des effets visuels, pour donner envie et encourager la bonne saisie des tickets.

Eduquer et valoriser

Bref, ici, nous voyons qu’il est important d’éduquer les utilisateurs et utilisatrices.

L’essentiel c’est de montrer que tout ce temps passé à saisir un bug, c’est du temps de gagner pour la compréhension du bug, et donc de sa réalisation. Quand on sait que c’est ce temps qui est lié au traitement, et donc la livraison de la correction, on peut se dire, qu’on fait bien et que nous sommes utiles, que c’est grâce à nous, client cliente, que l’équipe de développement va réussir à corriger le problème.

Vous voyez ici une vraie stratégie sincère qui va plus convaincre que d’imposer.

Le contenu d’un bon ticket

Que ça soit via un patron déjà proposé, ou bien via un outil, le contenu est important.

Nous y trouvons :

  1. Le Où

Où ça s’est passé, dans quelle page, dans quelle fenêtre, …

2. Le Comment

Comment ça s’est passé ? Quelles actions ont été réalisées ? L’idée ici étant d’être le plus précis possible.

3. Attendu

Décrivons ici ce que l’on attend, soit à chaque étape, soit au final.

4. Bugs constatés

On constate quel(s) problème(s) ?

Avoir un contenu encore plus précis

Après, vous pouvez proposer (ou imposer à vous de voir) des imprim-écrans, des photos de téléphone.
Et vous pouvez aller encore plus loin en proposant des petits films de ce qu’il s’est passé, du comment, du où, …

C’est tellement plus agréable quand on veut corriger le problème !

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici