Triabulle

“Je voudrais une application web qui investie en bourse à ma place selon mon niveau de confiance de la journée avec toutes les options configurables et des thèmes de couleurs dans 3 mois.”

Plusieurs développeurs afficheraient un sourire méprisant du développeur/connaisseur sur le client/ignorant et expliquerait avec un pointe de sacarsme : “c’est impossible à faire en si peu de temps voyons mon petit monsieur. Je vais faire une analyse complète de vos besoins et je vous rappelle bientôt”. Trois mois plus tard, le développeur revient avec l’analyse. “Ça va prendre 4 ans, 2 mois, 11 jours, 2 heures et 23 minutes” dit-il fier de lui. Mais qu’est-ce que le développeur a réellement estimé?

Le projet

Le client savait ce qu’il voulait. Il avait passé quelques heures à écrire un document sur ses besoins et à penser comment automatiser le plus possible chacune des actions. Le développeur ne connaissait pas grand’chose à ce domaine mais il était impressionné (sans le dire) par le document. Il ne savait pas ce que chaque point impliquait exactement mais avait une vague idée que ça serait long.

Dans son analyse, il avait exclu la demande de “thèmes de couleurs” puisqu’il s’agissait d’une fantaisie pour les yeux seulement et que ce n’était pas utile à l’application. Mais encore là, il avait coupé le temps de projet de deux semaines seulement. Il était encore loin du 3 mois voulu par le client.

Le temps

3 mois est un délai beaucoup trop court pour une application si complexe. Premièrement, comment connaître le niveau de confiance sans poser des dizaines de questions à chaque jour? Et puis, les configurations. Il peut y avoir tellement d’options que la gestion de tout ça sera extrêmement complexe. Il va me falloir deux pages de configurations différentes pour que je puisse tout entrer. Sans compter la structure de classe énorme pour gérer les états et les interdépendances entre elles. Ce client ne connaît rien au développement. Il est juste un gros cave.

Le temps versus le projet

D’abord, le développeur a raison. Le client ne connaît rien au développement (et tant mieux pour lui). Par contre, le client n’est pas “juste un gros cave” mais un professionnel qui a besoin d’une application pour améliorer ses performances. C’est ce que j’appelle un expert en son domaine. Si le client a eu cette demande pour développer une application en dedans de trois mois c’est qu’il aura accès à un nouveau service de la banque qui lui permettra de faire son travail plus rapidement et de sauver beaucoup d’argent. Mais pour l’utiliser, il doit changer ses méthodes de travail et c’est là que le développeur intervient.

Et si le temps de développement était plus important pour le client que le projet?

Par exemple, le nouveau service de la banque pourrait lui permettre d’augmenter de 5% ses revenus à tous les mois. L’application qu’il demande lui permet d’utiliser ce nouveau service. Si il s’en sert dès le lancement (dans 3 mois), il augmente incroyablement ses revenus à la fin de l’année. Si il doit attendre une année avant que l’application soit terminée, il perd 5% de revenus pendant quelques mois. Ce qui est important n’est donc pas l’application en elle-même mais le temps avant de pouvoir l’utiliser.

Fais ça vite

Le problème c’est qu’en tant que développeur, on entend trop souvent la phrase “C’est pour hier” et il faut tout faire rapidement et tout croche. Il faut bannir ce type de délai et toujours demander un temps raisonnable et minimum : “quand est-ce que vous avez besoin de cette application idéalement?”. Si la réponse est un mois, n’essayez pas de faire toutes les demandes mais montrez au client ce qui sera possible de faire en un mois. Si ça le satisfait, vous baissez votre niveau de stress et vous augmentez la qualité de votre travail.

Si il n’est pas satisfait, demandez-lui ce qui est réellement important pour lui et estimez le temps que ça vous prendra pour faire le minimum de ses attentes.

Si il n’est toujours pas satisfait, donnez le contrat à votre meilleur ennemi.