IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Humour Informatique Discussion :

Coder rapidement ou écrire du code de qualité ? Les deux approches ne servent à rien

  1. #41
    Membre averti
    Profil pro
    Inscrit en
    Août 2005
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 270
    Points : 342
    Points
    342
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Non, quand il s'agit de demande d'évolutions, celles-ci sont chiffrées et ajoutées au coût du projet. Ce sont les anomalies qui sont à la charge de la SSII. Évidemment, les commerciaux s'arrangent avec le client (faudrait pas le braquer non plus) et intègrent au projet une certaine partie des évolutions si leur coût est raisonnable par rapport à l'ensemble du projet.

    Dans le cadre d'une régie, ces questions ne se posent pas...
    Ca, c'est dans le meilleurs des monde. mais nous vivons quand même dans un monde ou des trucs comme la régie forfaitisée existe ! Alors, les cahiers des charges qui bougent...

    D'autre part, il ne faut pas que se situer dans un rapport "contractuel" ssii<> client.

    Nous sommes en général dans un rapport à 3 :
    - la MOA (la partie visible du client)
    - La MOE (l'équipe de dev)
    - Celui qui tient les cordons de la bourse... (partie invisible du client)

    Une bonne partie des couleuvres qu'avalent les équipes de dev sont en général due à une MOA qui n'a pas trop envie de dire "ca va couter le double parce que je n'ai pas pensé à la moitié des problèmes" à celui qui tient les cordons de la bourse...

  2. #42
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par jmguiche Voir le message
    (.../...)
    Une bonne partie des couleuvres qu'avalent les équipes de dev sont en général due à une MOA qui n'a pas trop envie de dire "ca va couter le double parce que je n'ai pas pensé à la moitié des problèmes" à celui qui tient les cordons de la bourse...
    Vu pas mal de fois. J'ai même vu une MOA qui refusait de corriger une spec fausse parceque la spec fausse avait été tamponnée et validée, par peur de déplaire aux grands chefs. Résultat : 18 mois de travail à 60 à la poubelle. Soit c'était conforme, mais ça ne parchait pas, soit ça marchait, mais ça n'était pas conforme. Alors que la spec était vraiment pas mal, et qu'il ne manquait pas grand chose pour qu'elle marche.....
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #43
    Membre averti
    Inscrit en
    Décembre 2007
    Messages
    222
    Détails du profil
    Informations forums :
    Inscription : Décembre 2007
    Messages : 222
    Points : 434
    Points
    434
    Par défaut
    Citation Envoyé par Barsy Voir le message
    C'est quand même rare que le commercial valide une évolution sans en faire part au préalable à l'équipe technique (enfin, j'imagine qu'il doit bien y en avoir qui le font... ).
    Dans le cadre d'un forfait, tout dépassement est la charge de la SSII. Accepter de prendre en charge des évolutions sans les chiffrer, c'est aller droit dans le mur.
    Vu et revu en SSII, le boss faisait quelques fois office de commercial et ne savait pas dire non. Les clients l'avaient compris et abusaient de lui. J'ai du, plusieurs fois, remettre des clients à leur place alors qu'ils demandaient des "petites" fonctionnalités qui auraient demandé de tout redévelopper. Bon, j'ai quitté cette boite
    La sécurité de l'emploi
    "Ce n’est pas une pratique médicale sensée que de risquer sa vie en se soumettant à une intervention probablement inefficace afin d’éviter une maladie qui ne surviendra vraisemblablement jamais."
    Docteur Kris Gaublomme, médecin belge ("Vaccins et maladies auto-immunes")

  4. #44
    Membre chevronné
    Avatar de olsimare
    Inscrit en
    Décembre 2006
    Messages
    1 175
    Détails du profil
    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 175
    Points : 1 767
    Points
    1 767
    Par défaut
    Bonjour.

    Pour ma part, je trouve l'analyse initiale par trop simpliste.

    On ne code pas à partir du besoin, on commence d'abord par l'analyser !

    Est-il si loin le temps ou avant toute chose, on réalisait un analyse fonctionnelle pour mettre en évidence les concepts et les invariants métiers qui permettaient au moins de batir sur un socle stable ?

    D'autre part, pour qu'un périmétre soit stable, il faut limiter au plus le nombre d'interlocuteurs susceptibles de le modifier... cela pose la question de qui est responsable de quoi, et c'est là où tout ce complique !

    Cdt
    Bon à savoir : la touche F1 ne sert pas à commander des places pour le grand prix de Belgique.

  5. #45
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Citation Envoyé par olsimare Voir le message
    Est-il si loin le temps ou avant toute chose, on réalisait un analyse fonctionnelle pour mettre en évidence les concepts et les invariants métiers qui permettaient au moins de batir sur un socle stable ?Cdt
    Depuis l'apparition des environnements RAD/WYSIWYG, cette pratique semble s'être un peu perdue en effet. En particulier pour les applications possédant une interface graphique.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  6. #46
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    A la question posée je suis entièrement d'accord avec :

    Citation Envoyé par Xysyo Voir le message
    A la question posée je dirais qu'il faut juste coder proprement en prévision des futures modifications, de manière à ce que la reprise du code soit la moins fastidieuse possible.


    Maintenant, dans le débat qui suit, je note que le principal problème est (comme ila toujours été) la gestion de projet (et des hommes) :


    Citation Envoyé par Patriarch24 Voir le message
    On en revient toujours au même : le problème, ce n'est pas la méthode, c'est la manière de gérer l'équipe.
    Citation Envoyé par olsimare Voir le message
    D'autre part, pour qu'un périmétre soit stable, il faut limiter au plus le nombre d'interlocuteurs susceptibles de le modifier... cela pose la question de qui est responsable de quoi, et c'est là où tout ce complique !

    Le second facteur est la méthologie employée :

    Citation Envoyé par billynirvana Voir le message
    Dans une méthode de travail stricte toutes les évolutions sont refusées sous prétexte qu'elles n'étaient pas prévues dans les specs, même si c'est juste pour ajouter une popup de confirmation lorsque l'on clique sur un bouton "Supprimer"... Avec une méthode Agile, cette question et cette réponse n'a plus lieu d'être (bien entendu si l'évolution reste dans le périmètre du projet initial).

    La méthode Agile selon moi ne sert qu'à ça, cela ne change pas la façon d'architecturer et de développer le projet. La méthode Agile ne doit pas converger vers la méthode à l'arrache.

    Citation Envoyé par jmguiche Voir le message
    Par contre, la mode des méthodes dites "agiles" accentuent peut être le phénomène. Beaucoup considèrent qu'une vue d'ensemble n'est pas utile : on fonce dans le développement à partir d'un besoin exprimé en 20 lignes dans un mail.
    Je pense que c'est une erreur, une très mauvaise mise en oeuvre de ces approches qui necessitent, au contraire, une maitrise d'ouvrage à l'esprit clair, structuré, avec une immense capacité d'abstraction et d'anticipation.

    Citation Envoyé par pseudocode Voir le message
    Depuis l'apparition des environnements RAD/WYSIWYG, cette pratique semble s'être un peu perdue en effet. En particulier pour les applications possédant une interface graphique.

    Citation Envoyé par martopioche Voir le message
    Oui mais aujourd'hui, c'est normal. On fait de l'Agile, on favorise la communication orale afin que les équipes communiquent plus vite, et le code parle de lui même. Alors la doc...

    Et le troisième problème (qui a aussi toujours existé) est la séparation bien trop grande entre "industrie informatique" et "clients", exprimée très bien par :

    Citation Envoyé par jmguiche Voir le message
    D'après mon expérience, de presque 30 ans, il y a deux types de "clients".

    Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.

    Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...

    Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.


    Je pense effectivement (et je l'ai dit de très nombreuses fois dans les débats concernés) que les méthologies (et leurs modes), qu'elles soient agiles ou non, sont MAL employées, TOUJOURS, car prises au pied de la lettre, alors que cela ne doit être qu'un guide...

    Que la mode des méthodologies dites "agiles" favorisent effectivement le développement de type brouillon, et l'émergence de nouveaux-venus dans le métier qui pensent qu'il suffit de réfléchir 5 minutes...

    Que l'échec des méthodes style Waterfall est de ne pas autoriser du tout de modifications en cours de route, et de penser que l'on peut tout modéliser de tête au départ...


    Et que fondamentalement il y a une erreur de fond sur les ressources humaines, comme mentionné ci-dessus...

    il y a eu (et c'est de plus en plus le cas) une formation universitaire déficiente, qui néglige presque totalement une approche "multi-disicplinaire" en spécialisant sur les langages ou la théorie, alors qu'il devrait y avoir à mon avis, ce qui est (un peu plus) le cas pour les développements scientifiques, plus des "utilisateurs généralistes très bien formés" que des "machines à coder".. (en gros des ingénieurs avec une culture générale grande).

    Ce qui entraîne les difficultés de rapport avec les clients (et les mauvaises perceptions de part et d'autre)..


    Et enfin maintenant il y a des formations diplomantes de "chefs de projet", ce qui est absurde, et que encore une fois le fait que la méthode employée soit agile ne change rien.. (alors que le contraire est bien précisé dans le Manifeste)


    En résumé pour moi le problème des ressources humaines dans l'industrie informatique est le pricnipal problème...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #47
    Membre averti Avatar de _Xavier_
    Profil pro
    Inscrit en
    Mai 2009
    Messages
    311
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2009
    Messages : 311
    Points : 390
    Points
    390
    Par défaut
    Les quatre valeurs fondamentales Agiles sont de valoriser2 :
    • l’interaction avec les personnes plus que les processus et les outils.
    • un produit opérationnel plus qu'une documentation pléthorique.
    • la collaboration avec le client plus que la négociation de contrat.
    • la réactivité face au changement plus que le suivi d'un plan
    Qu'est ce qu'il y a de rigide ici ?

    L'usage de "c'est la mode" à toute les sauces est aussi passé à la mode. On l'entend maintenant partout, tout comme critiquer des choses dont on n'a que des notions superficielles.

    La manière la plus objective de critiquer une méthode (les méthodes agiles en particulier) est de la pratiquer au moins une fois, dans un cadre approprié, avec des gens qui la maîtrisent bien.

    Le syndrome de la vieillesse fait parfois qu'on déteste tout ce qui est nouveau, et qu'on a tendance à se réfugier dans un passé mythique où tout était beau.

  8. #48
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 601
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 601
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Quand on ne sait pas lire, on n'essaye pas de donner des leçons... Le syndrôme de la jeunesse ne serait-il pas de parler sans avoir compris ??

    Où as-tu vu que quelqu'un disait que les méthodes agiles étaient rigides ????
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #49
    Membre éclairé Avatar de zeavan
    Architect
    Inscrit en
    Avril 2003
    Messages
    590
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : Autre

    Informations professionnelles :
    Activité : Architect

    Informations forums :
    Inscription : Avril 2003
    Messages : 590
    Points : 774
    Points
    774
    Par défaut
    Citation Envoyé par FR119492 Voir le message
    Bonjour à tous!

    Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:
    1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
    2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

    Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.

    Jean-Marc Blanc
    +100
    Je suis totalement d'accord avec cet avis, en tant que developpeurs nous sommes des super utilisateurs ou super client, il n'a rien de choquant de remetrre en question les exigences du client, apres un apprentissage approfondie de son domain.

  10. #50
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    Février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : Février 2003
    Messages : 433
    Points : 1 604
    Points
    1 604
    Par défaut
    Citation Envoyé par zeavan Voir le message
    Je suis totalement d'accord avec cet avis, en tant que developpeurs nous sommes des super utilisateurs ou super client, il n'a rien de choquant de remetrre en question les exigences du client, apres un apprentissage approfondie de son domain.
    Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

    Ce genre de réflexion me fait vraiment peur
    Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.


    PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"

  11. #51
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par zaventem Voir le message
    Tout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.

    Ce genre de réflexion me fait vraiment peur
    Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.


    PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"
    Sauf que si le client demande au plombier d'installer une douche en lui disant qu'il veut prendre des bains, je doute que le plombier ne lui fasse pas part de conseils dans ce cas.

    Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.
    C'est un problème récurrent d'ailleurs en informatique, beaucoup de clients demande au développeur de réaliser une solution sans lui faire part des besoins initiaux. Et résultat, ce sont souvent des projets qui se plantent car le client n'a malheureusement pas pensé à tout.

    C'est comme si j'allais chez le garagiste pour une panne et, plutôt que de lui expliquer la panne, je lui dis juste quelles pièces il doit changer.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  12. #52
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    Avril 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : Avril 2004
    Messages : 830
    Points : 1 430
    Points
    1 430
    Par défaut
    Citation Envoyé par Barsy Voir le message
    d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée
    Si le développeur discute directement avec l'utilisateur final, il est probable qu'ils arrivent rapidement à une solution simple, rapide efficace et bon marché.
    Heureusement qu'il existe des managers, chefs de projet, commerciaux, etc. pour valoriser la profession.
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  13. #53
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    Février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : Février 2003
    Messages : 433
    Points : 1 604
    Points
    1 604
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.
    C'est ce que je disais, un mission de conseil, pas définir lui-même les besoins.

    Disons qu'après réflexion, ce qui m'a surtout fait réagir serait cette partie là, partie appuyée par le message auquel j'ai répondu.

    Citation Envoyé par FR119492 Voir le message
    1. Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
    2. Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.

  14. #54
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Bonjour,

    Citation Envoyé par Nebulix Voir le message
    Si le développeur discute directement avec l'utilisateur final, il est probable qu'ils arrivent rapidement à une solution simple, rapide efficace et bon marché.
    Heureusement qu'il existe des managers, chefs de projet, commerciaux, etc. pour valoriser la profession.
    Il ne faut pas faire peur aux jeunes comme ca : il croiseront, tot ou tard, un manager correct, technique, qui comprend ce que fait son equipe, qui valorise le travail de ses ouailles, ...
    Pareil pour le chef de projet, mais plus dur pour le commercial

    Sinon, je trouve que simplement, il faut discuter, encore et toujours : expliquer au client que prendre des bains dans une douche sera difficile, lui montrer pourquoi, et voir avec lui s'il desire reellement prendre des bains, ou bien s'il a besoin d'un lavabo pour se brosser les dents.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  15. #55
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

    Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

    Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  16. #56
    Membre actif
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juillet 2009
    Messages
    130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2009
    Messages : 130
    Points : 276
    Points
    276
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

    Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

    Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.
    La "baignoire-douche-lavabo" étant installé dans la cuisine pour couronner le tout...
    MigouW

    La seule bataille perdue d'avance est celle que l'on refuse de livrer.


    Pensez au tag
    Ma réponse vous a été utile, votez plus 1 sur le message.
    Ma réponse est hors sujet, votez moins 1 sur le message.

  17. #57
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Le but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.

    Le but du client par contre est de réussir à acheter la douche au prix du lavabo.

    Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.
    Je ne sais pas d'où vient ce penchant des développeurs pour les analogies de plomberie...

    Une overdose de Mario étant jeune, peut-être ?
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  18. #58
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    Février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : Février 2003
    Messages : 433
    Points : 1 604
    Points
    1 604
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Je ne sais pas d'où vient se penchant des développeurs pour les analogies de plomberie...

    Une overdose de Mario étant jeune, peut-être ?
    C'est moi qui l'ai lancée et je n'ai jamais joué à Mario de ma vie, ça doit donc pas être ça. (ben oui, des comme moi, c'est peut-être rare mais ça existe)

    Bien tenté quand même

  19. #59
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    Avril 2004
    Messages
    830
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : Avril 2004
    Messages : 830
    Points : 1 430
    Points
    1 430
    Par défaut
    Les architectes savent aussi vous vendre une douche comme "salle de bains" http://www.maisonapart.com/edito/con...2-p10-5112.php
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  20. #60
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    938
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 938
    Points : 1 806
    Points
    1 806
    Par défaut
    Citation Envoyé par Barsy Voir le message
    Non, quand il s'agit de demande d'évolutions, celles-ci sont chiffrées et ajoutées au coût du projet. Ce sont les anomalies qui sont à la charge de la SSII. Évidemment, les commerciaux s'arrangent avec le client (faudrait pas le braquer non plus) et intègrent au projet une certaine partie des évolutions si leur coût est raisonnable par rapport à l'ensemble du projet.

    Dans le cadre d'une régie, ces questions ne se posent pas...
    Ca, faut vraiment être informaticien pour avoir des idées pareilles!

    En pratique, quand les délais s'allongent et que les coûts augmentent, le client ne se montre pas toujours raisonnable et fait preuve de mauvaise foi, arguant n'importe quoi pour que ce soit le prestataire qui assume les coût, même si la responsabilité est entièrement celle du client (genre envoyer le cahier des charges quinze jours APRES la date de fin du projet).

    Evidemment, tous les clients ne sont pas à ce point cauchemardesques.

Discussions similaires

  1. Réponses: 2
    Dernier message: 22/01/2010, 19h07
  2. Réponses: 1
    Dernier message: 17/04/2007, 14h07
  3. Façon d'écrire votre code
    Par reptils dans le forum C
    Réponses: 6
    Dernier message: 03/03/2007, 18h20
  4. Réponses: 3
    Dernier message: 17/08/2006, 05h11
  5. [VBA Excel] Comment écrire un code dans le ThisWorkBook ?
    Par WebPac dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 03/05/2005, 16h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo