C'est souvent ca quand le client veut du résultat "visible", c'est pas évident de lui montrer du code ... Parfois je me dit qu'on est des incompris
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
C'est souvent ca quand le client veut du résultat "visible", c'est pas évident de lui montrer du code ... Parfois je me dit qu'on est des incompris
Bienvenu au club !
Intéressant comme sujet ! ça fait tellement peur que des fois on préfère en rire (avec le recul... beaucoup de recul).
Pour ma part j'ajouterai "l'architecte fou" : l'architecte qui développe couche sur couche d'une grande complexité (ne fonctionnant pas mieux voir moins bien généralement) et qui démissionne... La complexité de la chose fait que personne ne peut reprendre l'existant et c'est le drame
ça vient justement de m'arriver. Alors à quoi ça sert de refaire l'appli sinon de dépenser des milliers d'euro pour avoir quelque chose d'équivalent voir même de moins bien (sachant que la nouvelle appli n'a pas la même maturité que l'ancienne)... ça fait réfléchir quand mêmeQuand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà
Un jour les spécifications étaient celle-ci :
Cela doit être beau et agréable à regarder !
Uniquement cela !
Donc j'ai renvoyé le mail avec ceci ...
C'est beau et agréable à regarder non ?
Ben ils n'ont pas trouvé cela drôle à Paris ...
J'ai vécu un truc très similaire à celui raconté par pseudocode, vraiment dans le même style, résultat, jour après jour, on développe plus de bugs que de fonctionnalités
Ou des POC/simples prototypes qui se retrouvent déjà à moitié vendu alors que c'était juste censé être un prototype jetable(notamment si le prototype est pas si mal que ça).
Du coup, le code continue sur le code de l'ancien prototype au lieu de tout recommencer correctement car on met des délais intenables...
Déjà vécu aussi. Des commerciaux qui ont vendu un produit uniquement disponible en image de synthèse sur les plaquettes publicitaires.Envoyé par millie
Ou des POC/simples prototypes qui se retrouvent déjà à moitié vendu alors que c'était juste censé être un prototype jetable
Grand classique ! Le prototype de R&D qui passe direct en Industrialisation après une courte pose au service informatique le temps de "finaliser le logiciel".Du coup, le code continue sur le code de l'ancien prototype au lieu de tout recommencer correctement car on met des délais intenables...
Amusant à lire mais tellement vrai !!
Ce n'est pas un hasard si 80% des projets informatiques sont voués à l'échec..
Pour moi l'une des raisons les plus importantes et qui fausse tout dès le départ :
- Le cahier des charges du client n'est pas un cahier des charges ... Quand on gratte un peu le client en fait ne sait pas bien ce qu'il veut. J'ai déjà eu à faire à un cahier des charges avec une diapo powerpoint !! C'est votre cahier des charges ? oui oui
++
Bah encore ça va si on compare au cahier des charges sur un post-it
Incroyable
Bonsoir tout le monde
le lien vers cet article m'a été envoyé par un Ex collègue, qui s'est fait licencier pour les motifs évoqués dans les diverses réponses ci-dessus.
Ce que je trouve incroyable, c'est que nous devons tous bossé dans la même boite.
La je suis en plein dedans, ce qui est effrayant c'est que ce sont toujours les mêmes qui morflent, et toujours les même qui tirent les marrons du feu, alors que ce sont eux les responsables du désastre.
Tout ce que je viens de lire est exact (dans mon cas) pourtant nous ne sommes qu'une petite boite de 35 employés, mais nous sommes gérés comme si nous étions une multinationale, avec cadre, super cadre, comité de direction etc, et ou est l'organisation dans tout ça ??, le cahier des charges (c'est le rouleau de PQ), les Specs (ça marche au téléphone) et de toute façon tu les comprend pas ( en fait le mec qui te les dit comprend pas ce que son client veut).
Alors a part continuer en se disant "Après moi le déluge", monter sa boite, chercher une bonne boite (28 ans que je cherche) que faire???
si quelqu'un à une idée a faire partagé je suis preneur.
Bonsoir a tous
Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?
En fait, on est pas tous dans la même boite, mais on fait tous le même métier ^^
Les spécs ça m'as toujours étonné aussi, les faire en parallèle des dévs, après les dévs, voire jamais... c'est comme si un architecte faisait son plan après la construction.
Je vais parler de ce que je connais, c'est à dire le développements d'application web, j'ai l'impression que l'informatique est un monde que vie en autarcie, il y a des gens qui créer des frameworks, censé simplifié la création de nouvelle application, mais au final souvent complexe, demandant de solide formation et de l'expérience.
On les met en place dans de nouveau projet(souvent parce que c'est vendeur d'utiliser tel ou tel techno), et on se rend compte (toujours après coup) qu'au vu de la taille du projet, qu'on a galèré à l'utiliser, on a fait plein de contournement parce que ça faisait pas exactement ce qu'on voulait, ça engendre plus de bug, ça engendre des problèmes de performances... etc.
C'est le ressenti que j'ai après 3 ans de développement, mais cela ne tient peut être que de mon expérience.
Mais si on prend du recul (beaucoup de recul) le temps qu'on perd a développer, souvent plus que prévu, fait qu'on a du boulot ^^ et qu'on est payé au temps passé, pas au temps perdu (heureusement)
Il existe des entreprises où :
Les clients savent ce qu'ils veulent et font un cahier des charges très exhaustif.
Les chefs de projets estiment correctement les ressources nécessaires pour le périmètre fonctionnel à accomplir ...
Les chefs de projets arrivent à convaincre le client de restreindre son périmètre, d'augmenter les délai et/ou son budget
Les développeurs peuvent choisir les technologies qu'ils veulent car ils ont le temps de faire de la veille, de recevoir les formations qu'ils souhaitent
Les clients testent sérieusement l'application durant la phase de recette et exprime clairement les petits problèmes rencontrés
Les clients ayant clairement défini ce qu'ils voulaient, il n'y a pas de mauvaise surprise.
Et lorsqu'ils ont oublié un petit truc qui paraît plus grave à leurs yeux qu'à ceux des développeurs qui n'en auront que pour quelques secondes à le corriger, ils ont tellement honte qu'ils vous amènent des croissants chauds ...
....
et là, je me réveille !
Ben à lire ca, je suis content d'être indépendant.
Ma spécialité, c'est le petit projet, de 1 jour (si si, ca existe) à 3 mois, pour ne seule personne, éventuellement 2 si ca tape en partie sur un domaine que je connais mal.
Je suis en direct avec le client, ou bien je passe par une SSII qui me laisse dialoguer avec le client et me laisse gérer ma barque (ce sont des conditions sine qua non). Cela évite 2 des principaux écueils cités : un service commercial qui transmet (mal) les demandes du client, et les chefs arbitraires et incompétents. Par contre, je me cogne les changements d'avis du client, ou le CdC powerpoint (que je préfère renommer en "expression des besoins").
Bien sûr, j'ai des sueurs froides, mais pas les mêmes qu'un salarié (client qui dépose le bilan, ou bien variation très importantes dans le revenu : -45% entre 2007 et 2008)
En fait ma question est celle-ci : je pense qu'il y a un rapport direct entre la taille du projet et les problèmes générés. Ce n'est pas visible à mon niveau, mais est-ce que certains pourraient confirmer / infirmer ce point ?
Yvan
Non. Des fois c'est pire. J'ai vu:
La "maquette" présentée aux clients, qui était en fait un fichier PPS, avec des screenshots bricolés avec paint shop pro. Et fait pas une ligne de code n'avait encore été écrite.
Le commercial et le patron qui impose à l'équipe de développement les outils à utiliser (et pas les moindres: l'EDI de développement). Bien sûr, ni l'un ni l'autre n'ont de connaissances en informatique.
Le commercial (le même) qui vend des nouvelle fonctonnalités aux clients avant même que ce soit développé (et avant même de savoir si c'est faisable). Démerde-toi après à développer ça. Il faut que ce soit fini pour vendredi.
Moi je baisse pas la tête... je l'attends à la sortie, quand c'est un "mec comme tout le monde" et je lui explique ma façon de voir les choses.« Décembre!!! », hurle BB. Les personnes baissent leur tête comme s'il leur pointait un fusil d'assaut vers eux. « Décembre est absolument hors de question. Chefs d'équipe, je veux de nouvelles estimations sur mon bureau pour demain matin. Je déclare dorénavant les semaines de 65 heures obligatoires tant que ce projet n'est pas fini. Et il a intérêt à finir pour le 1er novembre! »
Je me fais virer, mais on me parle pas comme ça... Et ce serait bien que personne ne se laisse parler comme ça, que personne ne baisse la tête et que tout le monde se lève pour lui expliquer la vie.
Mais ça... c'est l'esprit d'équipe, et dans vos grosses boites, on connait pas trop
Pour moi il y a un rapport direct, entre la taille d'un projet et les problèmes, surtout si le nombre développeur sur le projet est important.
Imaginons que sur un projet de 2 personnes, un problème est détecté, que un des développeurs prend un jour de retard, cela retarde de 1 jour le second développeur s'il est dépendant des dévs du premier.
Prenons maintenant un projet de plusieurs dizaine de développeur, même situation, un problème est détecté et un des développeurs prend un jour de retard, si dix personnes sont dépendantes des dévs de celui-ci, on a 10 jours de retard... (c'est une explication simpliste, mais ça met en évidence ce qui peut se passer)
C'est là la difficulté des grosses équipes, rendre les développements les moins dépendants des autres pour éviter ce genre de situation.
Ce n'est pas complètement stupide. Le client, ce qu'il souhaite au final, ce n'est pas un bout de papier lui expliquant comment fonctionne le logiciel, mais un logiciel fonctionnel.Quand le client n'a pas de culture de projet ça veut dire quand tu lui envoie les specs pour validation, il t'appelle et te dis bah moi je valide pas ça, ce que je veux c'est voir une 1ere version dans laquelle je peux valider le fonctionnelement de l'appli.
Je commencerai par dire que je reconnais ma situation dans tous ces témoignages, en affirmant que malheureusement, c'est une terrible fatalité. La (trop) faible percée des méthodes agiles ces dernières années ne permet pas de changer les mentalités en profondeur. Trop de gens sont encore persuadés qu'un projet logiciel se construit comme une maison, avec d'abord des plans, des fondations, le terrassement, etc. Il n'en est (presque toujours) rien. Le malheur, c'est que beaucoup de gens le savent (beaucoup d'autres l'ignorent aussi), mais ne veulent pas changer les habitudes de travail, et de son côté le "client" ne veut pas faire l'effort de s'intégrer dans le déroulement du projet, dans lequel il tient pourtant un rôle central.
Je ne prendrais qu'une sous-partie d'un projet comme exemple : celui du cahier des charges, considéré comme l'élément indispensable par tous, et quasiment toujours responsable des échecs. Dans le déroulement d'un projet "construction de maison", les développeurs ont besoin du cahier des charges pour analyser d'abord, puis concevoir et enfin développer... Le problème c'est que : le client ne sait pas exactement ce qu'il veut, et même s'il le sait, est-il en mesure de le coucher sur papier ? EN admettant même qu'il soit suffisamment explicite, l'équipe de développement sera-t-elle à même de le comprendre ? D'implémenter exactement les bonnes fonctionnalités ? De décrypter la vision du client ?
Tellement d'études démontrent que cette approche de projet est erronée dans 99% des cas. Ces études mettent en corrélation ces évidences (vos témoignages apportent encore des preuves !), à savoir que le taux d'échec est très élevé dans les projets gérés "en cascade" (mode construction de maison). Un jour, j'ai expliqué à mon boulot comment les méthodes agiles permettaient de résoudre une grande partie de ces problèmes, bien que n'étant pas la panacée. On m'a répondu : "commençons par travailler en mode projet" (extrait texto des bouches des décideurs). Au secours. Désarroi. Le mode projet, ça veut dire quoi exactement ?
Le jour où les décideurs, mais aussi les équipes de développeurs/architectes/chef de projets, prendront conscience que les échecs ne sont pas dus à l'incompétence de leurs équipes de développement ou au client qui fait des caprices du genre "je veux voir un logiciel fonctionnel pour valider" (ce qui est parfaitement légitime, c'est ce pour quoi il paie !), et que le principe de base de réussite d'un projet, la COMMUNICATION, sera l'élément central de tout projet, alors on (tout le monde d'ailleurs) vivra des jours meilleurs.
Je finirai en citant Alistair Cockburn : "Le développement de logiciel est un 'jeu collaboratif' dans lequel les participants utilisent des marqueurs pour se souvenir, se stimuler et s’informer mutuellement au cours de chaque mouvement du jeu. La fin du jeu est la 'production' et le 'déploiement' d’un système ; le résidu de ce jeu est un ensemble de marqueurs destinés à informer et assister les joueurs dans la partie suivante qui consiste à modifier le système existant ou à produire un système similaire." Le titre d'un de ses livres est : "Agile software development : the cooperative game", livre dans lequel il décrit cette activité comme "a cooperative game of invention and communication". Je conseille à de nombreuses personnes de méditer sur cet aspect (j'y médite toujours moi-même...).
Pour terminer, je précise qu'il n'y a aucune forme d'arrogance, de mépris ou de complexe de supériorité dans me propos. Je tiens juste à ouvrir un champ de réflexion nouveau, fort intéressant (je conseille la lecture du manifeste agile - agile manifesto -) à ceux qui ignorent de quoi je parle. En référence, documentez-vous sur des méthodes telles q'Unified process, Scrum, XP, Crystal. Je vous garantis que vous y trouverez des solutions à tous ces problèmes. Après, et c'est la tâches sans aucun doute la plus difficile, il vous reviens de convaincre et de changer les mentalités. Après avoir vous-mêmes été convaincus (ce qui, je l'avoue d'expérience, est franchement pas simple).
Dans ma boîte, le commercial, que le projet marche ou pas, il ne s'en fou qu'à moitier, les com des différents paiements sur différents lots sont déjà tombés. Donc on vend, c'est le principal, après la faisabilité c'est pas son problème, si le projet réussit, ça ne fera que plus d'argent dans sa poche, s'il échoue, ça fera toujours plus que s'il était réaliste et que le client refuse. Surtout que sa com porte sur le prix de vente, et non sur le bénéfice, c'est à dire que s'il vend pour 1 millions d'euros, que ça nous a couté 1,2 millions d'euros à développer, il aura toujours sa com sur un pourcentage de ce qui a été vendu, dans mon cas 10% de la vente soit 100 000 €, ce qui fait passer la perte de 200 000 à 300 000 euros sur le projet. Il ne va pas s'en plaindre, la différence tombe dans sa poche...
J'ai pas mal entendu parler des méthodes agiles, pour casser le mur commercial entre le client et l'éditeur afin d'avancer communément vers un objectif commun et pallier ensemble aux problèmes.
Est-ce que ces méthodes sont en voie de développement ou la croyance envers la rentabilité et les indicateurs prime ?
J'ai remarqué également un autre "fléau", celui ci interne. C'est cette peur qu'un employé apporte quelque chose afin que l'entreprise devienne dépendant de ses travaux et que par conséquent celui-ci devienne indispensable et garantisse sa sécurité d'emploi. De ce fait, l'entreprise n'est ouverte à aucune proposition des "ouvriers", créative ou non, évolutives ou non, rentable ou non, et en reste à ses méthodes soit disant "fiables". Vous avez déjà rencontré ce genre de problème ?
Répondre avec citation
Partager