C'est le kickoff meeting d'un projet ambitieux fait sur mesure. On rencontre le client, il nous expose sa vision et ses besoins. On travaille ensemble sur l'analyse en détaillant les moindres particularités.
Nous : Cher client, je recommanderais l'ajout de cette fonctionnalité en priorité. C'est important d'avoir une bonne fondation et de le faire immédiatement car une partie de la modélisation de la base de données en dépend.
Client : Non, merci, ça n'arrivera jamais. Gardons les choses au plus simple pour que ça coûte le moins cher.
Nous : Vous en êtes certains ? Selon notre compréhension, on croit déceller que ça serait nécessaire pour couvrir tous les cas de figure. Notez que c'est une décision critique qui risque de complexifier les choses si on doit revenir en arrière pour adapter le système.
Client : N'essayez pas de me vendre des extras que je n'ai pas besoin. C'est impossible que les exceptions que vous mentionnez surviennent.
Nous : OK, mais on vous aura averti.
Quelques mois plus tard... Coup de téléphone.
Client : Oui bonjour, nos clients se plaignent de l'absence de la fonctionnalité et il faudrait la rajouter finalement. C'est urgent!
Nous : Hum... il est un peu tard pour le dire non ?
Client : Écoutez, c'est juste une petite fonctionnalité toute simple, je suis sûr que vous allez programmer ça rapidement, vous êtes des pros!
*** Réflexion ***
Si le besoin est facile à exprimer, ça ne veut pas dire que c'est facile à faire. Imaginez si on était à construire un gratte-ciel et qu'à la toute fin, le client décidait qu'il aimerait qu'on ajoute un demi-étage entre le 7 et le 8ème (référence: Being John Malkovich). C'est excessivement compliqué, pourquoi ne pas le faire au sommet ? Nous n'aurions pas à toucher à la structure existante. Il est catégorique : il désire que cet étage soit à cet emplacement et pas ailleurs.
Pour lui, il s'en fout, c'est nous qui allons devoir relever le défi. Comme dit le vieil adage, le client a toujours raison. Il est roi et maître parce que c'est lui qui paie.
Chargé de projet : on va vous arranger ça.
Programmeur : département des miracles, bonjour ?
Heureusement, c'est de la routine dans la vie d'un programmeur. Il sait par expérience que le code doit être assez flexible pour permettre de se retourner sur un 10 cennes (faire face au changement très rapidement). En secret, il avait prévu le coup et préparé le terrain. Il n'existe pas de problème qui n'ait pas de solution. Dans ce cas-ci, impossible voulait dire 25 heures.
lundi 20 septembre 2010
1 réponse à "Impossible veut dire 25 heures"
S'abonner à :
Publier des commentaires (Atom)
Bienvenue dans notre monde.. LOL !!