Photos de Suède | Accueil | 34 000 mots »
17 octobre 2006
Plusieurs personnes se creusent les méninges afin de trouver la façon de diminuer les coûts de développement. Au début des années 90, James Martin a proposé le Rapid Application Development (dans un manuel de plus de 500 pages !). Depuis quelques années, on parle de méthodes agiles et d'extreme programming. Tout cela est certes louable. Cependant, il me semble que ça pourrait être plus simple.
Selon moi, il y a essentiellement trois raisons pour lesquelles le développement* prend plus de temps qu'il n'en faut :
1. On ne connaît pas vraiment les utilisateurs. L'étape consistant à connaître l'utilisateur est pratiquement inexistante. Ce qui fait qu'on se base sur des suppositions et des opinions pour développer, d'où ces interminables discussions qui viennent empoisonner le processus de conception. La solution : prendre le temps de connaître les utilisateurs en les observant, les interviewant, en lisant des études à leur sujet, en interviewant des tiers qui sont en contact direct avec ces derniers, etc.
2. Il n'y a pas de décideur. Lorsqu'il n'y a personne pour trancher entre différentes solutions, le risque de poursuivre ad nauseum les recherches et les discussions est très élevé. Tout le monde veut y mettre son grain de sel, tout le monde a son opinion et on n'hésite pas à consacrer beaucoup de temps afin de trouver la solution ultime. Rien de tel pour complexifier le tout... et dépasser les coûts et les échéanciers. La solution : nommer un décideur qui a un réel pouvoir de décision et qui est imputable. J'oubliais, il faut aussi que ce décideur soit disponible.
3. On ne se comprend pas. En 1994, une étude publiée dans Computerworld énonçait que la cause principale des dépassements de coûts et d'échéanciers était que les différents acteurs engagés dans un projet de développement n'arrivaient pas à se comprendre. Et ce n'est qu'à la toute fin qu'on s'apercevait que le résultat ne correspondait pas aux attentes. La solution : délaisser les formalismes traditionnels, formels et abstraits et utiliser des personnages, des scénarios, des maquettes, des cartes heuristiques, etc. pour communiquer.
Peut-être vois-je les choses trop simplement mais ce sont souvent les solutions simples qui sont garantes de succès !
* Je parle ici de développement au sens large, que ce soit de sites Web, de transactions Web ou de systèmes corporatifs.
Écrit par Daniel le octobre 17, 2006 12:02 PM
Tout à fait d'accord avec Daniel sur ce constat.
Je rajouterai, sur le point de l'importance du décideur, que nous avons besoin d'une personne qui garde le cap, qui conserve clairement en vue les 2 - 3 objectifs clés du SI, du logiciel. Ceci évite qu'il y ait des changements de cap inappropriés au gré des difficultés rencontrées lors du développement.
Écrit par: Martin le octobre 22, 2006 08:55 AM
Bonne analyse. Autre facteur à prendre en compte : les phases de tests qui sont souvent écourtées et qui génèrent des problèmes post-mise en prod, donc encore plus couteux et nuisibles pour l'image de marque du prestataire.
Sous la pression du client, et spécialement lorsque les plannings sont tendus, les développeurs ont souvent tendance à releaser un peu vite et à bacler cette phase de tests qui pourtant est primordiale.
Écrit par: Julien le octobre 18, 2006 10:22 AM