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 ? 
Envoyé par DarkBakura
