Ou les petites frustrations d’un développeur.
Développeur est un beau métier. Moi, par exemple, je travaille souvent pour le web, occasionellement pour l’administration de serveurs, parfois pour des cédéroms et rarement pour d’autres choses.
Que ce soit pour une grande entreprise multinationale ou pour une petite association locale, c’est franchement toujours le même esprit qui m’anime quant à la réalisation: faire les choses bien, tester, vérifier que ce soit bien ce qui est dans le cahier des charges, tester, vérifier les entrées/sorties, et tester encore.
Que ce soit pour une grande entreprise multinationale ou pour une petite association locale, il y a toujours quelqu’un qui arrive une fois le travail commencé et qui propose de modifier le cahier des charges, pour de plus ou moins bonnes raisons. Oh, pas un grand changement, non non, juste deux-trois petits trucs ça-et-là. Généralement tout le monde est content que ce brave type de la chouette équipe chez le client aie pu redresser la barre avant que le gros-oeuvre soit déjà fait. Mais n jours plus tard (n étant inversément proportionel à la taille du client: 2 jours pour la multinationale, 40 jours pour l’association locale), ce gentil personnage revient, avec son petit lot de petits changements. Et ainsi de suite jusqu’à la fin du mandat. Fin étant, dans ce contexte, un bien grand mot vu qu’il y a toujours des modifications à apporter au CdC, à reporter sur le produit et des tests à refaire. Mettons qu’on profite qu’il soit en vacances pour finaliser et sortir le produit.
Et bien cette aventure, c’est presque encore ce qu’il y a de mieux! En effet, au pire, le sympatique technico-commercial ne part pas en vacances tout de suite et sa hiérarchie a entre temps décidé de faire tout autre chose, autrement, quand c’est pas même avec d’autres gens. Résultat: on cuisine pour la poubelle! Des mois de développement prennent la direction de CD de backup, où ils ne seront généralement plus jamais dérangés.
Et là (vous allez voir, c’est complêtement dingue!), contre toute attente, il y a quelqu’un de votre côté pour dire qu’on en aura profité quand même, vu qu’on aura désormais un peu plus d’expérience dans le domaine exploité puis abandonné (la saisie de signature par un écran tactile, la représentation d’un sabot de giraffe en 3D, la simulation de paiement des intérêts compensatoires sur des comptes en euros, que sais-je). Mais en fait, l’expérience acquise ne servira jamais: pourquoi croyez-vous que le projet aie été abandonné?
Allez, allez… il faut faire contre mauvaise fortune bon coeur et se dire qu’il s’agit là d’un travers définitivement humain… En fait, je pense qu’on devrait prendre ceci en compte lors de la réalisation d’un cahier des charges. Pourquoi ? Ben justement parce que c’est un cahier des charges c’est fait pour dire ce que ça devrait faire, pas forcément comment… et là déjà, une inconnue…
Les besoins évoluent avec le temps, on se rend compte qu’il y a des choses mieux (eh oui, le cerveau ne s’arrete pas de réflechir, on ne peut pas le mettre en mode "off" sur le "générateur d’idée" 😉
Bref, avec l’expérience que j’ai (trés similaire à la tienne), j’ai fini par découvrir que finalement, le comportement du client est tout à fait normal et humain. Et que ce sont les méthodes de développement classiques (CDC, etc..) qui ne sont en fait pas vraiment adapté à la réalisation d’un projet informatique.
La solution à ces maux : l’extreme programming. Ce n’est pas évident à accepter au début car ça remet en cause la manière de voir les choses mais ça fonctionne et c’est de plus en plus adopté. En tout cas, il y a des idées à reprendre dans cette méthode.
http://www.xp-france.org/
http://www.extremeprogramming.or...
Et plus le délai de livraison approche, plus ces modifications sont importantes. On va finir par pouvoir en déduire une loi universelle!
Je rajouterais: les petites modifications augmentent d’autant plus que le délai de livraison s’approche, ce qui, presque sytématiquement, fait repousser la deadline et par effet mécanique amène son nouveau lot de petites modifications, qui, évidemment, s’accumulent aux précédentes. En général, cette logique se répète jusqu’à ce que tout le monde s’engueule et s’envoie chier.