Présentation du Dual Track Agile – la théorie
LEn juillet, j’ai eu la chance de suivre une formation de deux jours intitulée «Comment créer des produits que les clients adorent» Groupe de produits Silicon Valley. L’atelier a été intense et riche en informations, avec de nombreuses suggestions utiles pour notre équipe produit et notre processus de développement de produits. Dans cet article, je vais essayer de donner un récapitulatif des points que je considère les plus importants. J’ai mis ces principes en pratique avec mon équipe, et j’ai écrit un autre article où j’ai partagé l’expérience. Vous trouverez le lien en bas, au cas où vous voudriez y jeter un œil.
1. Le développement de produits doit être guidé par OKR
Les produits doivent avoir un visionet la vision devrait être déclinée à court terme objectifs. Sur la base de ces objectifs, vous, en tant que chef de produit, devez définir les mesures qui indiqueront si vous avez atteint vos objectifs ou non. Ces mesures sont appelées résultats clés (O = objectif, KR = résultats clés).
Peut-être que vous le saviez déjà. Mais ce n’est pas seulement pour vous. Ce qui est fondamental, c’est que toute l’équipe est alignée sur l’OKR et que tout le monde s’engage à les atteindre.
Si vous voulez en savoir plus sur OKR, je vous suggère ce postou le livre Radical Focus (voir les références ci-dessous).
2. Le lancement de fonctionnalités qui ne résolvent pas les problèmes n’est pas utile
Peu importe si vous souhaitez lancer de petites ou grandes fonctionnalités ou même de nouveaux produits, vous devez savoir précisément Pourquoi vous le faites. Donc, tout ce que vous faites devrait avoir pour objectif résultat clé.
Demandez-vous: si mon équipe développe cette nouvelle fonctionnalité, quelle est la mesure qui va s’améliorer? Si vous ne pouvez pas répondre à cette question, vous ne devriez même pas commencer le développement.
3. Personne n’a les réponses
Faire des produits, ce n’est pas comme résoudre des équations. Supposons que vous ayez identifié le problème, que vous sachiez quelle statistique vous souhaitez améliorer et que vous souhaitiez développer quelque chose pour le résoudre. Le fait est que personne ne peut savoir quelle sera la bonne solution.
le première supposition n’est souvent pas la meilleure. Les expériences précédentes, vos compétences, vos tripes, etc. peuvent être utiles, mais vous ne saurez pas si votre solution fonctionne avant de la publier et de la tester. Comme cela ne fonctionnera probablement pas, vous devrez modifier quelque chose et réessayer. Vous aurez besoin de plusieurs itérations pour atteindre votre objectif.
4. De nombreuses itérations «rapides»
Imaginons donc que vous ayez besoin de six itérations avant d’arriver à la bonne solution (en réalité, cela pourrait être bien plus que cela). Supposons maintenant qu’il faille un mois pour publier une nouvelle fonctionnalité et effectuer un test. Cela signifie que vous aurez besoin six mois pour trouver la bonne solution. Tu ne peux pas te le permettre. C’est pourquoi vous devez pouvoir effectuer beaucoup plus de tests en moins de temps. Plus vite vous êtes, plus vite vous trouverez la bonne solution.
Bien sûr, la création d’un produit ou d’une fonctionnalité complète prend du temps; il ne peut être atteint en quelques jours. Il est donc fondamental de développer des prototypes et MVP jusqu’à ce que l’idée soit validée. Parfois, vous pouvez même tester avec une fausse fonctionnalité. Ce concept est la base de toutes les approches Lean.
5. Les longs sprints peuvent parfois être un obstacle
Si tu utilises mêlée, vous savez qu’il divise le processus en sprints, généralement de 2 semaines (parfois plus). De plus, avant de commencer un sprint, vous avez besoin d’un Planification cela peut prendre quelques jours. Ce processus génère quelques problèmes: premièrement, vous ne pouvez publier que 1 à 2 fois par mois, pas très souvent; deuxièmement, dans chaque version, vous ajoutez plusieurs fonctionnalités, ce qui pose problème pour les tests, car vous devez tester un élément à la fois; Troisièmement, si vous connaissez le problème mais pas la solution, vous aurez besoin d’un sprint juste pour décider quoi faire, puis d’un sprint supplémentaire (ou plus d’un) pour développer la solution, cela rend les choses très lentes.
Peut-être que nous utilisions mal la mêlée. Je ne sais pas. Mais j’ai expérimenté ce problème à plusieurs reprises, et c’est l’une des principales raisons qui m’ont poussé à tester de nouvelles méthodes.
6. Agile à deux voies
La solution proposée est une méthodologie appelée agile dual-track, qui divise l’activité quotidienne d’une équipe produit en 2 pistes: Découverte et livraison. Les deux pistes vont en parallèle. Lors de la découverte, l’équipe identifie les problèmes et commence à réfléchir aux solutions, à concevoir des prototypes et à les tester autant que possible. Une fois le prototype validé, l’équipe peut commencer la livraison de cette fonctionnalité, ce qui signifie la construire.
L’idée est de tester autant de solutions que possible lors de la découverte et de rejeter toutes les mauvaises au cours de cette phase; de cette façon, seulement les bonnes solutions sont développés lors de la livraison.
7. Story Maps vs Backlog
Une autre suggestion consiste à utiliser un Carte de l’histoire comme point de départ, qui est une liste de toutes les idées possibles que vous avez concernant un produit. La carte d’histoire n’est pas le arriéré car les backlogs ne doivent contenir que des fonctionnalités validées, alors qu’ici, nous ne parlons que d’idées.
Périodiquement, l’équipe prend des histoires de la carte et commence la Découverte de ces caractéristiques.
8. Prototypes comme spécifications
Le résultat du processus de découverte devrait être un validé prototype: quelque chose qui a été soigneusement conçu dans tous les détails et déjà testé et validé avec qualitatif essai. Comme vos concepteurs UX peuvent vous le dire, il existe de nombreux types de prototypes et de nombreux outils pour les créer, en parler, il faudrait un article à lui seul.
Une fois que vous avez un prototype, vous n’avez généralement pas besoin d’écrire des spécifications ou des descriptions des tâches pour les développeurs. Les prototypes montrent déjà parfaitement, et mieux que toutes les spécifications, ce que l’équipe doit créer.
9. L’importance de l’équipe
Il y a une seule exigence pour tout ce qui précède: l’équipe produit. UNE petite équipe interfonctionnelle et collaborative de personnes responsabilisées et responsables concentré sur l’OKR. Toute l’équipe collabore pour la découverte et la livraison.
Habituellement, le chef de produit et les concepteurs de produits consacrent plus de temps à la découverte qu’à la livraison, tandis que les ingénieurs consacrent plus de temps à la livraison. Mais les ingénieurs sont également essentiels à la découverte, et ils doivent y consacrer du temps. Pourquoi? D’abord parce que les solutions doivent être réalisables et ensuite parce que les ingénieurs sont une excellente source d’idées.
10. Pour récapituler. Comment est-il censé fonctionner?
Vous connaissez les mesures clés que vous souhaitez améliorer et, sur cette base, vous sélectionnez les histoires dans la Story Map; vous les concevez et les validez, en créant des prototypes et en réalisant des tests qualitatifs. En parallèle, chaque jour, l’équipe prend l’un des prototypes validés et commence à le développer. Les nouvelles fonctionnalités sont publiées dès qu’elles sont prêtes. Une fois qu’une fonctionnalité est en ligne, vous la testez avec de vrais utilisateurs pour voir si vous avez atteint votre objectif, sinon, vous devez concevoir une nouvelle solution, avec des itérations rapides.
Facile, non? C’est du moins la théorie; nous savons que la réalité est généralement beaucoup plus difficile. Cependant, j’ai suivi ces principes au cours des 4 dernières années et je n’ai jamais eu aucun regret.
Si vous avez des commentaires, n’hésitez pas à laisser un message. Je serai heureux de savoir ce que vous en pensez.
J’ai écrit un autre article pour partager mon expérience en appliquant ces principes lors du développement d’un jeu mobile simple. Vous pouvez trouver l’article ici.
Références
- Inspiré: comment créer des produits que les clients adorent (livre de Marty Cagan)
- Comment créer des produits que les clients adorent (les ateliers)
- Radical Focus (livre de Christina Wodtke)
- Cartographie de la user story: découvrez toute l’histoire, créez le bon produit (livre de Jeff Patton)
- UX pour les startups Lean: Recherche et conception d’expérience utilisateur plus rapide et plus intelligente (livre de Laura Klein)