Les estimations c'est du bidon

A chaque fois que je lis ou rédige un devis, je me pose la question de sa pertinence pour un développement logiciel.

Parce qu'un logiciel vit au rythme des évolutions de l'entreprise qui l’utilise. Le contexte change, on s'organise différemment, on lance de nouveaux services.

A contrario, les devis figent la situation. Ils estiment un prix face aux besoins du passé. Parfois de façon volontairement flou avec le fol espoir que “ça permettra d’être flexible”.

Les devis donnent une fausse impression de sécurité, de maîtrise des coût. Et ils vous privent de l'essentiel : le droit de changer d'avis.

Parce qu'un devis accepté, c'est un lien contractuel entre un client et un fournisseur : on se met d'accord sur un prix en réponse à une demande. Une fois le deal validé, plus moyen de changer (même un peu) la demande sans changer le prix.

Sauf à avoir gravé dans le marbre un cahier des charges ultra-détaillé de ce qu'on veut, il va forcément y avoir des changements.

Et donc mécaniquement une remise en cause (à la hausse) du prix initialement prévu.

Parfois, c'est le développeur qui se trompe. Il m’arrive de sous-estimer le temps nécessaire pour réaliser ce qui est demandé.

Lorsque le développeur s'est complètement gaufré dans son estimation, il a deux options :

• Il en parle avec franchise avec son client, reconnais son erreur, et propose des solutions : augmenter le budget, rembourser l’acompte, ou ne pas faire le reste de ce qui était prévu par exemple.
• s’entêter dans son erreur, en ajustant le seul levier qui reste à sa main : la qualité du code.

Et voila le triptyque infernale d'un devis validé :

Vous voulez tenir le budget ? Alors vous n'aurez pas la possibilité de changer d'avis.

Vous changez d'avis pour prendre en compte une fonctionnalité importante pour les utilisateurs ? Alors il faut augmenter le budget. Ou renoncer à la qualité du code.

Valider un devis sur la base d'un cahier des charges, c'est prendre le risque de s'emprisonner dans ce triangle maudit.

Comment faire autrement ?

Le trio qui marche.

Remplaçons le triangle maudit par une version différente :

La façon la plus simple de respecter le budget, c'est de l'imposer au lieu de l'estimer.

Avec cette enveloppe budgétaire, vous allouez une réserve de ressources pour coder votre projet avec un niveau de qualité satisfaisant.

Mais comment garantit-on que l'on a TOUT ce qu'on veut à la fin ?

Et bien on ne le garantit pas.

Mais on fait mieux : on garantit que que chaque minute du projet est allouée à coder ce qu'il y a de plus important. Tout en gardant le droit de changer d'avis en cours de route.

"En fait les utilisateurs s'en fichent de <fonctionnalité prévue dans le devis> , ils préfèrent <fonctionnalité importante demandée par les utilisateurs>. "

• Triangle maudit => “Non, on fait ce qui était prévu dans le devis. On verra dans une version 2 comment ajouter ça”.
• Triangle vertueux => “OK. On place ce développement en priorité pour la prochaine itération”.

Conditions de réussite

C'est séduisant sur le papier, mais il y a quelques conditions à respecter pour que ça fonctionne :

Condition #1 : ne pas changer d'avis tous les jours.

Oui, si on passe son temps à zapper parce que chaque demande prioritaire chasse l'autre, on ne va pas avancer. Il faut impliquer les utilisateurs, mais ne pas sur-réagir à chaque remarque.

Le bon moyen est de collecter toutes les demandes et remarques dans une liste, que l’on priorise régulièrement (le backlog).

Condition #2 : livrer fréquemment.

Il faut penser à une démarche pas-à-pas, et non pas à un train dans un tunnel.

Pour vérifier que l'on avance dans la bonne direction, il faut livrer quelque chose qui fonctionne à chaque pas.

Oubliez les powerpoints du chef de projet. Une version en ligne qui fonctionne est la seule mesure d'avancement qui soit crédible.

Condition #3 : garder la vue d'ensemble.

Puisqu'on itère en ajoutant des fonctionnalités importantes, on fait face à un sérieux risque de construire un patchwork coloré auquel plus personne n'osera toucher dans quelques mois.

Il y a donc des seuils de refactoring à ne pas louper. Votre projet doit être pourvu d'un gardien de la qualité, doté du pouvoir d'allouer des ressources à améliorer le code sans que ça n'ajoute de fonctionnalité.

En résumé

Les devis que vous exigez vont probablement conduire à dépasser le budget sans avoir l'outil dont les utilisateurs ont besoin.

Le moyen le plus sûr de maîtriser son budget est de le fixer à l'avance, puis d'avancer pas à pas dans le codage en commençant par les fonctionnalités les plus importantes.

Les livraisons fréquentes de versions qui marchent auprès des utilisateurs permettent de piloter l'avancement du projet.

Un garant de la qualité d'ensemble doit cadrer les pratiques de développement et surveiller l'état du code pour éviter de dériver vers un patchwork impossible à maintenir sur le long terme.