La qualité ... revue et corrigée

Bon trop de contrariétés, j'ai beau essayé de négocier, Morphée ne veut pas de moi dans ses bras. Quitte à ne pas dormir autant rallumer le PC et faire un petit post édifiant.
Donc mon employeur est très porté sur la qualité. La qualité, c'est principalement une batterie d'indicateur qui permettent de dire si un projet se déroule bien ou pas et de ce fait permettent de savoir si il faut réitérer certaines méthodes ou mettre en place des actions correctives.
En gros c'est un peu comme la partie de notre cerveau qui nous rappelle que c'est pas une bonne idée de mettre sa main dans le feu parcequ'on a essayé une fois et que ça fait mal.
Maintenant certaines maladies peuvent bloquer les signaux nerveux et empécher la propagation du message nerveux de douleur, ce qui est très dangereux pour la personne car sans douleur la main reste dans le feu et finie bien cuite. PFIOU c'était long, vous êtes encore là ? Ben cette maladie c'est mon manager.
Il refuse catégoriquement de me faire ses retours dans le logiciel dédié parceque ça plombe ses indicateurs. Et pour pimenter le tout il alterne tout les moyens de communication possible et imaginable, e-mail, messagerie instantannée, communication orale, morse, signaux de fumée (bon j'exagère un peu - mais juste un peu).
La finalité : des indicateurs qui existent uniquement pour être vert ... d'où l'intérêt des indicateurs en question.
Autre fait étrange pour quelqu'un travaillant dans l'informatique, il n'a aucune notion de traitement par lot, c'est à dire que chaque notification vient indépendamment du reste, ce qui a pour effet immédiat d'empécher toute reflexion dépassant les 2 minutes.
Maintenant, si seulement ses observations étaient fondés, mais il a quand même débarqué dans mon bureau l'air grave en me disant que ça allait pas du tout, un écran sur deux ne marchait pas sur ma dernière livraison ...
Petite angoisse, sueures froide, et vérification ... on nous a demandé d'inclure des changements de structure de la base (grosse basse partagée entre plein d'applications sans versionning de base de données autrement appelée suicide collectif) venant d'une autre application. Et bien sûr sa base de test correspond à l'ancienne structure. CQFD, retourne dans ton bureau et confonds toi dans ta honte, pis au passage tu me copie 100 fois "je suis un abruti et je ne mérite pas de vivre".
Hop une petite enluminure spéciale dédicace à Schizzo (l'image est fort jolie qui plus est ça fait pas de mal).
Allez je retourne négocier avec morphée (une vraie mégère en ce moment).

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.

Collègues ...

Aujourd'hui, j'ai eu la joie de revoir un ancien externe. Celui-là même qui a fait un pot d'adieux la pénultième semaine. Il avait laissé un projet fini mais vu que les équipes de recette ont enfin testé, elles ont levé de nouveaux soucis. :-/
Il a appris son retour ce matin en appelant son nouveau client pour s'excuser de son absence dûe à une grève des transports en communs. Nouveau client qui s'est alors plaint puisqu'il était déjà prévu qu'il soit absent le lendemain pour aller travailler chez son ancien client.
Prévu ? Mon collègue l'apprenait de la bouche de son nouveau client. L'organisation et la communication, il n'y a que ça de vrai ... Du coup il est venu prester sa journée de corrections aujourd'hui.

Et mon collègue interne ? La grève ne l'a malheureusement pas arrêté. Il a passé sa journée à pester contre tout le monde.
Contre un nouvel externe d'abord; qui lui a donné trop de travail. Il faut dire que l'externe en question a fignolé le projet chez lui le weekend précédent pour ne pas être à la bourre ...
Contre son responsable interne ensuite, parce que celui-ci vérifie maintenant systématiquement le travail qu'il fait. Je peux facilement comprendre les inquiétudes légitimes du responsable connaissant les capatités de son subordoné ...

Ensuite il y a notre nouvelle collègue, qui a eu la difficile mission d'organiser une réunion. Entre demi-journées de congés, journées de formation et indisponibilités dûes aux projets, elle a reporté au lendemain, au surlendemain puis finalement à la semaine prochaine.

Et moi ? J'ai passé ma journée à lire des lignes de code cauchemardesques comme par exemple:

    int do_something( char *str )
    {
        str = NULL;
        str[10] = NULL;
        ...

Bon alors déjà, initialiser deux fois un paramètre, c'est pas terrible. Ensuite, initialialiser un paramètre chaîne à NULL, c'est idéal pour perdre sa valeur quand c'est un paramètre d'entrée. J'en ai déduit que ce devait être une valeur renvoyée par la fonction ...
Et en ce qui concerne la seconde initialisation:

1. Mettre un caractère à NULL plutôt que '\0', c'est témoigner trop de confiance au compilateur.
2. S'attaquer de la sorte au 11^ème caractère d'une chaîne inconnue, c'est présumer de la taille de la chaîne paramètre et des capacités du système d'exploitation à gérer les dépassements mémoire.
3. Enfin, tout ce joyeux foutware c'est casse margoulette quand on vient juste d'initialiser la chaîne à NULL.

Après avoir vainement tenté d'expliquer ce genre d'erreur de développement à l'une de mes collègue pendant près d'un quart d'heure, à grand renforts de justifications techniques exposées le plus didactiquement possible, je l'ai ouïe me répondre: "Ho, il est 17h, il faut que j'aille chercher mon gamin à l'école".

Et là, désolé, je ne peux plus lutter ...

Bug chaser.

Ce matin, plantage d'un service. Je commence à regarder les logs du serveur, lorsque mon manager arrive en trombe dans mon bureau. Il m'enjoint de ne pas relancer le service, ce à quoi je répond avec un œil noir que j'ai 10 ans de métier. Il y en a qui ne doutent de rien. Mais que peut-on attendre d'une personne qui à 30 ans passés dit encore: "il faut qu'on voiye ce qui se passe" ? Il me demande de regarder les logs, je rétorque que c'est ce que je suis en train de faire. Pardi !

Le problème selon lui: un utilisateur a un mot de passe avec un point. Je peux comprendre que le service ait déjà planté à cause d'une mauvaise gestion des accents et des conversions iso-latin1 / UTF-8, mais point pour un point. :-/ Pendant qu'il déblatère ses élucubrations, je me dis ce serait bien de lui apprendre l'hygiène bucco-dentaire en plus de l'orthographe. Qu'il se brosse les dents le matin ou qu'il prenne une pastille à la menthe après avoir bu son café. Tiens ... une idée marketing à creuser pour S*l*ct*.

Ensuite, il explore la voie des problèmes réseau. C'est vrai qu'ici l'infrastructure n'est pas en ligne, ni en boucle, ni en étoile mais en pointillés. Selon lui le service pourrait s'arrêter à cause des reboot des hubs. Heureusement que je lui dit pas que mon stylo bille n'écrit plus, sinon il me prescrirait un reboot de ma lampe de bureau. Il faut dire que reboot est le seul truc qu'il sache faire; alors il le vend bien: "tu comprends, quand on reboot, la mémoire est nettoyée, on est sûrs d'être clean ...". C'est ça; prends moi pour une truite.

Cela dit, un service qui ouvre des flux réseaux rémanents pour pouvoir se lancer, qui se plance si le réseau tombe et qui n'est pas fichu de redémarrer seul, c'est pas terrible. C'est d'ailleurs sans doute pour ça qu'il est encore en test sur une machine bancale au fin fond de la salle serveur. À se demander pourquoi toute l'entreprise l'utilise et la hiérarchie communique fièrement à son sujet. Bref, ayant d'autre chats à fouetter (jeu de mots), j'abandonne lâchement. Mon manager s'en retourne à son bureau et je lui crie en encouragement "bonne chance, Jim".

Il me rapelle dans l'après midi "tu peux venir s'il te plait". On note la formule de politesse postfixée, témoin de la précarité de sa situation. Je rapplique donc illico dans son bureau pour regarder ce qu'il fait (surtout le coin inférieur droit de son écran pour l'horodatage) tout en m'effforçant de présenter un air grave de circonstance.

Il recherche les sauvegardes pour restaurer la base de données tel qu'elle était la veille et découvre qu'il n'y a plus de backup depuis plusieurs semaines. Je me saisi du piano pour ne pas perdre de temps, retrouve le script d'archivage, trouve une erreur de syntaxe, la corrige et refait tourner le script. Il s'interroge: qui donc à modifié le script ? Je me retiens non sans peine de répondre: "le colonel Moutarde avec le chandelier dans la salle de bains." En tout cas ce n'est pas moi, j'étiquette systématiquement mes modifications (il faut savoir assumer). Sans réponse ni piste à son problème, il me laisser retourner vaquer.

Ce n'est qu'en fin d'après-midi qu'il trouvera in extremis la solution. Il y avait effectivement un compte avec un accent (enfin, une cédille). C'est pas comme si on avait pas déjà eu le problème ...

Hésitations

Je vois que le blog est très actif en ce moment. On sent bien que certains ont besoin d'évacuer le stress du boulot. Pour l'instant, je lis, je ne sais pas trop si je dois poster. Le risque d'être hors sujet est très grand et je ne voudrais pas démoraliser encore plus mes anciens collègues (ils n'ont pas vraiment besoin de ça en ce moment).
Les choses vont bien finir par bouger pour vous. Certains vont peut être partir, d'autres vont être remplacés.
Je vous le souhaite en tout cas.