Lors de différentes missions, j'ai pu constater un certaine répugnance à tout ce qui touchait de près ou de loin à la technique. Coté MOA, AMOA, analystes métiers, …, les informaticiens étaient appelés péjorativement des "tékausse".

On reprochait même à certains analystes d'être trop techniques dans leurs spécifications. Ce dédain pour les aspects réalisation technique pouvaient même aller jusqu'à passer à coté du dossier d'architecture technique. Les développements étaient sous-traités à une grande SSII qui devaient s'occuper de tout. C'est comme confier la décoration de son appartement à un architecte d'intérieur en lui disant "allez-y" sans autre directives et contrôles. Les mauvaises surprises arrivèrent bien vite. Quand la MOE chiffra les écrans, on arriva vite à des points de désaccord. Un écran utilisant 3 entités métiers, 4 zones de saisie, une liste déroulante, 3 boutons (Annuler, Enregistrer, Supprimer) étaient qualifié de complexe avec une charge de 12 jours de charges !  

Que s'était il donc passé ? 

Les parties prenantes par inexpérience de grands projets informatiques avaient négligé de s'allier les compétences d'experts en architecture et gestion de projet informatique pour les conseiller sur la réponse faite à l'appel d'offre. Les métriques d'estimation proposées par la SSII ne furent pas analysées et discutées. La direction de projet signa un chèque en blanc encore une fois par méconnaissance des méthodes et outils modernes d'amélioration de la productivité et du retour sur investissement. Les référentiels de bonnes pratiques comme CMMI, ITIL, eSCM étaient écartés car ce n'était pas le genre de la maison, "nous on est métier , MOA", on ne mélange pas les serviettes et les torchons ! 

Donc cette organisation se retrouva avec un chiffrage d'écran exorbitant, sortant largement des standards du marché. 

Quelles en étaient les causes ? 

Quand ne connaît pas un sujet, qu'on ne le maîtrise pas ou qu'on ne le comprend pas on s'attache les services d'un consultant expert avec une des retours d'expérience réussis dans le domaine considéré. Le projet avait des contraintes techniques, un existant imposé à faire évoluer. Le fait de s'appuyer sur une application existante utilisant des frameworks obsolètes, utilisant des vieux programmes mainframe, entraîna de fortes contraintes  techniques comme le fait par exemple de ne pas pouvoir utiliser les derniers outils pour le RIA (Rich Internet Application comme : Angular JS, Ext JS, GWT, PrimeFaces, RichFaces, Wicket, …) pour des raisons d'incompatibilité totale. 

Tous les composants graphiques de base furent entièrement développés manuellement avec les technologies d'il y a 15 ans (TagLib ,JSTL, JavaScript). Tous les comportements évènementiels IHM étaient écrits manuellement en JavaScript alors que plus personne ne fait ça aujourd'hui, ce serait comme développer une application de gestion en assembleur ! Quand on demanda le dossier d'architecture du projet, on nous dit qu'il était en cours de rédaction alors que la première bonne pratique est de valider l'architecture en tout début de projet et de ne pas se lancer dans la production de code sans cette validation. La méthode UP (Unified Process) spécifie même une phase propre à cette validation, la phase d'élaboration. 

N'ayant pas de contre expertise, la SSII en profita donc pour imposer ce qui l'arrangeait le mieux.  

Le projet ayant pris beaucoup de retard par ailleurs et les développements ayant commencé, il ne restait plus à l'organisation le choix cornélien, soit de payer ou soit d'arrêter le projet ! 

"Il faut tenir une résolution parce qu'elle est bonne et non parce qu'on la prise"

Voir aussi : http://urbanisation-si.blog4ever.net/

http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://rhonamaxwel.over-blog.com/