« Des roadmaps produits efficaces » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 20 : | Ligne 20 : | ||
C'est de là que vient le terme "Roadmap". Lorsqu'on utilise une carte routière, on sait toujours où l'on est et où l'on veut aller, et on a le choix entre plusieurs itinéraires. Certains itinéraires étaient plus courts, d'autres plus longs mais plus touristiques. En fin de compte, c'était à vous de choisir votre chemin optimal. Les roadmaps produits devraient fonctionner exactement comme leur homonyme, mais leur objectif a été perdu quelque part en cours de route. Aujourd'hui, les roadmaps fonctionnent davantage comme des diagrammes de Gantt. | C'est de là que vient le terme "Roadmap". Lorsqu'on utilise une carte routière, on sait toujours où l'on est et où l'on veut aller, et on a le choix entre plusieurs itinéraires. Certains itinéraires étaient plus courts, d'autres plus longs mais plus touristiques. En fin de compte, c'était à vous de choisir votre chemin optimal. Les roadmaps produits devraient fonctionner exactement comme leur homonyme, mais leur objectif a été perdu quelque part en cours de route. Aujourd'hui, les roadmaps fonctionnent davantage comme des diagrammes de Gantt. | ||
Les diagrammes de Gantt sont un outil de gestion de projet utilisé pour assurer le suivi des planifications et des échéances. Si les diagrammes de Gantt conviennent parfaitement aux grands projets de fabrication, ils ne sont pas adaptés à la plupart des logiciels en raison de l'incertitude qui entoure le développement. | |||
Lorsque nous décidons pour la première fois du produit logiciel à explorer, nous ne savons pas ce que veulent nos utilisateurs, et nous ne savons donc pas exactement à quoi ressemblera le produit fini. Il est donc pratiquement impossible d'estimer le temps que prendra la construction du produit. Pourtant, nous utilisons toujours ce modèle de diagramme de Gantt pour planifier notre travail, ce qui nous contraint à livrer des solutions à certaines dates. Les équipes sont frustrées par l'absence de flexibilité apparente dans ces planifications, et le management s'énerve lorsque les équipes ne livrent pas à temps. Le résultat est un tas de releases de fonctionnalités qui ne font pas de différence pour nos utilisateurs. | |||
Au lieu de cela, nous avons besoin d'un modèle qui nous aide à gérer l'incertitude et nous donne la flexibilité nécessaire pour la découverte et la livraison. Pour ce faire, nous nous concentrons sur les roadmaps produits qui se composent de résultats (''outcomes''), d'un thème et d'hypothèses, et nous écartons toute solution ou fonctionnalité non validée. | |||
Examinons un exemple que j'ai créé à partir d'une roadmap produit réalisée pour une équipe. J'utilise le site web du New York Health Exchange comme exemple de produit car je peux facilement identifier les choses qui doivent être corrigées - à savoir, beaucoup de choses. Je n'ai jamais travaillé avec eux et je ne prétends pas savoir comment ils fonctionnent en interne, mais je suis un client du site Web. C'est ainsi que j'aborderais l'amélioration du produit si je travaillais avec eux. | |||
[[Fichier:Example Product Roadmap - Google Sheets.jpg|border|link=]] | |||
