Compte rendu ...

Rappels pour ceux qui auraient manqué les épisodes précédents.
L'équipe dont je fais partie a réçu des demandes pour corriger les coquilles d'une application existante. Notre hiérarchie a décrété que cet outil historique devait être remplacé car il entraine trop de support pour l'équipe. Cela est principalement dû au fait que les membres de l'équipe sont obligés d'imputer sur le support à cet outil toutes les tâches orphelines (même sans rapport avec le support ou l'outil). Nous avons insisté sur le fait que l'ensemble de logiciels qui a été retenu comme nouvel outil ne remplace pas toutes les fonctionnalités de l'outil existant. Malgré cela, nos chefs ont décidé d'imposer cette solution à tous les projets utilisant l'ancien outil. Nous avons donc développé une solution de remplacement, et ce sans demander leurs besoins aux utilisateurs.

C'est à ce moment là que les athéniens s'atteignirent ...

À la recherche d'un projet pilote à même d'utiliser la solution maintenant quasi finalisée, les opinions divergent. Mon manager estime qu'une autre filliale que la notre serait bienvenue, car elle donnerait du poids au projet politiquement; ce serait alors un peu moins une solution "interne". Un membre de l'équipe estime quant à lui qu'il vaudrait mieux un petit projet simple, pour valider un début purement technique avant que d'entreprendre plus avant.
Les débats font rage, mais je n'y participe que très peu; ayant décidé de prendre de la distance avant de succomber à une nervousse braique donne. C'est alors que le membre de l'équipe propose de mettre en place une réunion avec les utilisateurs pour qu'ils donnent leur avis sur la question.
Un peu dans le brouillard, je n'ai compris sa stratégie qu'en décompressant une fois les débats terminés. Le but n'est pas tant de demander leur avis au client que de leur présenter le projet pour qu'ils démontent notre solution point par point (un peu comme dans la DADVSI).
Proprement machiavélique. ;->

... que les perses se percèrent ...

La réunion est mise en place. Mon manager tente plusieurs fois de la déplacer pour pouvoir y participer. Sans succès. La réunion aura donc lieu sans lui. Grand bien nous fasse. Une salle de visio conférence est réservée. Les interlocuteurs pertinents sont convoqués. Et in fine, la-dite réunion a lieu.
D'entrée, ça tape dure. Les utilisateurs ont l'impression d'un "grand bond en arrière", ils nous demandent pourquoi il a été décidé de changer l'outil, qui l'a demandé, qui a choisi et pourquoi la solution proposée n'offre pas les même fonctionnalités que la solution existante. Sur la défensive, je commence à raconter ma vie: "On ne fait pas en quelques semaines hommes, la même chose que ce qui a été obtenu au bout de la quatrième version en plusieurs années hommes."
Et c'est à ce moment là qu'arrive le sauveur, le messie, que dis-je, Dieu lui même: mon manager. (Putain mais qu'est ce qu'il fout là lui ?)
Après s'être présenté, il répond aux questions des utilisateurs. Il explique les demandes de corrections, le support. Il ajoute que l'outil est "vieux" (10 ans) qu'il utilise des "vieilles" technologies (XML et Java entre autres), donc qu'il faut le changer.
En ce qui concerne la non adéquation aux besoins des utilisateurs, il commence par parler de son concept de starter kit. Il a découvert ce mot récemment et le remet maintenant à toutes les sauces. D'après ce que j'ai compris de cet argot de l'informatique moderne, un "starter kit" est un ensemble de squelettes de programmes de base pour un environnement de développement donné, qui permet aux développeurs de disposer d'exemples concrets prêts à l'emploi. Dans l'esprit de mon manager, il s'agit d'une application "de base" que les utilisateurs pourront améliorer à l'envi sous leur responsabilité (donc plus de support pour son équipe).
Objection des utilisateurs: "donc vous déportez votre travail sur les utilisateurs". Et moi de jubilier intérieurement en criant dans ma tête "¥€$ !" tout en pompant mentalement de l'air avec mon poing.
Belotte.
Mon manager n'ayant pas plus de caractère qu'un beignet, il dit oui à tout ce qu'il ne comprend pas pour ne pas passer pour un abruti (plutôt que de l'ouvrir et de ne laisser aucun doute à ce sujet), tout en supposant que son interlocuteur doit avoir raison. En quelques minutes d'explications avec les utilisateurs aguerris, il accepte donc de s'engager à mettre en œuvre une solution isofonctionnelle. Méfiant, un des utilisateurs demande même explicitement à ce que cette promesse soit consignée dans le compte rendu de réunion.
Re belotte.
Pour noyer le poisson, mon manager enchaîne ensuite avec des retours d'utilisateurs ayant déjà migré (sous un autre outil) et qui sont fort satisfaits. Il se tourne vers moi en demandant: "on a bien fait pareil pour les projets X et Y ?". "Ben non" lui réponds-je "le projet X, on n'a pas de nouvelles et on ne sait pas ce qu'il fait; quant au projet Y, ils ont galéré et ne sont pas contents de la solution qu'on leur a proposé".
Et dix de der.
La réunion continue. Je note qu'il dit "j'ai", puis "on a", et ensuite "j'ai ... enfin on a". Bref, on sent que ça le titille de prendre le dossier à son compte. Mais comme il a compris qu'on jouait "Chroniques d'une vautre annoncée", il doit hésiter.
La réunion se termine et j'ai droit a une "petite mise au point" (sur les plus belles images de ma vie): "Il ne faut pas me contredire devant les clients, ça la fout mal. Il faut être plus positif tu comprends. Mais bon je ne suis pas au courrant de tout donc si je dis des bêtises, il faut pas hésiter à me corriger."
En une poignée de phrases, il a dit quelque chose et son contraire. Un des us dont il est coutumier.

... que les satrapes s'attrapèrent ...

La rédaction du compte rendu commence. On a tiré à boulets rouges sur le travail de l'équipe mais tous ses membres sont d'accord pour ne pas passer la chose sous silence. Si l'histoire c'est ce que racontent les vainqueurs, ce qui s'est dit en réunion, c'est ce qu'ont écrit les rédacteurs du compte rendu. On ne va pas laisser passer cette occasion de pointer du doigt les dysfonctionnements organisationnels que nous subissons au quotidien.

En parallèle, notre n+2 nous convoque pour un point sur l'avancement du projet. Le compte rendu n'est pas terminé, mais on compte bien lui exposer les grandes lignes. Mon manager passe dans le couloir et nous voit avec son supérieur. Sentant certainement instinctivement le danger, il s'invite au point d'avancement.
Le même manager convaincu de la nécessité d'une solution isofonctionnelle lors de la réunion explique maintenant qu'il en est hors de question et défend bec et ongles la solution starter kit; soutenue par le n+2. Ce dernier nous explique d'ailleurs que ce sera comme ça et pas autrement et il nous demande d'aller l'expliquer aux utilisateurs. On a l'impression d'un général envoyant ses soldats à l'abatware.

Dans le même temps, il nous faut mettre à jour notre planning prévisionnel pour le projet. Ça c'est important pour mon n+2 et je réalise qu'au début du projet on a fait un planning mais on n'a pas fait de cahier des charges. Et pour cause: on s'est assis sur les besoins clients. Je devais avoir la tête complètement dans le guidon pour ne pas tiquer avant. À ma décharge, j'évolue dans une dimension parallèle qui me fait tolérer les comportements les plus abérrants.
C'est quand même symptomatique du fonctionnement de notre filliale. On regarde combien un projet va coûter, qui va faire quoi et quand mais on se contrefout de ce dont les utilisateurs ont besoin, ou de comment on va l'implémenter. Plus tard, une personne d'un autre projet de la même filliale me dira que si on avait eu un cahier des charges, il aurait sans doute changé toutes les semaines comme pour sont projet.

Le lendemain, notre manager demande à relire le compte rendu. On s'inquiète car il a été écrit de façon on ne peut plus partiale. Il va forcément le voir et le corriger; copier coller des phrases faisant ainsi perdre au texte sa substantifique moelle.
Que non point !
Il trouve juste qu'un paragraphe est mal placé, il faudrait mettre nos arguments en face de ceux de nos détracteurs. Il déplace donc le paragraphe incriminé avant que je lui fasse remarquer le manque de cohérence et qu'il annule la modification. Il propose alors de récrire le paragraphe en démontant les arguments des utilisateurs mais ... ne trouve aucun contre-argument.

Il dit que le document lui convient et qu'il va le soumettre au n+2 pour validation avant envoi. C'est marrant parce que le n+2, lui, n'a pas le moins du monde participé à la réunion. On espère seulement que notre surchef va lire le fichier en diagonale et faire confiance à son subordonné. Si ça ne marchait pas tout le temps comme ça, on n'en serait pas là où l'on en est actuellement.

... et que les mèdes s'emmerdèrent.

Maintenant l'avenir propable prévisible.
À très court terme, le n+2 devrait s'apperçevoir qu'on va exploser les délais au niveau du planning. On va demander des ressources supplémentaires parce que c'est mal organisé et qu'on manque de temps. On va nous rajouter un responsable projet qui nous fera perdre encore plus de temps en paperasserie pseudo-organisationelle au lieu de changer de manager et de rajouter un membre à l'équipe actuelle.
Et j'ai bon espoir qu'à moyen terme, le même n+2 réalise enfin que l'ancien outil ne nous demandait pas tant de support que ça, puisque cette année les membres de l'équipe n'ont pas imputé les projets orphelins sur le support de l'outil historique.
Là, ça va être fun.