« Roadmaps Produits » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Aucun résumé des modifications
 
Ligne 16 : Ligne 16 :
Je comprends d'où cela vient, et il y a de nombreuses années, je l'ai fait moi-même, mais j'essaie d'expliquer pourquoi c'est une erreur à plusieurs niveaux.
Je comprends d'où cela vient, et il y a de nombreuses années, je l'ai fait moi-même, mais j'essaie d'expliquer pourquoi c'est une erreur à plusieurs niveaux.


Premièrement et avant tout, votre travail n'est pas de prioriser et de documenter les demandes de fonctionnalités. Votre travail consiste à livrer un produit de valeur, utilisable et faisable. La feuille de calcul des demandes de fonctionnalités va à l'encontre de cet objectif en faisant passer des fonctionnalités que les utilisateurs ne valorisent pas ou dont ils n'ont pas besoin, en augmentant la complexité, en diminuant l'utisabilité et en gaspillant des cycles de développement. J'ai écrit plusieurs fois sur les dangers de confondre les exigences du client et les exigences du produit (voir l'erreur numéro 1 en matière de produit ici : [https://svpg.com/papers/toppmmistakes.pdf www.svpg.com/papers/toppmmistakes.pdf], et les gars de 37signals ont publié un bon article sur le sujet il y a quelque temps : " Oubliez les demandes de fonctionnalités ".
Premièrement et avant tout, votre travail n'est pas de prioriser et de documenter les demandes de fonctionnalités. Votre travail consiste à livrer un produit de valeur, utilisable et faisable. La feuille de calcul des demandes de fonctionnalités va à l'encontre de cet objectif en faisant passer des fonctionnalités que les utilisateurs ne valorisent pas ou dont ils n'ont pas besoin, en augmentant la complexité, en diminuant l'utisabilité et en gaspillant des cycles de développement. J'ai écrit plusieurs fois sur les dangers de confondre les exigences du client et les exigences du produit (voir l'erreur numéro 1 en matière de produit ici : [https://light.lbl.gov/library/toppmmistakes.pdf www.svpg.com/papers/toppmmistakes.pdf], et les gars de 37signals ont publié un bon article sur le sujet il y a quelque temps : " Oubliez les demandes de fonctionnalités ".


Deuxièmement, cette approche va à l'encontre de la vision holistique de votre produit. Votre objectif est d'augmenter la conversion, ou d'aider les utilisateurs à faire leur travail, ou de permettre aux utilisateurs de trouver et de jouer leur musique, ou quoi que ce soit d'autre. Les demandes de fonctionnalités sont des théories spécifiques sur ce qui pourrait y contribuer, mais au stade de la feuille de route, vous n'avez pas la moindre idée de la pertinence des fonctionnalités décrites, ni de la possibilité de les concevoir de manière à ce qu'elles soient utiles et utilisables. Cela viendra lors de la découverte du produit. Verrouiller des fonctionnalités spécifiques au niveau de la feuille de route revient à sauter la partie la plus importante de votre travail, et la pierre angulaire des grands produits, à savoir la découverte du produit.
Deuxièmement, cette approche va à l'encontre de la vision holistique de votre produit. Votre objectif est d'augmenter la conversion, ou d'aider les utilisateurs à faire leur travail, ou de permettre aux utilisateurs de trouver et de jouer leur musique, ou quoi que ce soit d'autre. Les demandes de fonctionnalités sont des théories spécifiques sur ce qui pourrait y contribuer, mais au stade de la feuille de route, vous n'avez pas la moindre idée de la pertinence des fonctionnalités décrites, ni de la possibilité de les concevoir de manière à ce qu'elles soient utiles et utilisables. Cela viendra lors de la découverte du produit. Verrouiller des fonctionnalités spécifiques au niveau de la feuille de route revient à sauter la partie la plus importante de votre travail, et la pierre angulaire des grands produits, à savoir la découverte du produit.