Gérer les situations de crise (épisode 1)

Un chef de projet (fonctionnel ou technique) reste avant tout une personne qui doit veiller à ce qu’un projet se passe bien, mais quand ce n’est pas le cas doit assumer et gérer les problèmes.

Aucun projet ne se passe bien, vous aurez toujours des couacs plus ou moins importants. L’idée est évidemment de les minimiser au maximum et d’apprendre à les gérer. Quand vous êtes junior (mais certains « séniors » n’y arrivent pas), malgré votre formation, votre stage, votre capacité à analyser un problème, le résoudre vite mais bien n’est pas encore au point.
C’est normal, on apprend tous les jours (moi le premier).

Je vais donc commencer par les crises que je rencontre tous les jours, les problèmes de mise en ligne. Je ne vais pas détailler dans ce billet les best-pratice d’une mise en ligne (validation DEV, PREPROD, PROD etc). Imaginez simplement qu’un problème apparait, 2 grands type de bugs : mineur et majeur.

Mineur ( problème d’affichage sur certains navigateurs, liste déroulante qui bloque (sur une page de niveau N-5) ).

Généralement, même un chef de projet junior gardera son calme sur ce type de bugs. On constate soi-même l’erreur, on essaie de le reproduire, on le transmet à son développeur en expliquant la manipulation pour y arriver. On peut ouvrir un ticket sur un système de bugtracking (Mantis par exemple). Cela fera partie ainsi de la todo. Il faut juste veiller ensuite à ce que la todo soit traitée dans des délais raisonnables.

Majeur (inscription en base ne fonctionne pas, statistiques ne passent pas, mise en ligne de rubriques, contenus non finalisées)

Ce genre de bugs vous donne déjà plus de stress, s’il a été remonté par le client et que 5 minutes après, vous avez votre boss qui vient vous voir (et qui a reçu un appel téléphonique entre temps) , vous savez à ce moment là que la situation n’est pas propice à la blague .

Malgré tout, le point clé est de garder son calme afin de rester méthodique et être rapide.

Et c’est toujours la même procédure qu’un bug mineur, à savoir : reproduire le bug, analyser en même temps que vous naviguez les flux http (avec un logiciel comme Service Capture), identifier la page, le champ texte qui pose problème. A ce stade là, dans 75% des cas, vous aurez compris pourquoi ça ne fonctionne pas et indiqué à votre développeur ce qu’il faut corriger. Dans l’heure, le bug pourra être résolu de façon plus ou moins propre.

MAIS si vous êtes dans les 25%, allez prendre un verre car votre journée n’est pas finie. Allez voir votre développeur, reproduisez le bug avec lui. Si besoin, faites intervenir plusieurs personnes. Selon la situation, il faudra vous adapter, faire des choix (impossible à corriger, mise en ligne du backup).

Ce que j’ai essayé de faire comprendre à travers ce billet, c’est qu’être réactif pour résoudre une crise liée à une mise en ligne suppose :

1. avoir toujours sous la main un backup (soit une sauvegarde manuelle de la version en ligne, soit via SVN) pour faire un rollback en catastrophe, veiller à faire les mises en ligne avec votre développeur (malheureusement pas toujours respecté et ensuite très compliqué pour vous de connaitre les fichiers qui ont été passés etc).
2. ne pas véhiculer le stress de la partie commerciale (le client) à votre développeur, d’où l’intérêt de lui préparer la manipulation pour refaire le bug, et veiller à ce que ça soit le CP technique qui discute avec lui, faire comprendre que c’est urgent mais ne pas s’énerver (on fait ce genre de mise au point après l’incident, pour éviter que cela se reproduise).
3. restez méthodique.

Des bugs, vous en aurez tous les jours. Vous allez rapidement vous apercevoir qu’il y a toujours les mêmes solutions aux mêmes problèmes. Et en gestion technique, je vous laisse deviner tout ce qu’on voit passer. Cela permet de relativiser.

Apprenez à les gérer, l’important n’est pas toujours votre capacité à comprendre le bug (mais au moins le reproduire niveau fonctionnel), mais bien faire le tampon avec le client qui a tendance à s’affoler pour rien, et votre développeur.