Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Programmation : les erreurs à ne jamais commettre lors du développement d'un produit
Les 11 péchés mortels selon Alan Cohen

Le , par Michael Guilloux

0PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de DarkBakura
Membre actif https://www.developpez.com
Le 12/06/2015 à 9:27
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.
5  0 
Avatar de berceker united
Expert confirmé https://www.developpez.com
Le 12/06/2015 à 10:33
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.
4  0 
Avatar de tanatiel
Membre régulier https://www.developpez.com
Le 18/06/2015 à 16:29
Citation Envoyé par ChristianRoberge Voir le message
Pour ma part, Agile a fait des efforts mais n'en déplaisent à ses admirateurs n'est pas LA solution.
Agile permet de simplifier les choses et de faire communiquer les différents intervenants...à condition de se poser les bonnes questions.

D'expérience quand un sujet a du mal à arriver à terme, je finis par poser la question "C'est quoi le besoin" et là, assez régulièrement, j'ai pu constater une différence assez notable entre la réponse donnée à cet instant et ce qui a été écrit dans les spèc. On en revient souvent à ce" problème d'expression, voire d'identification, du besoin.
3  0 
Avatar de hbomb
En attente de confirmation mail https://www.developpez.com
Le 12/06/2015 à 10:00
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.
2  0 
Avatar de youliken
Candidat au Club https://www.developpez.com
Le 16/06/2015 à 6:28
Cet article semble n'être vu que sous l'angle technique.
Certains point sont une conséquence justement d'un relâchement dans la qualité des livrables avant développement.
La méthode scrum ne doit pas être un justificatif, ni un palliatif aux mauvaises analyses.
Le développeur ne devrait travailler qu'avec des livrables et pas faire ce qui lui plaît.
2  0 
Avatar de Ymer Leahcim
Membre habitué https://www.developpez.com
Le 16/06/2015 à 9:27
Citation Envoyé par berceker united Voir le message
De ton point de vu cela te semble ridicule mais son point de vu est compréhensible. Il a compris que si tu réduis les tâches par personne, c'est pas pour en donner d'autre. Un autre va faire le calcule suivant : 4 jours homme par semaine de gagné alors ça fait 16 jours par mois et par tête = Suppression de poste. Si tu supprimes des postes alors il faudra pas de responsable, donc lui il saute.
oh mais je l'avais compris.
là où j'ai pas compris, c'est la peur de la personne "chef" et sa non-volonté à vouloir améliorer l'entreprise où elle bosse et la vie de ses saalriés subordonnés en leur faisant faire autrechose de qualitatif.
Depuis j'ai compris que lorsqu'on se rend compte d'une solution comme ça (réduisant les tâches itératives d'un groupe de personnes), il ne faut surtout pas en parler au chef, mais au supérieur hierarchique du chef (1 degrés de subordination plus haut).
2  0 
Avatar de kouskefil
Futur Membre du Club https://www.developpez.com
Le 18/06/2015 à 7:03
Je suis d'accord avec le fait que Cohen défonce les portes déjà grandement ouvertes, mais dans un domaine où l'autre de la vie, il y a toujours un débutant pour qui des conseils peuvent être donnés !
2  0 
Avatar de tanatiel
Membre régulier https://www.developpez.com
Le 23/06/2015 à 14:24
Citation Envoyé par Saverok Voir le message
Ecrit comme ça, oui.
Mais dans les faits, beaucoup ont du mal à le comprendre et/ou à l'accepter.

Il y a quelque temps, quand j'ai quitté le monde des sociétés de services pour passer côté client, j'ai eu à mon arrivée une discussion de ce type :
"
* Ce que tu me demandes ne correspond pas au SFD
* oui, mais le SFD a été écrit il y a 4 mois...
* je m'en fous, le SFD c'est le SFD !!
"

Je te laisse deviner lequel des interlocuteurs j'étais et ce qu'il est advenu du presta lorsqu'il est arrivé le moment de renouveler sa mission...
Disons que dans un projet où tout va bien, il est facile de faire des concessions et donc d'assouplir les règles et par conséquent d'accepter des modifications des SFD. Par contre quand le projet va mal et que tout le monde se braque et se cache derrière son contrat, le moindre changement peut poser problème...

Personnellement, quand je pose la question du "C'est quoi le besoin", c'est pour forcer l'interlocuteur à reformuler et ainsi à confirmer son besoin. Ensuite si son besoin correspond bien à ce qui était écrit, pas de souci on continue. Si ça diffère, on se pose et on réfléchit aux impacts de ce changement et à comment le prendre en compte. Agile n'est qu'une boite à outil permettant de gérer cette situation en donnant des règles simples et partagées pour la prise de décision.
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 12/06/2015 à 14:26
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).
1  0 
Avatar de berceker united
Expert confirmé https://www.developpez.com
Le 15/06/2015 à 11:33
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.
1  0