Discussion :

[Michael Guilloux]

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 ?

[DarkBakura]

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.

[hbomb]

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.

[berceker united]

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.

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.

[DarkBakura]

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.

[el_slapper]

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).

[tanatiel]

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

[spidetra]

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...

[tanatiel]

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.

[spidetra]

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.

[Saverok]

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

[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..

[landry161]

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..

Moi également.

[berceker united]

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.

[gabriel.klein]

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.

[berceker united]

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.

[Ymer Leahcim]

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...

[CodeurPlusPlus]

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.

[berceker united]

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...

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.

[Ymer Leahcim]

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).