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 !

Les réunions de suivi projet, ça permet de prendre du recul, c’est souvent tranquille, parfois drôle et de temps en temps un peu tendu, surtout lorsqu’on découvre des surprises sur un projet …

« 60% de dépassement de budget ? mais comment ça se fait ? on n’est qu’à la moitié du projet !? »

En l’occurrence, il s’agit d’un projet en crise : budget explosé, délai improbable, satisfaction client inexistante. Alors que peut faire le chef de projet ?

Voici donc quelques idées catastrophiques et géniales (excusez du peu, c’est pour coller au thème 😉 ) à éviter et à suivre respectivement …

Idée catastrophique #1 : cacher les problèmes à son responsable

« Comment ça se fait qu’on le découvre que maintenant ? »

Bonne question, merci de l’avoir posée. Personne ne suit vraiment les chiffres et un beau jour, quelqu’un regarde de plus près et le sol s’écroule sous les pieds du chef de projet.

Ca arrive dans toutes les boîtes même les plus grandes : « Ah au fait, pour l’airbus A380, on va avoir 2 ans de retard … ». Alors oui, en interne, ils le savaient peut-être avant chez Airbus mais côté actionnaires et clients ils ont dû se poser la question suivante : « Depuis quand le savez-vous ? ».

Parce que le retard, ça se prend jour après jour. Mais ça se communique beaucoup moins vite …

Votre responsable va peut-être vous sauver la mise sur votre projet, alors autant lui donner confiance et lui donnez régulièrement un avancement proche de la réalité. Sinon vous allez passer un sale quart d’heure. Et sur le projet cité en introduction, la réunion de crise a duré beaucoup plus qu’un quart d’heure …

Idée catastrophique #2 : fouetter ses équipes (inutilement ;-))

Lire la suite