Délivrer de la valeur

L'approche agile met l'accent sur la valeur délivrée au client, et encourage à fournir très rapidement une version du produit intégrant les fonctionnalités les plus importantes : nous verrons sur cette page comment repérer ce qui a de la valeur, comment prioriser, et la notion de MVP.

Le dessert avant l’entrée…

L’un des éléments fondamentaux de la philosophie agile est qu’elle encourage les équipes à livrer très tôt des éléments de valeur (comprenez des versions fonctionnelles du produit, même si elles ne couvrent qu’une petite partie, la plus intéressante possible, du périmètre fonctionnel de l’application).

Cette valeur, on l’appelle généralement « business value ».

Cette manière de fonctionner est souvent nommée « Mangez votre dessert en premier ! » : en d’autres termes, ne vous fadez pas tout l’apéritif, la prise de commande et les plats successifs avant de déguster le bon gâteau au chocolat, commencez par là !

ALT

Pourquoi ?

Imaginez que le restaurant brûle pendant le repas. Vous ne le verrez jamais, votre dessert. D’autre part, quand on commence par livrer au client des éléments importants pour lui et qui lui procurent beaucoup de satisfaction, on le met généralement de bonne humeur, disposé à collaborer efficacement sur le projet.

C’est l’opposé du discours (trop) courant du type « attendez, il nous reste encore 2 mois de conception, méta-modélisation, modélisation, documentation des méta-modèles, customisation du framework, tuning des API, écriture des scripts d’automatisation du déploiment des documentations, et on pourra commencer à coder vos fonctionnalités ! ».

Le coût du changement

Autre bonne raison de faire les choses importantes pour le client dès le départ : au fur et à mesure que le projet avance, les capacités d’action se rétrécissent…

Regardez plutôt ce graphique :

Capacité d'action et engagement financier au cours du temps

Vous l’aurez compris, plus on avance dans le projet, plus on dépense d’argent (il faut bien payer des gens comme nous pour travailler sur le projet…), et plus on perd de capacité d’action (les choses se précisent, les développements se concrétisent, les inter-dépendances s’accumulent, le client s’impatiente…).

Bref, tôt dans le cycle de vie du projet, on a plus de marge de manœuvre, on est plus à l’aise et plus serein pour travailler efficacement sur les sujets qui importent vraiment pour le projet et pour le client.

Comment savoir ce qui a de la valeur ?

Il existent beaucoup de métriques pour évaluer la valeur, par exemple des fonctionnalités d’un produit.

La plus connue de ces métriques est le ROI (return on investment, retour sur investissement), pourcentage exprimant le ratio des bénéfices reçu par rapport à l’investissement concédé.

D’autres métriques permettent d’estimer plus finement la rentabilité d’un projet, en prenant notamment en compte les taux d’intérêt, la dépréciation, etc. Citons par exemple la valeur actuelle nette (NVP : net present value) et le taux de rentabilité interne (IRR : internal rate of return). L’explication détaillée de ces concepts dépasse le cadre de cette formation, mais je vous encourage à consulter les excellentes vidéos de Gary Straughan à ce sujet.

Concrètement

Avant de vous attarder sur ces indicateurs, il existe une méthode simple qui permet généralement d’éviter bien des développements inutiles. Cette méthode est toute simple… Avant de planifier ou prioriser quelque chose, posez-vous toujours la question suivante :

Est-ce que ce truc va être utile à mon client, objectivement, en lui apportant de la valeur ajoutée ?

Si la réponse est non, ne le faites pas.

Même si ça semble sympa. Même si le défi technique est alléchant. Même si vous en avez marre de travailler sur les sujets actuels. Ne faites que ce qui apportera quelque chose d’important à votre client, à ses yeux !

Business value

Vision partagée

Il est notamment important de s’assurer que tout le monde a bien compris ce qui est attendu, sinon, des ennuis sont à prévoir…

Regardez cette illustration humoristique (tirée du site Gestion de projet informatique) :

Gulf of evaluation

Les anglophones appelle ceci « gulf of evaluation » : entre ce qui était nécessaire à l’origine et ce qui est réalisé en bout de course, il y a souvent de gros écarts, qui font que 45% des logiciels livrés ne sont simplement jamais utilisés !

Prioriser en fonction de la valeur

Une fois que l’on est d’accord que le fait qu’il est crucial de traiter en priorité les éléments qui présentent le plus de valeur ajoutée, il faut être capable de prioriser ces éléments, en collaboration avec le client.

Définir les priorités

Tout d’abord, il peut être utile, pour aider le client à distinguer les fonctionnalités à haut potentiel, de lui proposer différentes méthodes de qualification de ces features.

Les priorités

On peut par exemple lui proposer de poser un critère de priorité sur les éléments : P1, P2, P3…

Une « P1 » représente quelque chose de très prioritaire, « P2 » un peu moins prioritaire, etc. Une approche assez répandue…

La méthode MoSCoW

La méthode MoSCoW consiste à attribuer aux fonctionnalités attendues des « qualificatifs » de priorité :

  • Must have (je le veux à tout prix !)
  • Should have (il me le faut et je suis prêt à faire des concessions sur le reste pour l’avoir)
  • Could have (si c’est possible, j’aimerais l’avoir)
  • Won’t have this time but would like in the future (je sais bien que je ne l’aurai pas tout de suite, mais un jour, j’aimerais qu’on en parle…)
STOP – Notez que ces façons de faire peuvent mener dans des impasses : imaginez que le client qualifie toutes ses demandes en P1, ou « must have ». On fait quoi ?

D’autres méthodes plus efficaces permettent de forcer les parties prenantes à définir des priorités relatives : boire ou conduire, il faut choisir (d’autant que l’alcool est dangereux pour la santé…) !

Parmi ces méthodes, citons notamment :

La méthode des 100 points

Vous avez 100 points à distribuer, vous les accordez aux features qui vous semblent le mériter. Par exemple :

  • Authentification sécurisée : 60 points
  • Interface de recherche : 30 points
  • Envoi de mails de relance : 10 points
  • Back office de gestion des clients ← Au revoir et merci, vous n’avez plus de points !

Le « dot voting »

La méthode du dot voting (aussi appelée multi-voting, sticker voting, sticky-dot voting, sticking dots, dot-mocracy, dot democracy…) est simple : chaque personne devant estimer les priorités écope de 5 pastilles (parfois 3).

Ils placent les pastilles à côté du nom des fonctionnalités qu’ils trouvent importantes.

À la fin, les fonctionnalités qui ont récolté le plus de points sont considérées comme les plus importantes !

Établir une liste des priorités

Une fois que les éléments les plus importants sont identifiés, il convient d’établir une liste classée par priorités relatives : la priorité de chaque élément est estimée par rapport aux priorités des autres éléments.

Chaque fonctionnalité candidate est classée (rankée) par rapport à son importance, les plus importantes en haut, les moins importantes en bas.

On commence alors à entrevoir que le fait d’ajouter une feature dans la liste décalera inévitablement les autres, car la capacité de travail de l’équipe est limitée : les développeurs n’ont pas quatre bras, et les jours ne font pas plus de 24 heures !

Liste priorisée relativement

La qualité de travail que peut produire l’équipe pendant un laps de temps est appellée la vélocité de l’équipe.

D’autre part, ce laps de temps, pendant lequel l’équipe travaille sur un certain nombre d’items, s’appelle une itération.

Livraison d’incréments produit

Sur la base de ces éléments de valeurs priorisés, l’équipe va pouvoir travailler à délivrer des versions successives du produit.

En particulier, il va être question de livrer une version fonctionnelle du produit, la plus simple possible : on l’appelle MVP, pour minimum viable product. Il s’agit d’un ensemble de fonctionnalités opérationnelles suffisamment complet pour être utile à l’utilisateur.

Notez bien qu’il ne s’agit pas de livrer le produit fini ! Le tout est que ça tourne, et que ça présente un intérêt fonctionnel : s’il manque des choses, pas de panique, c’est même tout à fait normal. L’équipe y travaillera par la suite !

Testez-vous !

Qu’est-ce qui diminue au fur et à menue de l’avancement d’un projet ?
  • La capacité d’action
  • L’engagement financier
  • Le niveau de connaissance sur le projet
  • La possibilité de réaliser des changements importants
Qu’est-ce que la business value ?
  • Un indicateur de l’état d’avancement d’un projet
  • La valeur ajoutée que l’équipe peut délivrer que le client
  • La pertinence du business que réalise l’entreprise
L’équipe hésite entre deux fonctionnalités à sélectionner pour les prochains jours de travail.
  • Elle doit choisir celle qui a le ROI le plus fort.
  • Elle doit choisir celle qui a le ROI le plus faible.
  • Le ROI n’est pas un critère de choix.
Qu’est-ce que le « gulf of evaluation » ?
  • Le fossé qui sépare ce qui a été compris par l’équipe et ce dont le client avait vraiment besoin
  • La frontière entre la nécessité et le besoin
  • Une évaluation des risques d’un projet
  • Une erreur dans l’évaluation de la NPV d’un projet
MoSCoW et le dot voting sont des techniques de…
  • Priorisation
  • Reporting
  • Testing
  • Estimation

Commentaires