Coma Informatique

Voici la suite de notre grand feuilleton sur l’installation d’eXtreme Programming dans une dotcom. Notre directeur technique a donc décidé de mettre en oeuvre XP en même temps que la migration sous .Net. Mais il doit d’abord convaincre le management et les équipes.

Mission impossible ?

Ce n’est un secret pour personne que l’opposition des managers entraîne à coût sûr l’échec d’un changement de méthode de travail. Si les chefs n’y croient pas, les équipes n’y croiront pas non plus. Il faut donc d’abord convaincre les responsables. Et aussi les équipes, mais c’est une autre histoire (ou un autre épisode).

Dans le monde de l’entreprise on a un vieux complexe qui fait qu’on préfère s’acharner plutôt qu’avouer qu’on se trompe et corriger le tir. Ce qui fait qu’on préfère réfléchir très longtemps avant d’agir, quitte à arriver toujours en retard (et avec une solution qui n’est plus adapté). Alors vendre une méthode comme XP qui va à l’encontre de cette habitude est doublement difficile, de part sa nature poussée vers l’action plutôt que la planification, et par le fait qu’il faut d’abord avouer que l’on travaillait mal avant.

Un contexte favorable

Heureusement dans le cas qui nous occupe, le PDG de l’entreprise avait bien compris que l’absence de déploiement chez les clients, propre aux sites webs, rendait possible une politique de livraison très fréquente. Le développement se faisait donc déjà sous forme d’itérations très courte (1 par semaine en moyenne). Le client, c’est à dire l’équipe marketing produit était présent sur le site. D’ailleurs les bureaux n’étaient qu’un immense un open-space sans cloisons (c’est tellement Internet, tu comprends). Ce qui était gênant quand on travaille seul, à cause du bruit, allait devenir un vrai avantage pour le travail en binôme. Mais on en reparlera plus tard.

Comme toutes les valeurs, celles de XP sont positives, donc difficilement contestables. Mais il faut quand même qu’elles raisonnent en nous pour qu’on les suivent. Le feedback était assez facile à accepter, surtout lorsqu’on travaille sur internet où tout est très rapide. Le moindre problème après une mise en ligne d’une nouvelle version entraîne beaucoup de mail d’internaute se plaignant. A tel point que le nombre de mail reçut était un des indicateurs suivi en comité de direction (à chaque gros problème le nombre de mail reçus dans la journée augmentait fortement).

La simplicité était aussi évidente. Le navigateur n’est pas appelé le client léger pour rien. Et quand on doit sortir une fonctionnalité par semaine, on doit forcement faire simple

La communication est paradoxalement plus difficile. Pourtant avec les mails, les messageries instantanés, l’open-space, cela aurait du être une évidence. Malheureusement dans un contexte difficile, avec les licenciements passés et peut-être à venir, beaucoup d’échanges se font afin de se couvrir, pas toujours pour partager de l’information.

Quand au courage, et pour les mêmes raisons, il était un peu en berne.

La préparation

Lors d’un entretien avec le PDG, il est décidé que le directeur technique proposerait sa méthode lors d’un comité de direction.

“Mais avant tu me montreras tes slides.”

“Donc il va valoir utiliser Powerpoint. Pas de problème, après C++, c’est ma seconde langue…”

Quelques heures plus tard (et moult pompage et traduction et adaptation de documents anglais), voici la présentation. Ce n’est que le support d’une présentation orale qui dure plus de 30 minutes.

Il faut comprendre que la situation n’était pas si difficile pour l’équipe technique. Malgré la difficulté à maintenir un bon niveau de qualité, la situation était sous contrôle. Il n’y avait pas de gros feux à éteindre, mais il fallait souvent réagir en mode pompier. Notre directeur technique bénéficiait d’un crédit de confiance suffisant pour pouvoir imposer sa méthode. C’est sans doute un point crucial dans le succès de ce type de démarche.

Le grand jour

Le PDG est convaincu par la présentation, puis vient le jour du comité de direction.

Évidement puisque le PDG est d’accord, tout est joué d’avance, XP sera mis en oeuvre. Par contre il faut convaincre les autres managers de ce que cette méthode va leur apporter, parce que sinon l’échec est garanti.

La réunion se passe plutôt bien.

Le responsable relation client, un pur méthodiste, est globalement satisfait qu’on se décide enfin à utiliser une méthode, même si elle lui semble exotique.

Le directeur marketing est plus méfiant. Il sent que ce qui est une force de XP, l’implication du client, et le fait qu’il est seul à décider de ce qui est fait et du planning, sans pouvoir imposer les délais autrement qu’en réduisant la porté fonctionnelle, lui donne une plus grande responsabilité. Évidement, quand les développeurs redonne du pouvoir au client, il a forcement une plus grande responsabilité. Mais un manager ne peut pas refuser une responsabilité, surtout quand elle était déjà dans ses attributions. Alors il accepte de bonne grâce.

Le directeur commercial ne comprend pas de quoi on parle, alors évidement il accepte.

Quand au directeur financier, vu qu’aucun achat de matériel ou de prestation n’est nécessaire, il n’a aucune objection.

Dans la foulé, devant tant d’enthousiasme, on décide aussi de mettre en oeuvre la méthode en même temps que le passage à .Net, lors de la réécriture d’un des produits.

Maintenant il faut convaincre les équipes, et surtout mettre la méthode en oeuvre

A suivre

Note : Bien qu’inspirés de faits réels, les personnages et les situations sont inventés de toute pièce… évidement.

Cet article a été publié par Alexis KARTMANN le Mercredi 13 avril 2005 à 22:17 et est classé dans Tags:extreme programming, programmation
.
Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.