Non-demande de devis ?

Je peux vous faire un devis pour vous rassurer. C’est un exercice facile qui tient compte de l’alignement des planètes et de la force du vent. C’est aussi un jeu dangereux pour vous et moi, chacun essayant d’être gagnant : si je passe moins de temps que prévu c’est moi qui gagne, sinon c’est vous. Je préfère des règles qui permettent aux deux parties de gagner.

Mais pourquoi l’estimation de la production d’un site, de code est-elle si aléatoire ? Une métaphore valant mille images, imaginons que vous vouliez apprendre une langue étrangère — au hasard le japonais. Vous me demandez alors un devis. Je vais vous faire une beau tableau avec des items (comprendre la structure des phrases, lecture des katakanas, etc), des durées et des prix associés. Le total vous permettra de savoir combien cela coûte d’apprendre le japonais. Ou pas.

En fait c’est beaucoup plus complexe que cela :

  • vous pouvez avoir déjà appris une langue étrangère approchante ;
  • vous pouvez rencontrer un japonais qui va vous faire progresser en dehors des cours ;
  • vous pouvez découvrir une application pour votre smartphone qui rend ludique l’apprentissage des kanjis ;
  • vous pouvez perdre la motivation pour aller au Japon et décider finalement de vous rendre en Australie ;
  • etc.

Si vous vous êtes engagé sur un devis avec un cahier des charges, vous allez être contraint d’apprendre le japonais alors que ça n’est finalement plus votre motivation ou de suivre des cours inutiles car vous avez déjà acquis ces concepts. Sans compter que l’apprentissage d’une langue se prolonge tout au long de la vie. C’est pour toutes ces raisons que les cours de langue se payent à la séance.

En informatique, nous sommes contraints à la même complexité :

  • une bibliothèque ou un framework vont nous permettre de gagner beaucoup de temps (ou d’en perdre) ;
  • un concurrent ou un nouvel usage va vous demander de pivoter et de changer votre produit du tout au tout ;
  • un test utilisateur va vous révéler qu’une fonctionnalité que vous pensiez essentielle est en fait inutile ;
  • un module que l’on pensait pouvoir développer rapidement s’avère finalement beaucoup plus coûteux ;
  • etc.

Quelle alternative au devis ? Le travail par itérations. On définit ensemble une durée relativement courte (2 semaines par exemple), on établit la liste des fonctionnalité avec une priorité et on reste en contact durant la période de développement. Au bout du temps imparti, on observe ce qui a été réalisé, on tente d’améliorer la fluidité de la collaboration pour l’itération suivante et on recommence si tout le monde y consent. Cette approche dispose de la flexibilité suffisante pour permettre de s’adapter tout au long de la construction de votre produit essentiel aux imprévus.

« Mais je ne sais pas combien cela va me coûter au final ? » Non, malheureusement le devis vous donne cette illusion mais personne ne peut estimer le coût de votre projet fini avant de l’avoir réalisé. Or un projet — comme tout apprentissage — n’est jamais terminé, c’est pourquoi nous préférons raisonner en terme de produit qui évolue et vit dans la durée. Voici une possibilité de développement avant de passer à une autre échelle :

  • 1 journée d’accompagnement pour vérifier la pertinence du produit auprès des futurs utilisateurs de manière orale ;
  • 1 première itération pour réaliser un produit minimal utilisé par les proches pour évaluer la pertinence de l’idée mise en pratique ;
  • 4 itérations de développement pour arriver à un votre produit essentiel qui permet d’accéder à d’autres types de financements.

Le coût d’une telle phase est de 30k€ et donne lieu à un produit utilisable par les early-adopters afin d’obtenir des retours permettant d’améliorer le produit lors d’une future phase.

« Mais pourquoi tout le monde fait des devis dans ce cas ? » La plupart des projets informatiques échouent et/ou ne répondent pas au besoin réel des utilisateurs. Cette pratique fait tourner l’économie, enrichit les SSII qui enchaînent les rallonges de budget et finit par dégoûter les porteurs de projets. Elle est confortable (au début !) pour le commanditaire car il est peu sollicité, elle est indolore au milieu car on lui demande de faire l’autruche et elle est clairement stressante au final lorsque le résultat est dévoilé et qu’il ne répond pas/plus aux besoins.

« N’est-ce pas dans votre intérêt de faire durer les développements ? » Je suis motivé par la production d’outils utiles et par la maximisation de la valeur créée sur le temps imparti. Mais y croire demande de la confiance qui se construira avec le temps. Je suis aussi motivé par le développement de code de qualité qui est réutilisable par une autre personne. Vous êtes libre d’essayer à chaque itération si vous trouvez que l’on n’avance pas suffisamment vite ensemble.

« Quel est le coût d’une itération ? » Une itération représente 10 jours de développement, soit 6000€. Elle va vous demander d’être réactif au quotidien et fera l’objet d’une présentation finale des fonctionalités développées. Tout au long de l’itération vous aurez accès au produit en cours de construction. Il est vivement conseillé de faire une journée d’accompagnement avant d’engager une première itération.

« Tout cela me parle, je veux essayer ! » C’est le moment d’entrer en contact :-).