Revisite de la métaphore des skateboards et des voitures
Auteur : Marty Cagan
Source : Skateboards vs. Cars Revisited
Date : 31/05/2018
Traducteur : Fabrice Aimetti
Date : 03/02/2024
Traduction :
Il y a près d'un an, l'un de mes coachs Agile préférés, Henrik Kniberg, a publié un article qui, à mon avis, explique parfaitement comment les équipes techniques peuvent tirer parti du concept de MVP et s'assurer qu'elles tirent le meilleur parti des méthodes Agile. Si vous n'avez pas encore lu l'article d'Henrik, j'espère que vous prendrez quelques minutes pour le faire avant de continuer à lire cet article.
J'insiste ici sur les "équipes techniques" car, dans cet article, j'essaierai d'opposer le concept à celui des véritables équipes produits multifonctionnelles.
Pour être clair, lorsque je parle d'"équipes techniques", je décris une équipe composée uniquement d'ingénieurs, ou toute personne faisant partie de l'équipe a probablement un rôle de soutien tel qu'un simple product owner (par opposition à un véritable product manager).
En revanche, une équipe produit est composée d'un véritable product manager, d'un designer produit compétent et d'un certain nombre d'ingénieurs.
Ne vous méprenez pas : de nombreuses organisations ont simplement des équipes techniques, avec une personne désignée comme product owner qui suit les rituels Agile autour de la priorisation et de la gestion du backlog, mais qui n'a que peu ou pas de formation ou de compétences lui permettant d'assumer le rôle beaucoup plus large de product management.
Il en va souvent de même pour le product designer. Il peut avoir accès à un designer graphique, mais pas au designer produit spécialisé dans la conception de l'expérience utilisateur, le prototypage, la recherche utilisateur, l'interaction et la conception visuelle dont je parle.
Quoi qu'il en soit, si l'équipe ne dispose pas d'un véritable product manager ou d'un véritable product designer, je les renvoie généralement à l'article d'Henrik et leur dis que je pense que c'est le mieux qu'ils puissent faire.
Mais s'il s'agit d'une véritable entreprise produit axée sur la technologie, je leur fais comprendre qu'ils peuvent et qu'ils doivent faire mieux que cela.
Donc si vous disposez d'une véritable équipe produit multifonctionnelle, avec un product manager et un product designer compétents travaillant côte à côte avec les ingénieurs, comment vous y prendriez-vous pour réaliser ce travail ?
Dans l'exemple d'Henrik, l'équipe s'efforce à la fois de déterminer le bon produit à construire et de construire ce produit. Pour ce faire, elle dispose d'un outil principal : les ingénieurs. Ce que vous voyez est donc un produit développé progressivement, avec un effort important pour obtenir quelque chose que nous pouvons tester sur de vrais utilisateurs à chaque itération.
Henrik insiste sur le fait qu'ils construisent pour apprendre, mais ils le font avec le seul outil dont ils pensent disposer : les ingénieurs qui écrivent du code. Si vous lisez attentivement, Henrik mentionne que les ingénieurs n'ont pas besoin de construire des produits - ils peuvent construire des prototypes, mais avec la plupart des équipes que je rencontre, cet aspect est perdu de vue parce qu'ils ne comprennent pas qu'il existe de nombreuses formes de prototypes, dont la plupart ne sont pas destinés à être créés par des ingénieurs.
Examinons maintenant le premier principe que j'ai énoncé dans l'article Beyond Lean and Agile (Au-delà du Lean et de l'Agile). Si vous n'avez pas encore lu cet article, lisez-le maintenant, sinon ce qui suit risque de ne pas avoir de sens.
Le premier principe consiste à s'attaquer aux risques en amont, avant d'utiliser nos ingénieurs pour écrire une ligne de code de production. Plutôt que la notion relativement simpliste de skateboard/d'itération testable au plus tôt, nous plongeons plus profondément dans les risques et considérons explicitement la valeur, la facilité d'utilisation, la faisabilité et la viabilité économique.
Ensuite, sur la base des domaines que nous considérons à risque, nous choisissons l'outil ou la technique qui convient (la description des nombreuses techniques dépasse le cadre de cet article, mais je soulignerai qu'il existe quatre grands types de prototypes) et décidons s'il convient de le tester qualitativement ou quantitativement. Et nous testons non seulement avec les utilisateurs et les clients, mais aussi avec les autres membres de notre équipe et les différentes entités concernées de notre entreprise.
C'est le product discovery. Nous nous efforçons de trouver le bon produit à construire.
