→ "Bref ... mon développeur se fout de ma gueule !" ★ Chef de Projet Malin

« Bref … mon développeur se fout de ma gueule ! »

C’est ce que j’aurais pu me dire compte tenu de la situation ! Mais 1) Paul n’était pas « mon » développeur et 2) il n’avait aucune mauvaise intention à mon égard, enfin .. je crois !

Je venais de reprendre un projet. Le chef de projet avait été envoyé en mission longue durée chez un client et le projet se retrouvait sans pilote. Fort de ma première expérience de chef de projet (vous comprendrez l’ironie …), on m’affecta le rôle de chef de projet pendant cette phase si délicate qu’est la phase de recette.

Je n’étais pas complètement étranger au projet puisque j’avais participé à l’analyse fonctionnelle, la modélisation de la base de données et la reprise de données.

Phase de recette donc. Celle-ci est assez difficile. Les tickets remontés par le client sur le gestionnaire de bugs s’accumulent et les livraisons successives n’arrivent pas à satisfaire le client. Difficile de reprendre un projet au forfait dans ce contexte mais quand il faut y aller, faut y aller …

Parmi les symptômes, plusieurs tickets reviennent d’une livraison à l’autre. Ce qui est sensé être corrigé ne l’est finalement pas. Le client commence à en avoir marre de retester la même chose et il commence à le faire savoir.

La correction d’anomalies : l’histoire sans fin

Je refais donc une passe sur les tickets, je les qualifie, je tâche de les reproduire et les renvoie éventuellement chez le client avec une demande de précisions. Pour les anomalies avérées, je les affecte aux personnes de l’équipe pour correction. Une fois corrigées, les tickets prennent un statut pré-recette. Et avant de livrer, je vérifie que la correction est bien en place pour chacun de ces tickets.

Et heureusement ! je tombe sur des tickets soi-disant corrigés qui ne passent pas les tests. Je vérifie un peu le cas de test, je reboucle avec Paul, le développeur pour le contenu de la spécification et le résultat attendu et je rebascule le ticket à « En cours de traitement ».

Je bascule sur un autre projet. Je reviens en fin d’après-midi sur cette liste de tickets.  Rebelote, je passe en revue les corrections, vérifie que c’est conforme et valide la plupart. Sauf un !

Je fais la remarque à Paul. Je l’aime bien Paul, il est toujours de bonne humeur, souvent prêt à lancer une blague et à rire à celles des autres. Mais là, cela fait 2 fois qu’il travaille sur cette anomalie et je n’ai pas envie d’y passer la nuit. Mon ton est très légèrement agacé mais prudent, sait-on jamais, je ne teste peut-être pas comme il faut … :

« C’est toujours pas bon, Paul, pour le ticket #913, je passe toujours pas le contrôle du formulaire, tu peux vérifier, s’il te plaît ? »

Sans rentrer dans des considérations techniques, il s’agit simplement d’un formulaire web, certes complexe mais sur lequel on applique de simples contrôles pour valider les données saisies par l’utilisateur. Par exemple, un code postal doit contenir 5 chiffres, sinon c’est qu’il y a un problème. Et je n’arrive pas à passer le contrôle avec une donnée pourtant « bonne » d’après ce que je comprends.

Je sens que Paul s’active au bureau de l’autre côté. Ca tapote fortement sur le clavier, la souris s’agite un peu et au bout de 30 secondes, j’entends :

« Ah oui, ça devrait être bon maintenant ! »

Je lui réponds : « T’es sûr hein ? » avec un sourire en coin pour lui faire comprendre que ça fait 3 fois qu’il repasse dessus quand même …

« Oui oui ! » qu’il me dit avec le même sourire ..

Développeur trop confiant pris en flagrant délit !

http://owni.fr/Ok ! Je reprends mes tests, j’ouvre le formulaire, je saisis à nouveau mes données de test et … ça ne marche pas ! Rrrrrrrrrh ! la règle est quand même simple, c’est juste une condition, Paul assure bien techniquement d’après ce que je « sais », ça devrait pas lui échapper, je pense.

Je m’apprête donc à faire la remarque à Paul .. et finalement décide de ne rien dire pour le moment. J’aimerai d’abord jeter un coup d’oeil au code source. Après tout, c’est une simple condition à implémenter, je dois bien pouvoir comprendre si je teste bien ce qu’il faut.

Je trouve l’endroit exact où ça se situe. Et là, je tombe sur une condition qui, manifestement, ne peut être jamais vraie, le résultat sera toujours faux quelles que soient les conditions. C’est comme contrôler que le champ « code postal » doit contenir que des lettres : quelque soit le code postal numérique que je rentre, ça ne marchera jamais.

Je vérifie mon hypothèse en modifiant le code. Effectivement, cela fonctionne maintenant. Je remets le code comme il était avant et me laisse 10 secondes pour décider quoi faire …

« Paul, tu l’as testé le ticket #913 ? »

« Oui oui pourquoi ? »

« Tu peux venir voir ? je comprends pas un truc là … »

Paul se lève et vient à côté de moi.

Il m’a regardé. J’ l’ai r’gardé. J’lui ai montré l’écran avec mon doigt. Il a regardé mon doigt sur l’écran.

J’lui ai dit : « Y’a un truc que je ne comprends pas, explique-moi comment cette condition peut être vraie. »

thegazettepowa.blogspot.com

Il m’a dit : « Ah ben … jamais apparemment .. »

Il m’a regardé. J’ l’ai r’gardé.

J’lui ai dit : « Et comment il peut marcher alors le ticket #913 ? »

Il m’a dit : « … »

5 secondes de silence. Tout est dit. Il est déjà reparti à sa place pour corriger. Je lui lance une remarque pour qu’il teste cette fois avant de me dire que c’est corrigé. Il me sourit. Je lui souris. On s’est compris … Ajouté à cela que la moitié du plateau a entendu la conversation, Paul a été un peu plus rigoureux ensuite … mais je veillais au grain.

La confiance, ce n’est pas une question de politesse

Alors je mets fin directement au potentiel débat que les développeurs sont des fainéants qui ne testent pas, ce n’est pas l’objet de cet article, ce n’est bien sûr pas vrai et je respecte complètement la difficulté du métier. Alors bien sûr, ils doivent tester. Mais tout le monde doit tester et vérifier son travail quel qu’il soit, chef de projet, développeur, commercial … soi-même ou avec l’aide de quelqu’un d’autre d’ailleurs.

Je souhaite simplement mettre en évidence que par défaut, il ne faut pas faire confiance. Si vous ne connaissez pas la personne, si vous n’avez jamais travaillé avec et même si vous avez entendu beaucoup de bien de cette personne, ne faites pas confiance par défaut. Testez cette personne dans le contexte particulier où elle évolue pour vous faire votre propre opinion.

Si j’avais fait confiance et que je n’avais pas vérifié, j’aurais effectué une livraison en disant au client que c’était corrigé alors que ça ne l’était pas. Et pour remonter la satisfaction client, ça n’aide pas …

La confiance, ça se gagne petit à petit, au fur et à mesure que vous déléguez des tâches. Bien sûr, il peut y avoir des loupés, cela arrive à tout le monde. Mais, pour éviter les problèmes, mieux vaut éviter la solution de facilité de faire confiance par défaut. Ensuite à vous de voir à partir de quel moment vous décidez d’accorder votre confiance.

NB: sur le même sujet, je vous explique pourquoi j’ai une confiance très limitée envers les agences immobilières : le remboursement de ma caution locative

Et vous ? faites-vous confiance facilement ?

Mise à jour : je précise que cette histoire s’est déroulée en 2006 ..

Cet article a été posté dans Gestion de projet, Management.

32 réponses à « Bref … mon développeur se fout de ma gueule ! »

  1. Pingback: → L'abécédaire du chef de projet ★ Any Ideas

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Pour vérifier que vous allez mettre un commentaire humainement intelligent : * Time limit is exhausted. Please reload CAPTCHA.