Design To Cost, ça te parle ?
C’est l’idée de fixer le prix que ça coûtera avant de faire le travail, plutôt que de le découvrir après avoir fait le travail.
Le contraire de l’agilité ?
Ca peut sembler à contrepied de l’agilité, qui s’implémente souvent sous la forme de sprints ou autres itérations et une facturation au dit sprint. Dit autrement : on fait avec ce qu’on a, et on verra combien ça coûtera à la fin.
Je vous l’accorde, bien faite, cette approche non prédictive a le mérite d’être équitable, notamment en suivant cette maxime qui m’est chère :
“Tout travail mérite salaire.”
Bon… Après, cette approche peut aussi être mal mise en œuvre, avec une équipe qui travaille sur ce qui lui chante, et à la fin on a une facture salée et rien d’exploitable 🤷
#TrueStory
Travailler à budget contraint
Le contrepied de cette démarche, ce serait justement de fixer d’office le montant de la facture. On travaille directement à budget contraint.
Bien sûr, là aussi on peut mal mettre en œuvre cette démarche, et se retrouver avec un bon vieux forfait des familles, qui impose un périmètre fixe pour un coût fixe. (et tant qu’on y est — un délai fixe aussi !)
Bien mis en œuvre, par contre, c’est une approche redoutable.
Pour commencer, le premier bénéfice c’est la facilité de s’engager pour le client : il sait déjà combien il paiera !!! C’est bien plus facile à accepter que de ne pas savoir ce qu’on aura à la fin et de ne pas savoir non plus combien ça coûtera… 😕
Mais ce n’est pas tout. C’est un excellent moyen d’embarquer le client dans l’aventure agile de l’équipe. Le budget étant limité d’emblée, on se retrouve tôt ou tard dans la situation de devoir décider, arbitrer, prioriser, découper — le nerf de la guerre si je puis dire !
Attention au cahier des charges
Le danger réside dans le périmètre fixe qui prend la forme d’une spécification détaillée. C’est ce qui qualifie le traditionnel “forfait” qui est pour le moins casse-gueule si vous me permettez.
Pour les meilleurs résultats, mieux vaut partir d’un objectif. Quelque chose qui a du sens, qui a de la valeur. Surtout pas un cahier des charges.
Et là, tu comprends sûrement en quoi cette approche est complètement agile : Design To Cost, ça veut dire fixer le prix en avance, mais pour un périmètre qui n’est pas fixe.
Ca ne veut pas dire que seul le client prend des risques : si on ne lui garantit pas ce qu’il aura à la fin dans le détail (on ne s’engage pas sur le quoi ni sur le comment), on lui garantit par contre que son problème sera résolu (on s’engage sur le pourquoi, sur le besoin, sur l’objectif).
Les vrais critères d’acceptation
Ce qui tire la question de comment définir l’objectif et comment valider son atteinte !
Pour un objectif, cela peut prendre la forme de KPI et de cibles à atteindre sur ces derniers. On sait qu’on y est quand les compteurs indiquent tels niveaux.
Cette approche permet même d’envisager une logique d’intéressement au résultat : plus on explose la cible, plus on a une grosse prime.
Pour un problème à résoudre, on va plutôt se tourner vers des critères d’acceptation. Mais attention : de vrais critères d’acceptation. C’est à dire des scénarios, mais qui décrivent le problème de l’utilisateur, et non pas la solution.
Quelque chose qui soit lié au problème et à sa résolution, tout en laissant le plus de marge de manœuvre possible pour définir et mettre en œuvre la résolution du problème.
Bien sûr, à nouveau, l’enjeu est de ne surtout pas fixer le périmètre du travail à faire, et d’ainsi pouvoir tirer les bénéfices de l’agilité.
Avoir les bonnes discussions, prendre les bonnes décisions
Dans le modèle traditionnel, on suit cette boucle infernale qui ne fait que des perdants :
J’ai un problème à résoudre
→ Je demande combien ça coûterait pour le résoudre
→ La personne ou l’équipe ne veut pas se retrouver à s’engager sur un montant trop faible pour bien faire le travail, donc elle essaie d’envisager tous les cas de figure, tous les pires scénarios, bref elle gonfle son estimation (en toute bonne foi)
→ Je trouve que c’est trop cher par rapport au bénéfice potentiel donc je refuse
… Et je ne comprends pas pourquoi ce partenaire (potentiellement interne, potentiellement la DSI) est incapable de livrer quoi que ce soit en un délai convenable→ La personne ou l’équipe a déjà investi du temps pour répondre à la requête initiale ; ce temps est purement et simplement perdu, sans bénéfice
… Et ils ne comprennent pas pourquoi on leur fait perdre leur temps→ D’un côté comme de l’autre, la défiance se développe
En mode Design To Cost, on inverse tout, et cela génère énormément de dynamiques positives. Cela ressemble plutôt à ça :
J’ai un problème à résoudre
→ Je demande combien ça coûterait pour le résoudre
→ On me demande plutôt combien je serais prêt à investir pour le résoudre
→ Je fais des projections de bénéfices potentiels et j’identifie un budget cohérent avec le problème à résoudre
→ La personne ou l’équipe se positionne directement avec ce budget en tête et propose des solutions cohérentes avec le budget en termes de complexité, de robustesse et de complétude fonctionnelle
→ Nous travaillons ensemble pour affiner la solution, en gardant en tête les enjeux à résoudre et les bénéfices potentiels
Rien de plus agile, pas vrai ? 😊
Ce mode de fonctionnement favorise directement les discussions et la collaboration vers l’atteinte de l’objectif qui devient commun.
Plus facile à dire qu’à faire… Comme le Sprint Goal
J’ose espérer t’avoir convaincu du bien fondé de la démarche.
Maintenant, bien entendu, la difficulté reste dans la conduite du changement. Et là, ce n’est pas si évident !
Ce changement de penser objectif plutôt que périmètre n’est pas nouveau. La majorité des Scrum Masters s’y sont confrontés lors de la mise en place du Sprint Goal de Scrum : faire en sorte que l’équipe possède un objectif pour guider la construction et le déroulé du Sprint, plutôt qu’une liste de choses à faire.
Et c’est là qu’on touche du doigt tout ce qui rend difficile ce changement : quand on n’a pas une équipe pluridisciplinaire qui peut se positionner au niveau de la résolution du problème, mais un ensemble de personnes, spécialisées, qui ne peuvent s’engager que sur leur domaine. Dans ce cas de figure, cette notion d’objectif n’a aucun sens ; au mieux, elle est superficielle.
Si on sort du contexte de Scrum, le parallèle fonctionne toujours. Pour pouvoir s’engager sur la résolution d’un problème ou l’atteinte d’un objectif plutôt que sur un périmètre, il faut un dispositif qui soit au même niveau, à un niveau qui permet de résoudre le problème ou atteindre l’objectif.
Tout cela afin de pouvoir avoir une véritable discussion sur l’objectif.
