aspexplorer (aspexplorer) wrote,
aspexplorer
aspexplorer

Le pool fugace

Dans ma boîte, on a un jeu rigolo qui s'appelle "kiki va se taper la maintenance". Je vous expose le problème : monsieur Jourdain, il faisait soit de la prose, soit des vers. Bon ben en informatique c'est pareil, soit on fait du projet (c'est à dire qu'on développe de nouvelles applications ou de nouvelles fonctionnalités pour les applications existantes), soit on fait de la maintenance (on prend en compte ce que l'on appelle pudiquement les "anomalies" et on corrige les applis en conséquence).


Lt Cmdr. Spock, du pool maintenance

Bref, un jour, y'a typiquement un malin qui sort d'une grande école et qui a une idée géniale : et si que on séparait les gens qui font la maintenance des gens qui font des projets en créant des pools dédiés ? Pourquoi ? Ben y'a une bonne raison. Les maintenances, en effet, c'est souvent urgent. Quand votre référentiel clients est en rade, quand vos chargés de clientèle ne peuvent plus encaisser un chèque, quand votre site internet vous renvoie un pot-pourri des plus beaux codes UTF-1, les informaticiens lâchent les projets sur lesquels ils travaillent pour éteindre l'incendie, c'est atavique. C'est que ça peut pas attendre deux mois qu'on ait un créneau de libre dans un environnement de pré-recette à la con, il faut s'en occuper tout de suite. Du coup, pendant ce temps, les projets, ils n'avancent pas. Et ça c'est chiant parce que si on décale le projet A, il faut aussi décaler les projets B, C et D qui en dépendent, les recaler sur le rythme des environnements de test, glisser d'une ou deux releases, bref, dans une grosse boîte avec des systèmes informatiques touffus, de la sous-traitance chez ATOS et du développement à Bengalore, ça peut chiffrer assez vite en millions d'euros ces conneries. La séparation maintenance/projet permet d'avoir une équipe qui s'occupe rapidement des anos, sans perturber l'avancement des projets. C'est-y pas une idée qu'elle est bonne ?


Le poulpe Roger

Ouais, sauf que dans la pratique, l'équipe de maintenance, elle se retrouve à s'occuper de 500 applis (c'est pas de l'exagération, c'est un ordre de grandeur réaliste) dont ils ne maîtrisent évidemment ni la technique (qui remonte parfois aux années 80) ni le fonctionnel. En outre, les anomalies, elles ne sont pas le produit des rayons cosmiques, de la pleine lune, du réchauffement climatique ou du complot des Atlantes de Mû. Elles viennent en général de projets récemment mis en production et dont les bugs ne sont pas apparus en recette (y'a toujours des trous dans la passoire). Et à votre avis, qui est le mieux placé pour corriger l'ano : celui qui a codé le programme foireux et qui est responsable de sur son appli depuis dix ans, ou le pauvre gusse qui a reçu 50 applis à gérer parce qu'elles avaient toutes un nom qui commence par J, K, L ou M et dont il ne connaît quasiment rien ? Évidemment, le développeur va trouver le truc en cinq minutes là où le maintenanceur va galérer à enquêter pendant trois jours avant de demander au développeur (qui trouvera en cinq minutes). Du coup, au bout d'un moment, un autre polytechnicien frais autant que moulu va bientôt avoir l'idée géniale : "et si on redescendait la maintenance dans les équipes projet, histoire de capitaliser sur le savoir-faire des équipes ?"

Evidemment, ça va entraîner des décalages dans les livraisons des projets... blablabla...

D'où, à chaque changement de direction, un mouvement pendulaire visant à l'apparition intermittente d'éphémères équipes de maintenance.

Mais bon, comme disait ma mémé...

Tags: belles histoires
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 20 comments