Outils à la prise de décision

Références :

• https://marcabraham.com/2021/09/28/my-product-management-toolkit-46-making-decisions/
• https://maa1.medium.com/my-product-management-toolkit-54-making-decisions-part-2-32c75c917ee1
• https://www.scaledagileframework.com/wsjf/

Il n’existe clairement pas une solution magique, permettant de gérer toutes les décisions que nous pourrions avoir à prendre, même dans le périmètre de notre produit. Avoir plusieurs outils sous la main, permet d’adresser des cas de figures variables de façon pragmatique (et accessoirement, rien ne nous interdit de paralléliser plusieurs solutions compatibles).

Décider sur la base des implications

Décision Type 1 / Type 2

Les sujets à décisions sont classés en deux grandes catégories sur une base : est-ce que la décision est réversible ou non.

• Type 1 : lorsqu’une décision est irréversible, comme un changement profond de l’organisation de l’entreprise, celle-ci doit faire l’objet d’une sérieuse réflexion.
• Type 2 : à l’opposé, une décision facilement réversible, comme un ajout ou suppression de fonctionnalité, peut être prise dans analyse approfondie, dans la mesure où il est facile de revenir en arrière.

Remarques :

• Dans le cas de décisions sur un produit, si les bons outils sont en place, de nombreuses décisions peuvent devenir réversibles, comme par exemple avec le continuous discovery, les méthodologies agiles, etc. Cela permet d’accélérer les processus de décision est accroitre la réactivité de l’organisation. Après, leur mise en place peut nécessiter un gros investissement (notamment si la mentalité de l’entreprise ne s’y prête pas à priori).
• D’expérience, la criticité d’une décision est rarement aussi binaire. Par exemple, le retrait d’une fonctionnalité peut être rendu facilement réversible, avec les bons moyens, sauf que … C’est une fonctionnalité clé de notre produit, et sont retrait, même temporaire, aura un impact désastreux sur l’image de l’entreprise. Dans ces cas là, une approche plus souple, sur la base de la gestion du risque (étude d’impact, etc.) serait plus pertinente.

La glissière de sécurité

En fait, il s’agit de la mise en place de principes, ou d’une stratégie d’entreprise, permettant d’orienter les prises de décision. La stratégie descend de la direction, et permet aux équipes de s’aligner sur une base commune pour les choix produit.

Remarque : ce genre de principes peuvent émerger d’eux-mêmes lorsqu’une équipe produit se trouve régulièrement confrontée à des problèmes similaires, ou à la suite d’une étude de marché révélant une tendance générale, etc.

Conséquences du second, voir du troisème ordre

L’idée est de clairement identifier séparément les conséquences (positives et négatives) à court terme (de premier ordre), de celles à plus long terme (du second ordre, et potentiellement à plusieurs années).

Le troisième ordre intervient quand on analyse différentes options sur leurs conséquences à long terme. Mettre en concurrences leurs avantages et inconvénients permet de repérer la meilleure alternative.

OODA

Mise en place par Reid Hoffman, cette méthode aide à prendre des décisions rapides sans oublier d’éléments clés :

• Observer les circonstances et faits concrets, c’est à dire la matière première pour notre future décision;
• Orienter, dans le sens où on prend un point de vue extérieur à l’organisation, par exemple un concurrent, pour faire abstraction (autant que possible) des biais;
• Décider quels actions entreprendre sur la base des différentes observations précédentes;
• Agir, c’est-à-dire mettre en œuvre la décision prise.

Inversion Thinking

C’est le concept général se cachant derrière la démarche de “pré-mortem”, c’est-à-dire envisager les conséquences de notre décisions, dans le cas où elle s’avère mauvaise. Présenté autrement, c’est exposer le point de vue du pessimiste (le Chapeau Noir de Bono) : on va explorer tout ce qui pourrait mal tourner, et voir quels en seraient les conséquences.

Penser les alternatives

SPADE

Si on revient au premier point (Décision Type 1 / Type 2), lorsqu’une décision est irréversible ou, plus généralement, possède un impacte non négligeable, la méthode SPADE est une solution intéressante.

Setting : identifier le contexte de la décision selon trois axes :

• “Quoi”, c’est-à-dire définir précisément le sujet de la décision (par exemple, avec la méthode des 5 Whys).
• “Quand”, pour identifier précisément le délai dont on dispose pour prendre notre décision.
• “Pourquoi”, dans le sens où on doit clairement identifier “pourquoi” cette décision doit être prise (on peut également retrouver ces infos avec les 5 Whys).

People : il s’agit d’identifier le rôle de chaque personne, dans cette prise de décision, sur un modèle de type RACI :

• “Responsible”, ou “réalisateur”, en français;
• “Accountable”/”Approver”: ou “responsable”/”Approbateur”, en charge de la supervision;
• “Consulté” afin de répondre aux Grandes Questions sur le sujet (et on ne répond pas “42”, à moins que la question ne soit mal formulée);
• “Informé”, pour désigner les personnes intéressées par la prise de décision, mais non acteur de celle-ci.

Alternatives : étant jamais certain de la validité de notre solution, il s’agit de prévoir des alternatives réalistes, variées, et couvrant également le problème. Sur ce point, on peut revenir à la démarche de découverte des solutions proposée par Teresa Torres, dans Continuous Discovery Habits.

Decide : bien évidemment, il arrive un moment où il faut prendre “la” décision. Gokul Rajaram, créateur de cette méthodologie SPADE, recommande une méthode de type vote à bulletin secret. Là, aussi, on peut renvoyer à la proposition de Teresa Torres, qui inclut l’étape de choix de “la” solution.

Explain : une fois la décision prise, on doit être capable de la présenter, et de l’argumenter à qui de droit (typiquement, les approbateurs).

Prioriser plusieurs opportuntiés

RICE

C’est une formule, litérallement “mathématique”, permettant de prioriser les opportunités.

• Reach : somme pondérée des clients impactés. La pondération se fait sur la valeur escomptée sur l’opportunité. On peut par exemple pondérer sur le bénéfice financier que l’on escompte, et donc se baser sur le chiffre d’affaire des clients impactés.
• Impact : dans quelle mesure ces clients sont impactés. On parle ici du délai acceptable par le client, voire du caractère bloquant du sujet (cf. MoSCoW).
• Confidence : dans quelle mesure avons-nous confiance en nos estimation (i.e. reposes-t-elle sur des faits, des intuitions, etc.).
• Effort : charge de travail pour élaborer notre solution.

Calcul : RICE = (R * I * C) / E

Plus la valeur est élevée, plus le sujet est prioritaire.

La portée et l’impact sur les clients repose sur la connaissance de ces derniers. Dans l’idéal, un PO/PM est en mesure d’aller au devant des clients directement pour obtenir ces informations. Il peut également se reposer sur les équipes au contact des clients (supports, commerciaux, etc.) et sur des éléments statistiques (analyse des données).

Remarque : estimer la valeur apportée sur une opportunité aux clients est l’une des tâches les plus complexes à évaluer, car elle repose sur les attentes des utilisateurs finaux de notre produit. Cette partie du travail repose en grande partie sur la connaissance du client, et une part de ressenti (le “feeling”).

L’effort repose sur la maîtrise du métier en interne. Par exemple, si le sujet est nouveau, et nécessite de nouvelles technologies, il faut envisager le coût pour acquérir les connaissances nécessaires. L’effort peut également impliquer de vraies connaissances techniques, car une évolution, en apparence minime d’une fonctionnalité, peut en réalité nécessiter une refonte d’architecture sur un composant de notre application. Et cette connaissance se reposera sur l’expertise des équipes, ou d’un architecte. Cela nous renvoi d’ailleurs à la composition type d’une équipe produit (cf. encore une fois Continuous Discovery Habits, mais d’autres références sont également d’accord, sur ce point).

WSJF

“Weighted Shortest Job First” Cette méthode vient de SAFe.

Cost of Delay : correspond à l’impact qu’aura le délai sur le client et le business de l’entreprise.

• Impact relatif : Valeur relative de la fonctionnalité pour nos clients (i.e. qu’est-ce qu’il attend le plus parmi les fonctionnalités qu’il attend)
• Urgence : De quel délai disposes-t-on ? Est-ce que le client a un moyen de contournement ? Est-ce que c’est bloquant ? Une date précise est fixée ?
• Valeur business : est-ce que cette fonctionnalité réduit un risque donné, ou ouvre des opportunités pour l’entreprise ?

Cost of Delay = Impact relatif + Urgence + Valeur business

Chaque clé sera sur une échelle identique, par exemple de 1 à 10 (ou alors utiliser la suite de Fibonacci modifiée).

Job Size : il s’agit de la charge de travail que représentera le traitement de la demande.

• Niveau actuel des ressources,
• Dépendances sur d’autres ressources,
• Compétences déjà disponibles / nécessaires à acquérir,
• etc.

Les critères dépendent des protagonistes dans l’équipe, et pourra être mise à jour en conséquence. Il faut donc la construire avec les membres de l’équipe, pour prendre en compte leurs spécificités.

Quoi qu’il en soit, le Job Duration doit être ramené sur une échelle similaire, d’une opportunité à l’autre.

Calcul : WSJF = Cost of Delay / Job Size

Comme pour le RICE, plus la valeur est élevée, plus le sujet est prioritaire.

MoSCoW

“Must / Should / Could / Won’t do”

Cette méthode peut se combiner avec l’une des précédentes pour répartir les sujets à leur arrivée dans le backlog Produit.

• Must do : ce qui est vital.
• Should do : ce qui est essentiel (sans être vital).
• Could do : ce qui apporte du confort aux utilisateur si c’est traité.
• Won’t do : ce qui est du registre de l’optimisation, ou du superflu.

MoSCoW permet de donner une vision “grosse maille” des priorités, et fournit un cadran “Won’t do” permettant de conserver une trace des propositions qui n’ont pas été retenu par l’équipe Produit.