mercredi 9 janvier 2013

MOA/MOE ça m'énerve !

MOA/MOE mon amour ... ou pas


Un de mes amis militaire, peu au fait des pratiques du monde merveilleux des SSII françaises m'a demandé si l'article de Pierre Schneider me parlait ou pas.

An tant qu'ancien pratiquant de l'IT à la sauce MOA/MOE française, évidemment que ça me parle, mais ça me donne aussi des nausées.

Quand est-ce que les sociétés abandonneront cette hérésie de MOA/MOE. On ne travaille pas dans le bâtiment, on fait de l'informatique !!! Je n'ai jamais réussi à développer avec une truelle et je ne leur demande pas de construire ma maison à coup de claviers !!!


Voici la réponse que j'ai fait à mon amis. Oui, elle est partisane mais j'avoue que l'emploi de l'organisation  MOA/MOE avec les mauvais résultats ou les dérives commerciales que cela implique m'énerve assez vite.

Comme disait récemment Jeff Sutherland dans cet article de son son blog
"Scrum doesn't magically make your problems go away, it makes them clear and you know immediately where to look for responsibility."
L'Agilité et Scrum en particulier ne sont pas une garantie de succès, mais ils sont une organisation plus simple, plus logique et plus efficace que la MOA/MOE.

Ma réponse 

A la question "Est-ce que tu comprends quelque chose à cet article", j'ai répondu : 

Oh oui je ne comprends que trop bien pour avoir travaillé avec ce système poussif des années en France.

Je fais partie, je milite et utilise de nouvelles méthodes de travailles et d'organisation du travail qui permettent de rapprocher le client du développeur et donc de raccourcir le cheminement de l'information, minimisant de ce fait le risque d'erreur.
Ça s'appelle l'Agilité et ça aide à réussir des projets complexes comme Louvois.
Steria n'est pas très engagé dans ces méthodes pour une raison simple : l'argent.
Avec la méthode actuelle des bataillons d'analystes étudient le besoin (les fonctions du logiciel) pendant des semaines/des mois en interrogeant des utilisateurs, des responsables etc ... Ils sont ce qu'on appelle la MOA ( maîtrise d’ouvrage – ceux qui définissent comment devrait fonctionner le produit). Ils pondent un document qui s'appelle le Cahier des Charges et qui est censé contenir tout ce que le produit doit comporter comme fonctions, comportements, spécificités. Il faut comprendre que là tout n'est que théorique, le logiciel n'a pas été produit. Ici on n'a produit qu'un gros paquet de feuilles A4.
Le client prend plusieurs semaines/mois pour lire ce gros document (souvent assez incompréhensible pour un client non informaticien) et s'il est d'accord, on estime combien de temps ça prend pour créer tout ça sur la base de ce qui est écrit dans ce doc. On signe des contrats pour un certain montant et une certaine période de développement. C’est la MOE (maîtrise d’œuvre) qui réalise réellement le produit encore une fois sur la base du cahier des charges. Ce sont les développeurs (en schématisant évidemment)
Le hic dans cette méthode (dite prédictive par ce qu'on "prévoit" que ça devrait marcher comme ça) c'est que des projets de cette ampleur prennent du temps à développer et que donc les besoins du client peuvent changer entre temps. Sans oublié qu'on a pu se tromper ou sous-estimer tel ou tel point (c'est humain). Sauf que quand c’est signé, c’est signé ! « T’as signé, c’est pour en chier »
Quand le développement commence tu peux rien changer gratuitement puisque t’as signé et les analystes sont tellement bon qu'on "a pas pu se tromper" …. ou pas
Les grosses SSII jouent sur ces ambiguïtés. En gros si ce n’est pas dans le document que vous avez signé, ou si vous voulez un truc différent parce qu'en 6 mois des nouvelles lois sont passées (que vous ne pouviez pas prévu quand vous avez écrit le cahier des charges), alors vous devez signer un avenant et bien sûr payé à nouveau pour que ce soit fait. C'est considéré comme un changement dans le contrat initial signé entre tous.
Du coup à la fin du projet (surtout ceux très long comme celui-là) soit tu as exactement ce que tu veux (rare) mais tu as doublé le prix de ton application à cause de ce qui n'était pas écrit dans le cahier des charges, soit tu as un logiciel qui ne correspond pas à ton réel besoin même s'il correspond peut-être au besoin existant quand le cahier des charges à été rédigé une année auparavant. Mais c'est aujourd'hui qui compte, pas hier.
J'ai bossé des années comme ça, et ça amène toujours au conflit. C'est de la gestion de projet à court terme et qui ne tient pas compte de la satisfaction client. C'est le problème de boite de ce type dirigée uniquement du point de vue commercial, sans prendre en considération une dimension de qualité bien plus profitable à long terme.
Malheureusement c'est toujours les même qui trinquent : le client, en l’occurrence ici l'armée et ceux qui "bénéficient" de ce logiciel : vous !


Aucun commentaire:

Enregistrer un commentaire