« Roadmaps Produits » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (Une version intermédiaire par le même utilisateur non affichée) | |||
| 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:// | 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. | ||
| Ligne 33 : | Ligne 33 : | ||
Les feuilles de route des produits doivent être très simples et de très haut niveau. Elles doivent refléter vos réflexions actuelles sur les objectifs les plus importants. S'agit-il de rendre le produit international ? De prendre en charge les appareils mobiles ? De prendre en compte des personas supplémentaires ? De résoudre les principaux problèmes d'utilisabilité ? La feuille de route n'a pas vocation à être une spécification, ni une liste exhaustive de fonctionnalités. | Les feuilles de route des produits doivent être très simples et de très haut niveau. Elles doivent refléter vos réflexions actuelles sur les objectifs les plus importants. S'agit-il de rendre le produit international ? De prendre en charge les appareils mobiles ? De prendre en compte des personas supplémentaires ? De résoudre les principaux problèmes d'utilisabilité ? La feuille de route n'a pas vocation à être une spécification, ni une liste exhaustive de fonctionnalités. | ||
N'oubliez pas non plus que si vous indiquez habituellement des dates cibles sur une feuille de route ("au premier trimestre, nous voulons lancer le produit au Royaume-Uni"), ces dates ne sont en fait que des espoirs et des souhaits. Ce n'est que lorsque vous définissez le produit dans le cadre de la découverte produit, que vous travaillez avec l'ingénierie sur les coûts réels en termes de temps, et que la gestion de projet/PMO planifie réellement le travail, que vous avez des dates réelles auxquelles vous pouvez croire. | |||
Aujourd'hui, les feuilles de route des produits sont presque toujours stockées sur un Wiki afin que l'équipe projet puisse les trouver facilement et prendre connaissance de vos dernières réflexions et raisonnements. | |||
Pour les équipes Agile, tous ces problèmes peuvent encore exister, mais il y a une autre catégorie de problèmes dont je parlerai dans un prochain article. | |||
Il s'agit d'un vaste sujet et il existe plusieurs techniques utiles et éprouvées pour s'assurer que vous choisissez les bonnes priorités et que vous communiquez votre planification à l'organisation. J'aborderai ces sujets plus en détail dans de futurs articles, mais si vous faites partie de ces chefs produits qui passent leur journée à passer au crible les demandes de fonctionnalités, à les classer par ordre de priorité et à les documenter, j'espère que cette note vous incitera à prendre du recul et à vous demander si ce n'est pas une raison pour laquelle votre produit ne progresse pas vraiment. | |||
