Un projet informatique, c'est comme...

icon Tags de l'article :

Juin 23, 2011

... construire une maison !

Sisi ! C'est un parallèle que j'ai fait il y a quelques jours, et plus j'y pense, plus je trouve que c'est vrai.

Vous vous voyez demander à un architecte et son équipe de fabriquer une maison en 2 mois ? Non, car c'est impossible. Et pourtant, dans l'informatique, on nous demande très (trop ?) souvent de réaliser l'impossible. Et les gens y croient, vu que c'est un domaine dans lequel ils n'y connaissent rien, ...

"Bon sang, c'est pas compliqué de rajouter un bouton ici, un formulaire là, et un traitement métier en fond enfin !

- Bah, ça rajoute seulement 2 semaines de développement...

- Pfff même moi je le ferais en seulement 1 semaine. Vous avez 3 jours."

Imaginez la tête de l'architecte à qui le client irait dire, à 1 mois de la remise des clefs, "Au fait, je veux le garage sur le toit et une piscine à la place de ma cuisine". Ca peut vous sembler ridicule, mais on vient souvent nous annoncer des modifications majeures à faire dans le délai imparti alors que le projet est presque fini...

Et ce ne sont que deux exemples de ce qu'on demande aux développeurs. Il y en a plein d'autres !

La plupart du temps, les patrons voudraient des applications fonctionnelles, sans bug, évolutives et développées rapidement sans paperasse ni planification.

"Bon alors je voudrais une maison de 300 m² sur ce terrain de 200 m². Elle devra compter 10 chambres au minimum, et on devra pouvoir rajouter 50 chambres, si besoin est, en appuyant sur un bouton. La piscine sur le toit doit pouvoir se transformer en cuisine instantanément. Enfin, on aimerait un sous-sol aménagé façon Louis XIV pour le rangement. Pour tout ça, on te donne 2 mois et vous serez 3. On compte, bien sûr, sur ton implication personnelle pour que le projet soit terminé à la fin de ce délai." (Traduction : "Si c'est pas terminé dans les temps, tu seras viré car ce sera de ta faute, bien évidemment.")

Et après on se demande pourquoi 20% des projets sont abandonnés et pourquoi 60% explosent les délais et les couts.

On a vraiment une belle vie, nous les développeurs, non ?

N'hésitez pas à donner votre avis ou à faire un autre parallèle dans les commentaires Cool

image retouchée de comedy_nose, sous licence CC

23 commentaires

Nico - 24/06/2011 à 10:52:16

Yop!

J'aime bien la comparaison, tu as vraiment mis le paquet sur le sous-sol aménager Louis XIV mais bon on retrouve un peu notre quotidien.

Bah oui c'est logique, ça coûte bien trop cher de planifier!!! Si seulement on pouvait, à chaque fois, faire des deux façon (avec et sans gestion de projet) pour montrer aux gérants l'argent qu'ils perdent...

Mais Tommy il parait que l'on compte sur nous (les jeunes) pour faire bouger les choses et apporter de nouvelles méthodes... Alors allons-y! :D

@répondre #lien

Adrian - 24/06/2011 à 11:21:09

Excellent, ça m'a bien fait rire :) ! Tellement vrai Tommy !

@répondre #lien

Benoit - 24/06/2011 à 14:37:49

Il est vrai que le rapprochement est similaire! Mais on fabrique aussi des maisons en 2 mois ca s'appelle la maison en kit, c'est biensur pas une suédoise qui te la monte mais c'est faisable.

Biensur on veut toujours tout bien, rapidement et pas chère. Prochaine fois, annonce 2 mois de développement, peut être qu'on te donnera tes deux semaines ;)

Et puis ... VIVE LES PATRONS ^^

@répondre #lien

Fleid - 30/06/2011 à 03:25:40

Attention à ne pas voir le constant changement du client comme quelque chose de mauvais à éliminer.

Pour un projet de 6 mois, vous préférez un client qui change d'avis toutes les semaines ou un client qui ne vous fait aucun retour pendant 6 mois? Le piège c'est que celui qui ne dit rien ne vous signera jamais le PV de recette (donc vous n'êtes pas payés) parce que ce que vous aurez livré n'est pas ce qu'il avait imaginé... Bin ouais mais fallait peut être le dire avant Monsieur le Client!

Moi en tout cas je préfère celui qui change d'avis: au moins ça veut dire qu'il s'intéresse à ce qu'il se passe!

Le tout est d'utiliser la bonne méthode de gestion de projet avec le bon client. Si vous ne connaissez pas encore les méthodes Agile, c'est le moment de s'y mettre. Faîtes vous un petit projet SCRUM entre vous, ça change complétement la relation avec le client et c'est une super ligne sur un CV de développeur au moment de l'embauche!

@répondre #lien

Tommy - 05/07/2011 à 06:50:08

Oh je ne vois pas le constant changement du client comme un point négatif, au contraire !

Il est clair que l'effet tunnel est encore plus néfaste à un projet que le client maladroit mais qui s'intéresse au projet...
Ce que je n'aime vraiment pas, c'est la rétention d'informations. Le client se dit que cette modification à laquelle il a pensé est mineure, et il la suggérera à la fin du projet, alors que cette modification impacte le front, le back, la BDD et la doc !
Ca me rappelle cette image qui est tout à fait vraie : http://www.projectcartoon.com/cartoon/42 . La communication est déjà assez difficile comme ça entre le métier et le technique... Quand le commercial s'en mêle et qu'on insère des intermédiaires, faut pas s'étonner que le projet s'écroule !

Les clients considèrent souvent le développement comme quelque chose de simple, alors que c'est loin de l'être (comme l'avait découvert à ses dépends ce journaliste : http://zanasha-land.naeodeferra.fr/index.php?2011/06/15/09/45/49-tiens-un-petit-frustre ) ! C'est pour ça que j'avais fait cette analogie... Si on fabrique une maison en 2 semaines, on ne peut pas s'attendre à ce qu'elle soit évolutive, stable, bien réalisée et sans défauts !

Enfin les méthodo SCRUM je rêve de les utiliser en entreprise, mais dans ma mission actuelle, on fait du "simili-SCRUM", avec des post-it et... c'est tout :(

@répondre #lien

Plomps - 24/05/2012 à 14:39:29

La solution consiste bien évidemment à ne plus se laisser faire :)
Le seul moyen de se faire respecter en entreprise n'est pas de râler dans son coin mais, à un moment donné, de se battre un bon coup avec la hiérarchie : refusez, menacez, négociez.

Il y a deux choses fondamentales à considérer. Premièrement, en tant que développeur n'assumant pas un métier de cadre, vous n'avez pas obligation de résultat, mais de moyen (i.e. vous pouvez vous planter, à condition d'avoir tout fait pour réussir). Deuxièmement, si vous êtes en CDI, on ne peut pas vous virer facilement, donc refusez de faire des heures supplémentaires non payées ou négociez une augmentation. En acceptant de faire des heures supplémentaires pour finir un projet à temps, vous amenez la hiérarchie à considérer que les délais qui ont été prévus étaient suffisants : c'est une mauvaise chose, si votre chef de projet se fait engueuler un bon coup, il commencera à revoir un peu ses techniques d'estimations.

Ouvrir sa gueule en entreprise est assez mal vu, donc par la suite vous devrez vous battre continuellement. Toutefois, vous avez la chance de vous situer sur un marché relativement porteur (ce qui ne durera pas !) alors n'hésitez pas à changer de poste tous les trois ans. L'expérience accumulée vous garantira une progression de salaire bien plus rapide.

Bref, soyez agressif. C'est de cette façon, et seulement de cette façon, que les développeurs cesseront d'être traités comme des larves consentantes.

@répondre #lien

Teocali - 24/05/2012 à 15:05:32

pluzun avec Plomps. Le truc c'est vraiment de ne pas se laisser faire, et donc de ne pas avoir peur de changer d'entreprise...

Teo

@répondre #lien

lu - 24/05/2012 à 15:17:43

Héhé, petite parenthèse pour rebondir sur ton parallèle avec le bâtiment^^ moi qui ai bossé en tant que dessinateur dans le bâtiment, on retrouve des demandes un peu comme ça… le client veut une maison qui d'apparence extérieure, est un plain-pied.

Et quand on lui demande la disposition des pièces qu'il demande, il veut 3 chambres et une salle de bains à l'étage : c'est incompatible !

@répondre #lien

Fab - 24/05/2012 à 15:22:56

Amusant, j'avais cité cette analogie à mes collègues et mes boss (tu construirais vraiment une maison sans architecte?) il y a quelques jours. La seule chose qu'on m'a répondu c'est "tu penses vraiment qu'un client va payer 10 ou 20 jours pour de l'analyse?"...

Pour moi le gros problème est que beaucoup de décideurs voient les développeurs comme des ressources autonomes qui font des miracles derrière un ordi. Quand on leur parle d'analyse, ils ne voient que le côté "tu ne codes rien, donc je ne vends rien, donc tu n'analyseras pas".

Comment faire comprendre que l'analyse est une réelle valeur ajoutée à un projet? Si quelqu'un a une phrase choc, je suis preneur parce que là, mon ulcère en prends un coup ^^.

PS : à propos des changements d'avis du client, mes boss sont également persuadés qu'avoir un CDC rend le projet hermétique à toute souplesse...

@répondre #lien

mat - 24/05/2012 à 15:43:39

Bah pour rester dans le bâtiment...
Tu construit ta maison sans les plans toi?

@répondre #lien

Michel - 24/05/2012 à 15:50:50

vu du coté utilisateur
http://ephata.blogspot.fr/2005/01/fable.html

@répondre #lien

Plomps - 24/05/2012 à 16:01:07

Un bon moyen d'expliquer à un décideur que le CDC, l'analyse et tout le reste de la paperasse est important, c'est de lui rappeler que vous aussi vous n'aimez pas ça. En effet, c'est long, ça prend du temps, ça demande un effort de réflexion considérable (communication avec le client, analyse des besoins, des risques, des coûts, création de maquette et toute une foultitude de choses très consommatrices de temps mais finalement pas très intéressantes).

De plus, le décideur doit comprendre que ces choses là sont aussi contractuelles et vont aussi permettre à l'entreprise de se défendre. Un client qui change sans cesse d'avis et ajoute continuellement de nouvelles choses, ce n'est pas de l'agile, c'est juste du chaos. Et le chaos, ça peut très vite plomber un projet (retard, surcoût, mauvaise réponse au besoin, etc.). Un projet plombé c'est, tôt ou tard, le tribunal. Et au tribunal, le client gagnera, car c'est la SSII qui a un devoir de conseil aux yeux de la loi (le client il n'y connait rien, si le projet se casse la gueule, c'est donc forcément de votre faute).
Beaucoup de décideurs négligent ce genre de chose, mais un client peut très vite assigner l'entreprise en justice. Ca, ça coûte encore plus d'argent que les retards ou les dépassement de budget.

Bref, si vous voulez valoriser quelque chose auprès d'un décideur, jouez sur la corde sensible : le pognon.

@répondre #lien

Blux - 24/05/2012 à 17:07:37

Ben, c'est les même qui pensent qu'en réunissant 3 femmes, on va faire un bébé en 3 mois...

@répondre #lien

H3 - 24/05/2012 à 19:00:15

C'est on ne peut plus vrai comme analogie... Si l'on ajoute à ça les spéc qui change tous les jours à cause patrons indécis, on retrouve bien nos pretits...

@répondre #lien

Loups - 24/05/2012 à 19:05:30

Tout à fait vrai, c'est troublant car j'expliquais justement à un ami le métier en prenant cet exemple de la piscine dans la cuisine !
Il est vrai que certaines modifications semblent très simple à réaliser mais, il faut souvent refaire tout un pilier de la programmation car ce n'était pas prévu pour au début. Comme un client qui vous dirait que maintenant il veut un sol chauffant sous le magnifique carrelage que vous venez de poser en une semaine, et qui nécessite de tout détruire pour passer les tuyaux.

En effet, une analyse faite proprement dès le début, en mettant en avant des points pouvant changer souvent ou être retouchés par la suite, est un vrai gain de temps et l'assurance d'avoir un projet fonctionnel dans les temps.

@répondre #lien

lanfisis - 25/05/2012 à 10:31:06

Les CDC, les analyses et autres paperasses sont le meilleurs moyen de planter un projet. Par exepérience, et je pense que vous en conviendrez, aucun client n'est capable, en début de projet, d'exprimer complètement et clairement ses envies et besoins. Moi même, en temps que developpeur expérimenté, je ne sais pas si j'en serais capable.Donc faire un cahier des charges figé en début de proget permetra juste de dire au client: vous voulez faire ça en plus ou déifférement, ha désolé, c'est pas dans le cahier des charges, aller vous faire voir ou alors alonger le pognon. Pensez-vous que ce soit les bases d'une relation client saine ?

Pourquoi ne pas plutôt lui démontrer les bienfaits des méthodes agiles, proceder à un premier Sprint de test durant lequel vous pourrez poser les base de la future application. Si le client est content du résultat obtenus il voudra continuer sur la lancé ou vous n'aurez vendu, de votre côté, que du temps passé. De plus vous associer et impliquer complètement votre client. Il sera à même de mieux comprendre la réalité de votre travail. Pas de CDC, juste des users stories. Pas de conception technique, juste du code commenté et des tests unitaires. Pas de perte d'argent: vous facturer le temps passé.

Je ne comprend pas les analogie avec le monde réel (contruction de maison, de voiture, ...) Justement, l'informatique n'est pas le monde reel et le changement est possible en cours de projet et permet d'avoir des application qui colle au plus prêt des réalités métier du client, et donc lui approte entière satisfaction. Je pense que les developpeur et les entreprise de developpement doivent aussi se poser des questions sur l'accompagnement qu'ils proposent et leur approche client. Alors plutôt que d'essayer de convaincre votre décideur qu'il vous faut 10 / 15 / 20 jours pour écrire un cahier des charges qui sera obscolète 2 jours plus tard, essayer de le convraincre de tester un projet en agile :)

Je vous invite à lire cet excelent article : http://knplabs.fr/blog/agile-c-est-quoi Il résume parfaitement ma vision dee la manière dont devrait être menés les projets informatique.

Bonne journée.

David

@répondre #lien

Freddy - 26/05/2012 à 12:29:12

Héhé... Comme je me reconnais dans ce profil.

J'ai dû créer seul, lors d'une mission, un extranet pour 300 personnes mais qui "doit pouvoir accueillir d'ici quelques années (ou pas) entre 2000 et 20000 utilisateurs", avec comme seules indications quelques notes griffonner sur une feuille de papier... et un délai de 3 mois pour le réaliser.
Et a environ 15jours de la fin, le rajout d'une "petite fonctionnalité", "rien du tout" : la possibilite d'avoir des groupes de travails indépendants, qui à du me faire revoir completement l'architecture de base du site...

Enfin heureusement pour moi, j'avais choisis Drupal comme techno...

Et au final, même pas un merci ou une reconnaissance de mon exploit.

Apres cette aventure, j'ai décidé de définitivement arreter les SSII.

@répondre #lien

Freddy - 26/05/2012 à 13:25:05

Je suis pas tout a fait d'accord avec toi Lanfisis.

Je vais parler en tant que developpeur web ayant une quinzaine d'années d'experience.

Un CDC a l'avantage de faire reflechir un minimum le client sur ce qu'il souhaite et comment il voit les choses, quitte à l'aider à la redaction du CDC.

Trop souvent, je suis confronté à un client qui ne sait que vaguement ce qu'il veut, aussi l'avantage d'un CDC permet de definir un tant soit peu le comportement/affichage du site.

Donc je dirai que je suis totalement pour un CDC mais realisé en commun, pas trop détaillé ni trop strict...

Je suis d'accord qu'en informatique on peut tout faire et refaire, voir revoir les bases, mais cela a un cout.
En effet, les changements de structure non prévus a la base demandent enormement de ressources humaines (bon developpeur avec un excellent niveau d'analyse obligatoire), enormement de temps... et en consequence pas mal de ressources financieres.
De plus, les risques que le systeme devienne instable, inadapté ou sous-calibré sont alors beaucoup plus élevés.

A faire et defaire, on pollue le code (c'est l'experience qui parle).

Donc pour ma part, je pense que passer un peu de temps sur un CDC (1 à 2 jours), ca peut que faire du bien... Ensuite passer 10/15/20 jours pour écrire un cahier des charge c'est plus du commercial qu'autre chose...

Un bon compromis est l'utilisation de copies d'écrans, ca parle aux clients et ca donne de bonnes bases...

Sinon je pense que la communication demandeur / executant est primordiale, un projet sans des contacts très réguliers et frequents est voué a l'échec.

@répondre #lien

Poujol-Rost Mathias - 28/05/2012 à 19:57:33

Un lien que je suis étonné de ne pas avoir déjà trouvé dans les commentaires, par Frédéric de Villamil : http://t37.net/si-les-architectes-devaient-travailler-comme-les-web-designers.html .

@répondre #lien

lanfisis - 29/05/2012 à 09:32:04

Je me permet de continuer la discution.

Pour reprendre ton exemple, je préfère faire une première reunion client et écrire les premières user stories qui correspondent aux attentes client. Partant du principe que le premier sprint fait 15 jours, a vous d'essayer de prioriser avec lui ce qui peut-être fait dans ce delais. Il est impressionnant de voir à quel point un client arrive à prioriser quand il sait qu'il n'aura pas une minute de plus que celles qu'il a acheté. pour faire dans le concret, il peut être convenu que des les 15 jours, doivent être posé les base d'un CMC avec une partie d'administration (pour rester dans le classqiue, mais s'applique à tout type de projet) Au bout des 15 jours, on fait le point avec le client, en lui montrant un site déjà fonctionnel (même si c'est pour le moment une coquille vide) Et on repart pour des users stories, priorisation et 15 jours de travail avec toujours une demo fonctionnelle à la fin. Si ou bout de 6 sprints , le projet satisfait le client, parfait. S'il ne lui convient pas, on repart pour une serie de sprint dans une nouvelle direction sachant que chaque sprint est payé au juste prix. Ainsi, aucun dépassement des délais ou des coût n'est possible, tout est maitrisé.

Pour moi, un cahier des charges rédigé en 1 ou 2 jours, sauf sur un tout petit projet, ne peut être assez exaustif ou complet pour ne par être modifié en route. Si une modification du contenus du CDC est faite par le client, même d'une heure, et ne prend pas la place exacte d'un autre point supprimé, vous êtes déjà en retard d'une haure sur votre dead line. (qui porte bien son nom au demeurant)


J'ai mené des projet de cette manière et le client a non seulement été toujours satisfait, mais je n'ai jamais travaillé plus que ce que j'avais vendu, mon rendament est donc le plus optimal.

Bonne journée.

@répondre #lien

lanfisis - 29/05/2012 à 09:33:20

Etant dysorthographique et un peu trop prompt à répondre, j'ai mis CMC au lieu de CMS. Vous aurez corrigé par vous même.

@répondre #lien

E.Merten - 08/06/2012 à 10:03:33

Une pure vérité ! En alternance pour ma Licence, je suis confrontrer exactement a se problème et l'incompétence de mon chef de projet qui croit en tous et n'importe quoi, me fait un cahier des charges en une semaine pour projet d'une durée de 5mois ! Ayant osé dire la vérité, je me retrouve sans emploi à la fin du mois ... YEAH ! it's AWESOME ;)

@répondre #lien

GilD - 04/05/2015 à 17:04:23

les phases d'analyse sont le plus souvent écourtées.
La raison est que l'on veut garder du temps pour corriger en phase de coding des erreurs qui n'auraient pas été commises si l'on avait pris plus de temps lors de l'analyse.... amusant, non!

le chef / directeur du projet / programme a la responsabilité d'afficher des plannings réalistes: ce qui englobe la définition d'un périmètre clair, des estimations de charge basées sur des profils définis (tenant compte de la séniorité)
Les demandes de changement sont à gérer très précisément (risques, coûts, délais) par le comité idoine.

@répondre #lien

icon Flux RSS des commentaires de cet article

Les commentaires sont fermés pour cet article