Design : Le rôle critique de la découverte dans le développement de produits

En mars (avant Covid), un groupe d’entre nous était Jeff Patton et Jeff GothelfPropriété certifiée Scrum (CSPO). Bien qu’un certain nombre de concepts partagés soient familiers, cela nous a amenés à nous demander comment ils sont actuellement appliqués dans le contexte de notre propre organisation.

En particulier – quel est le rôle de la découverte en ce qui concerne l’unité de l’équipe produit, comment ces équipes trouvent un équilibre entre la découverte et la livraison, les outils dont elles disposent pour hiérarchiser leur découverte et notre approche générale pour tester les idées et les hypothèses.

Tout d’abord, comprenons exactement ce que nous entendons par découverte de produits, qui peut être défini comme:

«La découverte de produits décrit le processus itératif de réduction de l’incertitude autour d’un problème ou d’une idée pour s’assurer que le bon produit est conçu pour le bon public. Sur la base d’une découverte de produit, une équipe produit a une plus grande confiance dans sa voie à suivre. C’est également le fondement d’une mise en œuvre réussie et d’une phase de lancement ultérieure. » – Tim Herbig

Une autre façon de penser la découverte est comme un flux continu et continu d’activités menées par une équipe de produits (ou un sous-ensemble de) afin de déterminer, dans une certaine mesure, ce qu’il faut construire; avant de décider comment le construire.

Cela peut sembler évident, mais chaque projet de développement / travail important devrait commencer par une compréhension et une analyse des problèmes que les équipes cherchent à résoudre. S’agit-il de véritables problèmes que vos clients rencontrent régulièrement? Sont-ils suffisamment douloureux pour valoriser une solution? La résolution de ce problème ouvre-t-elle la voie à votre stratégie actuelle?

Il est trop facile de passer directement à la première idée préférée que nous avons, pour un problème que nous croyons exister. L’acte de découverte, cependant, nous permet de remettre en question ces hypothèses et d’encourager activement les équipes à consacrer plus de temps et d’efforts, opérant explicitement dans l’espace des problèmes.

La découverte sert à accroître la confiance des équipes dans la recherche du bon problème et de la bonne solution à ce problème; augmentant leurs chances de capacités et de fonctionnalités d’expédition que les clients apprécieront et utiliseront.

La découverte est donc la manière dont toute équipe produit moderne atténue les risques d’agir et de développer des idées qui:

1. Les clients ne valoriseront ni n’utiliseront (désirabilité)
2. Techniquement, nous ne pouvons pas mettre en œuvre (faisabilité)
3. Ne conduisez pas ou n’activez pas nos objectifs commerciaux (viabilité)

La découverte mange des hypothèses et des conjectures pour le petit déjeuner!

À ce stade, nous nous demandions « ne faisons-nous pas déjà cela … ou quelque chose comme ça? ». La réponse était «oui»… au moins dans une certaine mesure. Cependant, là où nous avons souvent eu du mal (et je soupçonne qu’il en va de même pour de nombreuses organisations), c’est pour établir un équilibre sain entre la découverte et la livraison.

Inévitablement, certaines organisations, et des équipes encore plus granulaires, le feront mieux que d’autres; où les meilleurs exemples semblent être ceux où les efforts de découverte de l’équipe sont planifiés, visibles et budgétés parallèlement aux activités de livraison. Dans ces équipes, la découverte est un citoyen de première classe.

Pour gérer cet équilibre et garantir le temps et l’espace nécessaires à la découverte, Jeff Patton, Marty Cagan et d’autres acteurs de l’espace Agile / produit ont été de grands partisans d’une approche de développement de produits appelée Développement à deux voies ou Agile Dual-Track.

Le principe est que tous les efforts de développement de produits s’inscrivent dans l’un des deux flux (découverte et livraison) et que ces flux doivent s’exécuter simultanément et en continu. Dans un monde pré-Agile, ce type de travail sur les connaissances aurait généralement été effectué en amont et avant tout effort de développement; entraînant efficacement la remise de spécifications et de conceptions longues sur la clôture.

Pas vrai non? Nous savons tous que l’histoire d’un projet coûteux qui a finalement été expédié au client, en retard et au-dessus du budget, pour se rendre compte qu’il n’a pas résolu un problème qui leur tenait à cœur, ou que la conception était si fondamentalement viciée que le résultat était un produit c’était tout simplement inutilisable. Aie!

Le développement en cascade, pour la majorité des organisations de logiciels, est devenu une chose du passé et Agile / Lean a promis une nouvelle voie à suivre, où les équipes travailleraient pour fournir des logiciels dans des boucles itératives plus petites. Une rétroaction régulière de leurs clients (fermant la boucle) leur permettrait d’apprendre rapidement et de changer de cap au besoin.

Cependant, à l’autre extrême, une focalisation pure sur la livraison, même dans un contexte Agile, ne sera probablement pas la meilleure approche pour déterminer ce que nous devons construire. Il existe de nombreux scénarios où la livraison est la bonne approche, mais où il existe un degré élevé de risque et d’incertitude, l’écriture de code est un moyen coûteux d’apprendre.

Comme le dit Jeff Patton:

«La façon la plus coûteuse de tester votre idée est de créer un logiciel de qualité production».

C’est donc là que la découverte prend tout son sens; s’assurer qu’il y a certains quantité de recherche et de conception effectuées en amont pour tester vos hypothèses les plus risquées de la manière la moins chère possible; donner aux équipes la confiance de savoir où dépenser leurs efforts de développement.

Dual-Track présente un modèle où un sous-ensemble de l’équipe se concentre sur la découverte, tandis que d’autres doublent sur l’écriture et la publication d’un logiciel de qualité de production. Ceux qui travaillent dans le domaine de la découverte sont inévitablement légèrement en avance sur ceux qui sont livrés à:

• Comprendre et définir les problèmes à résoudre
• Formuler des hypothèses vérifiables et déclarer leurs hypothèses
• Explorer des idées de solutions potentielles à ces problèmes
• Mener des expériences pour tester leurs idées et prouver / infirmer leurs hypothèses
• Créez des conceptions et des actifs prêts pour la production

Dans cette illustration de Tim Herbig, il montre un modèle de collaboration de découverte, avec les concepts de «collaborateurs permanents», de «collaborateurs temporaires» et de «supporteurs». Cela verrait des rôles comme les chefs de produit, les concepteurs de produits et les responsables techniques (dans notre cas) passer un plus grand pourcentage de leur temps à travailler dans des cycles de découverte, avec une implication plus rare (ou une collaboration temporaire) de la part de l’équipe élargie et d’autres parties prenantes immédiates.

Une note importante ici est que, bien que toute l’équipe ne soit pas directement impliquée dans la découverte (les organisations ont encore besoin de capacité pour expédier un logiciel fonctionnel), l’équipe plus large doit être alignée avec et comprendre ce qu’elle cherche à apprendre ensuite; ainsi que les grands thèmes (ou paris) plus loin dans la feuille de route. En fin de compte, les décisions prises ici (en amont) façonneront et informeront les futurs efforts de livraison (en aval).

En tant que telles, les équipes les plus efficaces ne sont pas seulement celles qui peuvent livrer sur les deux flux, mais aussi celles qui considèrent la découverte comme un élément central du processus de développement de produits. Les équipes doivent planifier et budgéter la découverte, tout comme elles le font pour les activités de développement. Il est donc important qu’elles puissent visualiser le flux de cet effort et comprendre les résultats; à savoir:

• Qu’essayons-nous d’apprendre?
• Qu’avons-nous appris?
• Qu’allons-nous faire / ne pas faire en conséquence?

Les meilleurs exemples d’un processus de découverte plus intégré sont ceux où les équipes intègrent la découverte dans la façon dont elles hiérarchisent, planifient, visualisent et examinent le travail de découverte en vol. Tissant essentiellement la découverte dans le rythme naturel de l’équipe et la découverte de la surface dans le cadre de leurs cérémonies d’équipe existantes, par ex. stand-ups quotidiens, critiques de sprint, show & tell.

Donc, après avoir compris le rôle de la découverte, la plus grande question est de savoir comment décider où et quand dépenser nos efforts de découverte? La recherche, l’exploration et la conception, comme tout aspect du développement, sont une ressource limitée; donc savoir quand mettre quelque chose dans le flux de découverte, par opposition à la livraison, est une partie importante et essentielle de la priorisation.

Selon Le mode de Tim Herbigl, la découverte et la priorisation des activités de découverte devraient être une partie régulière et routinière des conversations de développement. Ces conversations devraient apporter des perspectives du produit, de la conception et de l’ingénierie (AKA Trios de produits) pour établir une série d’hypothèses (stratégiques et tactiques) qu’ils cherchent à tester, dans la poursuite d’un résultat particulier.

Chaque hypothèse sera chargée d’hypothèses; certains sur les problèmes, certains sur les solutions. Le travail du groupe est d’établir sa perception du risque et de l’impact en mesurant son niveau de confiance; à la fois en termes de compréhension des problèmes des clients et d’efficacité de leurs idées.

Dans quelle mesure sont-ils sûrs de comprendre le (s) problème (s) des clients, de telle sorte qu’ils puissent raisonnablement commencer à explorer des idées pour les résoudre? Quels sont les risques et impacts potentiels de la mise en œuvre d’une idée sans la tester au préalable avec un groupe de clients?

Cela conduit à une autre question importante: Chaque travail / projet doit-il passer par le processus de découverte? La réponse est: «Non… pas toujours».

N’oubliez pas qu’il s’agit d’atténuer le risque de prendre des décisions médiocres ou mal informées. Jeff Gothelf a récemment publié son Toile de priorisation des hypothèses, qui est un autre outil de la même catégorie que la cartographie des hypothèses, pour aider les équipes à classer le travail et à déterminer la meilleure approche pour une opportunité donnée.

Il s’ensuit donc que pour les opportunités qui se présentent aux équipes avec un degré plus élevé de risque et d’incertitude, ce sont d’excellents candidats pour dépenser une partie de l’effort de découverte de l’équipe. Dans ce scénario, il y aura probablement un certain nombre d’inconnues-inconnues et un manque de preuves de première main; conduisant à de faibles niveaux de confiance dans le problème à résoudre ou dans la façon dont ils pourraient le résoudre (la solution).

Au contraire, pour les opportunités où il y a une plus grande certitude autour du problème à résoudre et où la solution est simple, claire et évidente, alors il y a moins besoin de dépenser leur effort de découverte. Au lieu de cela, l’équipe peut passer rapidement à la production (développement), où elle est en mesure de déployer une solution existante prête à l’emploi ou d’apporter des améliorations relativement mineures à certains aspects existants des fonctionnalités.

Comme vous pouvez le voir, il existe une pratique ici autour de l’analyse et de la hiérarchisation, nécessaire pour déterminer quand il est juste et approprié d’appliquer une approche par rapport à une autre; ainsi qu’un éventail de compréhension et de confiance nécessaires pour déterminer l’étendue du pipeline de découverte d’une équipe.

À ce stade, il vaut la peine de réfléchir à votre projet moyen. Selon le Double Diamond, il y a deux phases claires du processus de conception: l’espace des problèmes et l’espace des solutions. Lorsque les équipes s’efforcent d’atteindre un résultat particulier, elles auront des hypothèses sur le client, qui il est, quels problèmes ils rencontrent actuellement et la valeur qu’ils pourraient accorder aux solutions à ces problèmes.

Lors de la déclaration de leurs hypothèses, ils devraient chercher à délimiter celles relatives à l’espace des problèmes de celles de l’espace des solutions. Au début et au début d’une nouvelle entreprise / projet, les équipes auront probablement plus d’inconnues-inconnues par rapport au client et à leurs problèmes; où les efforts de «découverte précoce» devraient se concentrer sur la validation des problèmes.

Au fur et à mesure que les équipes avancent dans un projet et ont parlé ou observé leurs clients cibles, les rapprochant d’une définition du ou des problèmes qu’elles cherchent à résoudre, elles commenceront probablement à introduire des hypothèses davantage basées sur des solutions, à savoir les efforts / caractéristiques / capacités qui, selon eux, pourraient résoudre ce problème. Ici, il y a plus d’inconnues-inconnues sur la forme de la solution; où les efforts de «découverte tardive» devraient se concentrer sur la validation de la solution.

Au fil du temps, la portée et la fidélité de vos tests, ainsi que la forme de vos efforts de découverte changeront. Rappelez-vous, la découverte est l’acte d’aider les équipes à décider quoi construire («construire pour apprendre») et tout comme nous modulons et priorisons notre effort de découverte, nous modulons et priorisons également l’arriéré de tests (ou d’expériences) que nous exécutons. Rechercher les bonnes réponses au bon moment, en utilisant les outils et techniques les plus appropriés.

Une fois que l’équipe a déclaré ses hypothèses les plus risquées (concernant le problème ou la solution) et a identifié où elle doit consacrer ses efforts de découverte (rappelez-vous, vous n’avez pas besoin de tout tester), elle est prête à les tester. Cependant, il est important que la forme et la fidélité d’un test (ou d’une expérience) soient proportionnelles au niveau de risque et de récompense.

Le test le plus précis sera toujours un logiciel fonctionnel, mais nous savons que c’est aussi le moyen le plus coûteux et donc le plus risqué de valider une idée. Mais, si l’équipe a derrière elle un ensemble de preuves suffisamment concluantes pour suggérer qu’elle devrait simplement faire la chose, alors l’équipe peut décider si cela compense le risque et déterminer la taille de son investissement (un pari).

Giff Constable’s Courbe de vérité illustre bien cela. Chaque idée proposée par l’équipe peut être présentée comme un pari. Compte tenu des éléments de preuve disponibles, la meilleure estimation de l’équipe quant à la probabilité de réussite d’une idée (par rapport au résultat souhaité). Le modèle illustre comment les équipes peuvent adapter la fidélité de leurs tests à mesure que les preuves qu’elles rassemblent augmentent leur niveau de confiance.

Lorsque les équipes manquent de preuves de première main de la part du client (elles échangent des hypothèses) et ont une faible confiance dans l’idée, leur test devrait idéalement utiliser les méthodes les plus rapides et les plus rapides requises pour apprendre (par exemple, entretiens avec les clients et croquis). À mesure que leur confiance augmente, ils peuvent commencer à investir dans des méthodes de fidélité plus élevée qui pourraient permettre une rétroaction plus riche et plus concluante. À un moment donné, l’équipe est suffisamment confiante pour parier sur la maison, se lancer à fond et devenir une solution évolutive.

En conclusion, la découverte se fait mieux quand il s’agit d’une activité continue et continue, menée dans le cadre des pratiques de développement régulières de l’équipe. Les équipes parcourent une série de discussions sur la hiérarchisation et la planification – tout comme elles le feraient pour le travail de développement – en déclarant leurs hypothèses les plus risquées, les questions auxquelles elles doivent répondre en premier et la forme de leur prochain meilleur test.