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

Débats sur le développement - Le Best Of Discussion :

Programmation : les erreurs à ne jamais commettre lors du développement d’un produit


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 513
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 513
    Points : 78 710
    Points
    78 710
    Billets dans le blog
    2
    Par défaut Programmation : les erreurs à ne jamais commettre lors du développement d’un produit
    Programmation : les erreurs à ne jamais commettre lors du développement d’un produit
    Les 11 péchés mortels selon un livre d’Alan Cohen

    Le développement d’un produit est une aventure pleine de risques et d’obstacles à surmonter pour garantir le succès du projet. Un projet est plein de pièges et chaque surprise non découverte à temps pourrait s’avérer fatale pour la réussite du projet. Dans un livre intitulé « Prototype to product : a practical guide for getting to market », l’auteur Alan Cohen consacre son premier chapitre à présenter « les 11 péchés mortels pour le développement d’un produit ». Une synthèse de ce chapitre a été faite sur le site Oreilly.com, mais ici nous allons nous limiter aux « péchés mortels » auxquels les développeurs sont couramment confrontés dans leurs différents projets.

    La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui. Cet adage prend tout son sens dans le développement informatique car l’un des péchés mortels dans le développement d’un produit vient du vice de la paresse. Dans son livre, Alan Cohen explique en effet que c’est une erreur grave de faire les tests seulement après que les prototypes soient largement développés. Remettre les tests à la fin du développement peut conduire parfois à effectuer de grands changements alors que le projet est très avancé, ce qui est très coûteux. Les tests devraient vite commencer dans le développement, cela permettra de découvrir les surprises le plus tôt possible et d’entreprendre les actions nécessaires au bon moment.

    D’autres erreurs qui pourraient miner le projet découlent des hypothèses que nous faisons sur les besoins des utilisateurs. A ce niveau, le développeur pourrait commettre 2 péchés mortels selon Cohen. Le premier est de supposer que nous connaissons les caractéristiques que le produit doit avoir pour satisfaire l’utilisateur moyen. La plupart du temps, nous ne le savons pas parce qu’en tant que développeurs, nous avons tendance à mettre l’accent sur la technologie. Nous désirons plus de fonctionnalités et plus de personnalisations, alors que l’utilisateur ne veut qu’un outil attrayant qui pourra lui permettre de travailler efficacement.

    Une autre erreur à ne pas commettre est de se dire également que les utilisateurs savent ce dont ils ont besoin. Selon l’auteur du livre « Prototype to product », il se trouve souvent que ces derniers ne savent pas non plus ce qu’ils veulent mais plutôt ce qu’ils pensent qu’ils veulent. L’idéal serait donc de leur donner quelque chose à tester le plus vite possible - afin d’identifier leurs besoins réels - au lieu d’attendre jusqu’à la fin du développement.

    Le flou ou le manque de spécificité dans la planification d'un produit et son effort de développement est également une source majeure d'échec du projet. Il y a 3 péchés mortels qui découlent du flou : le manque de compréhension des exigences, l’absence d’un bon plan de projet et la non assignation de responsabilité.

    Si les deux dernières erreurs fatales liées au flou sont plus ou moins claires, il est important de revenir sur le manque de compréhension des exigences. A ce niveau, il faut noter qu’entre l’utilisateur final et le développeur, chaque intervenant a une certaine compréhension du produit que demande le client. Même si le client a une idée claire de ce qu’il souhaite, en exprimant son besoin, le produit qu’il décrit peut subir une modification et d’ores et déjà être différent de ce qu’il souhaite. Si le besoin est recueilli par une partie intermédiaire entre le client et le développeur, cette personne aura encore une compréhension un peu dégradée de ce que le client a exprimé ; alors le produit souhaité par le client subit une autre déformation. Jusqu’à ce que l’expression des besoins parvienne au développeur, le produit aurait déjà subi une profonde déformation. Le développeur va donc concevoir un produit selon la compréhension qu’il a eu des besoins de l’utilisateur. Il sera donc plus facile par exemple pour le client qui voulait une Lamborghini de se retrouver une Volkswagen.

    D’autres erreurs à ne pas commettre dans un projet découlent du vice de perfectionnisme. Le développement d’un logiciel peut avoir de grands enjeux, au-delà de l’obligation du développeur de bien faire son travail. Un logiciel réussi peut apporter la gloire et la richesse alors qu’un échec d’un produit destiné à une utilisation à grande échelle pourrait s’avérer désastreux. Le développeur veut donc produire quelque chose de parfait et cela peut parfois l’inciter à développer de nouvelles fonctionnalités. Ce que certains développeurs ne mesurent souvent pas, c’est que l’ajout de nouvelles fonctionnalités a un coût et un risque de mise en œuvre. Une fois que les exigences sont déjà définies, le calendrier est établi et le budget verrouillé. L’ajout de nouvelles fonctionnalités va donc nécessiter plus de temps et générer des coûts supplémentaires.

    Une autre erreur fatale liée au vice de perfectionnisme est de ne pas savoir quand arrêter le développement et livrer quelque chose au client. Un logiciel n’est jamais parfait, mais il arrive un moment où il peut être déjà libéré. Le développeur doit savoir s’arrêter à ce moment et donner quelque chose d’utilisable aux clients. Il y aura toujours la possibilité de faire des mises à jour sur le terrain, après que le logiciel ait été déployé.

    L’orgueil est également un vice qui peut miner un projet. Selon Cohen, ce serait une erreur grave pour le développeur d’exclure la possibilité d’un échec. Envisager la possibilité d’un échec ne contribue qu’à aider le développeur, qui sera plus avisé pour ne pas commettre les autres erreurs.

    Source : oreilly.com

    Et vous ?

    Qu’en pensez-vous ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre actif
    Homme Profil pro
    Développeur Concepteur WebMethods
    Inscrit en
    février 2015
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Concepteur WebMethods
    Secteur : Finance

    Informations forums :
    Inscription : février 2015
    Messages : 73
    Points : 207
    Points
    207
    Par défaut
    J'avoue ne pas avoir lu l'intégralité de l'article, parcourant la seconde moitié en diagonale. Mais, bien que je n'aime pas beaucoup le concept "d'évidence" balancé trop souvent à tort (tout le monde ne trouve pas naturel ce que certains prennent pour acquis), ici j'ai du mal à comprendre comment on peut ne pas trouver totalement logique et inné ce qu'affirme Cohen. Il ne nous apprend rien de concret et se contente simplement de défoncer des portes déjà largement ouvertes. Et ce sur tous les points qu'il soulève. Je doute qu'un développeur puisse aujourd'hui agir dans le sens des "pêchés mortels" qu'il évoque, à moins que ce même développeur n'ait tout simplement jamais travaillé pour qui que ce soit d'autre que lui-même. Et encore, même dans ce cas certains ne sont tout simplement pas envisageables pour peu que la personne ait le minimum des compétences requises pour mener un projet jusqu'à son terme.

  3. #3
    En attente de confirmation mail
    Homme Profil pro
    Chef de projet
    Inscrit en
    décembre 2005
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2005
    Messages : 24
    Points : 58
    Points
    58
    Par défaut
    Je suis assez d'accord avec DarkBakura, on n'apprend rien de nouveau... Au final, ces recommandations on les retrouve dans les méthodes Agile/Scrum.

  4. #4
    Expert confirmé
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    février 2005
    Messages
    3 435
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : février 2005
    Messages : 3 435
    Points : 5 787
    Points
    5 787
    Par défaut
    Citation Envoyé par DarkBakura Voir le message
    J'avoue ne pas avoir lu l'intégralité de l'article, parcourant la seconde moitié en diagonale. Mais, bien que je n'aime pas beaucoup le concept "d'évidence" balancé trop souvent à tort (tout le monde ne trouve pas naturel ce que certains prennent pour acquis), ici j'ai du mal à comprendre comment on peut ne pas trouver totalement logique et inné ce qu'affirme Cohen. Il ne nous apprend rien de concret et se contente simplement de défoncer des portes déjà largement ouvertes. Et ce sur tous les points qu'il soulève. Je doute qu'un développeur puisse aujourd'hui agir dans le sens des "pêchés mortels" qu'il évoque, à moins que ce même développeur n'ait tout simplement jamais travaillé pour qui que ce soit d'autre que lui-même. Et encore, même dans ce cas certains ne sont tout simplement pas envisageables pour peu que la personne ait le minimum des compétences requises pour mener un projet jusqu'à son terme.
    Citation Envoyé par hbomb Voir le message
    Je suis assez d'accord avec DarkBakura, on n'apprend rien de nouveau... Au final, ces recommandations on les retrouve dans les méthodes Agile/Scrum.
    Pour vous cela semble être une évidence, mais ça l'est au moment ou on vous le met sous les yeux. Dans le feux de l'action, on a parfois tendance à l'oublier car d'autre paramètres vien vous polluer l'esprit. Le manque de temps, l'envie de trop bien faire, l'envie d'utiliser une petite techno, être à quelque jours des vacances, le faite de faire plusieurs chose à la fois, etc.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  5. #5
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

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

    Informations forums :
    Inscription : juin 2004
    Messages : 47
    Points : 114
    Points
    114
    Par défaut
    En fait, tous ces péchés peuvent être évités avec l'application correcte d'une méthode Agile comme SCRUM: cela évite l'effet tunnel, le client est proche du développement, etc...

    *Edit*
    Ah, je vois que j'ai été devancé sur la mention de SCRUM

  6. #6
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 298
    Points : 476
    Points
    476
    Par défaut
    En fait A. Cohen fait plutôt référence au Lean Startup.

    Le "Client", c'est le marché. Et les techniques de Lean Starup sont là pour aider à mettre un produit sur le marché, le plus rapidement possible et si possible qui correspondent le mieux aux besoins du marché.
    On est encore dans des techniques agiles/itératives mais spécifiques au lancement d'un produit sur un marché.
    Pour les parties spécifiques au développement logiciel n'importe quelle techniques agiles pourra être mise en oeuvre, Scrum, Kanban, etc...

  7. #7
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

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

    Informations forums :
    Inscription : juin 2004
    Messages : 47
    Points : 114
    Points
    114
    Par défaut
    Citation Envoyé par spidetra Voir le message
    En fait A. Cohen fait plutôt référence au Lean Startup.

    Le "Client", c'est le marché. Et les techniques de Lean Starup sont là pour aider à mettre un produit sur le marché, le plus rapidement possible et si possible qui correspondent le mieux aux besoins du marché.
    On est encore dans des techniques agiles/itératives mais spécifiques au lancement d'un produit sur un marché.
    Pour les parties spécifiques au développement logiciel n'importe quelle techniques agiles pourra être mise en oeuvre, Scrum, Kanban, etc...
    Effectivement, d'ailleurs je regarderai cette méthode qui du coup s'adresse plus à une démarche d'éditeur grand public, non? Quelque chose d'assez adapté aux applications SmartPhone?

    Sinon, de mon expérience, SCRUM s'applique bien pendant une phase projet et Kanban pendant une phase de TMA, les rythmes et cadences étant assez différents.

  8. #8
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 298
    Points : 476
    Points
    476
    Par défaut
    Oui, l'objectif du Lean Startup c'est de designer de manière itérative des produits qui s'adressent à un large public.
    Cette technique s'applique plutôt aux startups IT qui veulent attaquer rapidement un marché.

    Dans le livre de A. Cohen (et les 4 ou 5 livres qui tournent autour), les différents auteurs adaptent ces techniques aux produits hardware, principalement pour le marché IoT.
    L'article semble enfoncer des portes ouvertes. Mais ce n'est que le résumé du premier chapitre d'un livre.
    Pour vraiment de faire une idée de ce que pense l'auteur il faudrait lire le livre en entier.

  9. #9
    Membre actif
    Homme Profil pro
    Développeur Concepteur WebMethods
    Inscrit en
    février 2015
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Concepteur WebMethods
    Secteur : Finance

    Informations forums :
    Inscription : février 2015
    Messages : 73
    Points : 207
    Points
    207
    Par défaut
    Citation Envoyé par berceker united Voir le message
    Pour vous cela semble être une évidence, mais ça l'est au moment ou on vous le met sous les yeux. Dans le feux de l'action, on a parfois tendance à l'oublier car d'autre paramètres vien vous polluer l'esprit. Le manque de temps, l'envie de trop bien faire, l'envie d'utiliser une petite techno, être à quelque jours des vacances, le faite de faire plusieurs chose à la fois, etc.
    Sur un instant T je ne nie pas qu'on peut se retrouver face à cette situation. C'est même très humain selon le contexte de l'instant. Mais j'évoquais un projet sur son ensemble. Sur sa durée totale, le bon sens incite à ne pas se lancer dans les "pêchés mortels" qu'évoque Cohen. Et je pense que même sans être un adepte absolu des méthodes agiles le développeur d'aujourd'hui est conscient de cela.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 678
    Points : 30 977
    Points
    30 977
    Par défaut
    Citation Envoyé par DarkBakura Voir le message
    Sur un instant T je ne nie pas qu'on peut se retrouver face à cette situation. C'est même très humain selon le contexte de l'instant. Mais j'évoquais un projet sur son ensemble. Sur sa durée totale, le bon sens incite à ne pas se lancer dans les "pêchés mortels" qu'évoque Cohen. Et je pense que même sans être un adepte absolu des méthodes agiles le développeur d'aujourd'hui est conscient de cela.
    Mais le décideur? Le décideur qui a soudain besoin d'un projet informatique, lui, ne sait rien de tout cela(et c'est normal).
    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.

  11. #11
    Membre actif
    Homme Profil pro
    Développeur Concepteur WebMethods
    Inscrit en
    février 2015
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Concepteur WebMethods
    Secteur : Finance

    Informations forums :
    Inscription : février 2015
    Messages : 73
    Points : 207
    Points
    207
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Mais le décideur? Le décideur qui a soudain besoin d'un projet informatique, lui, ne sait rien de tout cela(et c'est normal).
    Ca fait partie du métier, arriver à faire comprendre au décideur que la réalité technique n'est pas forcément compatible avec sa vision optimale des choses. Que le développeur qui semblerait lui faire perdre du temps vis-à-vis de son besoin ne le fait que pour optimiser le produit final et répondre au mieux à ses attentes. Il n'a pas la connaissance que nous avons, tout comme nous manquons forcément de données concernant ses enjeux et sa vision de son métier, et ce même après l'avoir questionné.

    Cela dit, je suis bien conscient, pour le voir au quotidien, que ce n'est pas une tâche facile, voire même possible selon le décideur ou l'environnement. Si tout était si simple, ça se saurait. Mais comme le sujet était axé autour du développeur plus que du reste, je me suis autorisé ce constat.
    Dans les faits, on sait que ce n'est pas toujours possible de mener "parfaitement" son projet, pour bien des raisons. Mais ce que je voulais dire par mes messages, c'est qu'initialement ce n'est pas censé être inhérent à la logique du développeur. Seulement lié à son environnement qui lui permet - ou non - de s'exprimer correctement dans son métier. De base, je pense qu'aucun développeur ne peut être autant à côté de la plaque que les points noirs soulevés par Cohen.

  12. #12
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 298
    Points : 476
    Points
    476
    Par défaut
    Citation Envoyé par DarkBakura Voir le message
    De base, je pense qu'aucun développeur ne peut être autant à côté de la plaque que les points noirs soulevés par Cohen.
    Sauf que le propos de A. Cohen ne s'applique pas uniquement au domaine du software. Par exemple relis uniquement le #1 de l'article original.
    Dans de l'intégration hardware (en cours de dév) + software ( en cours de dév ) + sous-systèmes mécaniques ( en cours de dev ), il est très facile de tomber dans les pièges évidents qui sont énoncés. Même si tout les membres des différentes équipes ont conscience de ces pièges.

  13. #13
    Membre actif
    Homme Profil pro
    Développeur Concepteur WebMethods
    Inscrit en
    février 2015
    Messages
    73
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Concepteur WebMethods
    Secteur : Finance

    Informations forums :
    Inscription : février 2015
    Messages : 73
    Points : 207
    Points
    207
    Par défaut
    Citation Envoyé par spidetra Voir le message
    Même si tout les membres des différentes équipes ont conscience de ces pièges.
    Ca rejoint donc ce que je dis. =)

    J'ai parlé des développeurs mais tu as raison évidemment, toutes les équipes sont concernées. Et encore une fois, je sais bien que dans les faits, même avec la meilleure des volontés, il est compliqué de pouvoir mener un projet de bout en bout sans tomber dans certains travers. C'est même normal, puisque plus les acteurs sont multiples, plus la cohésion en pâtit. Mais tous savent, normalement, quelles sont les bonnes pratiques, même si leur mise en application n'est pas forcément possible. C'est ce que je voulais dire depuis le départ.

  14. #14
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Qu’en pensez-vous ?
    Cet article est un plébiscite aux méthodes Agile.
    Tous les "péchés mortels" sont gérés et/ou corrigés par l'Agile...
    Bref, rien de révolutionnaire

  15. #15
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2015
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Burundi

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2015
    Messages : 2
    Points : 3
    Points
    3
    Par défaut josuekakomba
    je trouve que ces péchés exposé sont réelles dans chaque étapes du développement d'une application et j'en prend note..

  16. #16
    Expert confirmé
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    février 2005
    Messages
    3 435
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : février 2005
    Messages : 3 435
    Points : 5 787
    Points
    5 787
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Cet article est un plébiscite aux méthodes Agile.
    Tous les "péchés mortels" sont gérés et/ou corrigés par l'Agile...
    Bref, rien de révolutionnaire
    C'est bien pour ça que la méthode Agile existe, l'article ne fait que dire pourquoi celui-ci existe.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  17. #17
    Membre régulier
    Profil pro
    Inscrit en
    août 2013
    Messages
    40
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : août 2013
    Messages : 40
    Points : 70
    Points
    70
    Par défaut
    Article qui n'apporte que peu de valeur.

    Le premier point est déjà très bof
    "La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui."

    Souvent des tâches sont pas très bien définies! Il faut aussi attendre que la tâche soit "mature".

    Parfois une tâche peut être mature qu'après avoir fait une autre tâche qui nous permet de comprendre la première tâche.

    Si on se lance directement, on a le risque de faire du travail sans forcement avoir compris le but de ce travail. Et comme on a "commencé à coder", on a de la peine à mettre le travail effectué à la poubelle - donc on continue dans une voie qui peut être fausse.

  18. #18
    Expert confirmé
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    février 2005
    Messages
    3 435
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : février 2005
    Messages : 3 435
    Points : 5 787
    Points
    5 787
    Par défaut
    Citation Envoyé par gabriel.klein Voir le message
    Article qui n'apporte que peu de valeur.

    Le premier point est déjà très bof
    "La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui."

    Souvent des tâches sont pas très bien définies! Il faut aussi attendre que la tâche soit "mature".

    Parfois une tâche peut être mature qu'après avoir fait une autre tâche qui nous permet de comprendre la première tâche.

    Si on se lance directement, on a le risque de faire du travail sans forcement avoir compris le but de ce travail. Et comme on a "commencé à coder", on a de la peine à mettre le travail effectué à la poubelle - donc on continue dans une voie qui peut être fausse.
    En faite non c'est pas idiot. "il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui". Si tu peux le faire aujourd'hui c'est que la problématique que tu décris n'existe pas. Si nous suivons ta logique, tu attendras le dernière jour avant livraison en attendant d'être sur d'avoir tout le besoin.
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  19. #19
    Membre habitué
    Femme Profil pro
    Analyste d'exploitation
    Inscrit en
    juillet 2014
    Messages
    64
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 45
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2014
    Messages : 64
    Points : 134
    Points
    134
    Par défaut cela me rappelle une expérience
    Une autre erreur à ne pas commettre est de se dire également que les utilisateurs savent ce dont ils ont besoin. Selon l’auteur du livre « Prototype to product », il se trouve souvent que ces derniers ne savent pas non plus ce qu’ils veulent mais plutôt ce qu’ils pensent qu’ils veulent. L’idéal serait donc de leur donner quelque chose à tester le plus vite possible - afin d’identifier leurs besoins réels - au lieu d’attendre jusqu’à la fin du développement.
    cela me rappelle une expérience :
    j'avais intégré une structure pour laquelle je devais apporter de nouvelles fonctionnalités à leur applicatif (un ERP opensource fait maison et très bien conçu -aka très modifiable simplement).

    Les utilisateurs quotidiens me demandaient une nouvelle fonctionnalité pour leur simplifier la vie dans l'ERP: j'ai répondu qu'elle était possible et facile à développer sans problème.
    Le chef des utilisateurs me demandait une autre fonctionnalité pour empêcher ses subordonnée (donc les utilisateurs du logiciel au quotidien) de faire des erreurs : cette fonctionnalité était plus difficile à mettre en oeuvre mais faisable également.

    J'ai ensuite proposé à ce même chef, une autre fonctionnalité qui aurait permis au logiciel de faire tout seul le boulot (souvent eronné) que faisait ses utilisateurs avec l'ERP (en gros que les utilisateurs n'allaient plus avoir besoin de travailler avec cet ERP du tout et que le chef allait avoir le résultat instentanément en cliquant sur un bouton (+ des paramètres).

    Le chef a refusé cette fonctionnalité est m'a répondu (ça m'avait marquée) : non car si ils n'ont plus de travail à faire, je n'ai donc plus de responsabilité à les surveiller et je ne serais plus chef. Et surtout qu'elle ne voulait pas être responsabilisé d'avoir appuyer sur le bouton qui fait tout à leur place.
    Je lui avais rétorqué en gros qu'en leur enlevant cette tâche et en la faisant faire par l'outil informatique, ils allaient tous y gagner en temps/argent (environs 4jours/h par semaine) et qu'il pourrait profiter de ce gain temps pour leurs faire faire autre chose de plus utile en qualité/process que ces vulgaires tâches répétitives sur l'ERP (recherches,filtres,planifications suivant des règles simples).
    Le chef avait eu le dernier mot en disant quelque chose comme "contrairement à vous, mon boulot ne consiste pas à remplacer le travailler des hommes par des machines" mais à maintenir mon propre travail et à me rendre utile...

  20. #20
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 640
    Points : 2 346
    Points
    2 346
    Par défaut
    Mais par définition, on n'est pas vraiment utile si le travail qu'on fait peut être exécuté par une machine...

    PS : en même temps, dans mon métier (prof), on va aussi finir par être remplacés par des machines.

Discussions similaires

  1. Réponses: 3
    Dernier message: 25/04/2007, 14h53
  2. Réponses: 5
    Dernier message: 14/01/2007, 19h12
  3. Eviter les erreurs lors de l'utilisation des compo Tsocket
    Par Coussati dans le forum Composants VCL
    Réponses: 5
    Dernier message: 01/02/2006, 20h14
  4. Programme détectant les erreurs de mémoire
    Par gids01 dans le forum MFC
    Réponses: 2
    Dernier message: 07/12/2005, 11h57

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