1

Mais non, je ne parle pas de mise à pied, je fais référence au ménage dans les bugs. Êtes-vous du genre à tout reporter au lendemain? À repousser au maximum le moment où vous devrez vous creuser les méninges pour corriger un problème de longue date au lieu de tripper dans la nouveauté? Si oui, il faut vous responsabiliser!

Voyons, toutes les entreprises dignes de ce nom ont bien un logiciel pour l’inventaire des bugs actifs. Si vous sortez un petit rapport dans le genre « liste des bugs ouverts tous projets confondus » et que vous incluez la colonne « date d’ouverture de l’anomalie », risquez-vous de trouver des cas qui datent de la dernière guerre? Si dans la même liste, vous affichez aussi la colonne » à tester », reste-t-il quelques corps morts qui mériteraient d’être fermés une fois pour toute? Y a-t-il des bugs « tiroir » qui commencent avec un vague problème d’interface et qui – tant qu’à y être – se muent en remplacement du moteur de recherche? Si oui, probablement que personne ne s’intéresse à vos statistiques et donc à ce que vous faites. C’est triste mais c’est ça!

Commençons par nous organiser un peu. D’abord, réglons les corps morts. Un bug est fixé – testons-le et fermons-le s’il est OK. Il est encore problématique… ne tombez pas dans le piège du bug tiroir : si le problème initial est réglé et qu’il en a soulevé un autre, c’est un autre problème. Fermez le bug et ouvrez-en un autre. Allez, allez, ne soyez pas paresseux!

Le problème n’est pas réglé mais il faut dire que le programmeur n’a pas vraiment testé avant de livrer, on réouvre – et hop, un petit coup de marteau pour lui rappeler de faire son boulot correctement. Gardez donc en note le nombre de fois que les bugs doivent être réouverts pour cette raison. Cette statistique vous permettra de rencontrer le programmeur (en présence de son patron) et de lui proposer un poste temporaire dans une chaise de QA pour le sensibiliser au problème!

Le problème n’est pas réglé mais on ne peut blâmer le programmeur, la description du problème était, on ne peut plus succincte. Voulez-vous vous donner la peine de documenter clairement svp? Allez, allez, ne soyez pas paresseux! Personne n’aime perdre son temps!

Suis-je bête! Je n’ai même pas encore fait allusion à la sévérité/priorité. Révisez-moi tout ça et soyez gentil d’inclure votre client dans la conversation. Vous allez vous rendre compte que sa vision des choses est peut-être différente de la vôtre et que tout compte fait, c’est son produit après tout! Vous n’êtes pas d’accord avec lui? Pas de problème, exposez-lui votre point de vue mais à la fin, n’oubliez pas que c’est lui qui paye! Les opinions divergent de part et d’autre malgré tout et vous êtes certain d’avoir raison? Escaladez! Ça n’est plus votre problème si votre client est borné. Vous êtes le dernier point d’escalade, mettez vos objections par écrit et informez-le clairement des conséquences. S’il veut encore se pendre après ça, vous n’y pouvez rien et on ne pourra pas vous le reprocher.

Vous manquez de temps pour faire tout ça? Faut réaménager votre horaire voyons!

Je n’y comprends rien? Mais pas du tout! Je me suis farcie cette excuse si souvent que je suis devenue septique à la longue.

C’est bon, en fait, vous manquez de ressource (mine basse et résignée). Réponse : encore une excuse! Faut avoir les moyens de ses ambitions sinon, à quoi bon! Arrêtez de vous leurrer en continuant à développer de nouvelles choses et assignez donc vos ressources à la correction de bugs. Une fois par année pendant quelques semaines, ça ne fera pas de mal à personne (programmeurs) que de se souvenir qu’ils sont peut-être à l’origine de tout ça!