Faire peur !

La première étape à mon avis, c'est de dégoûter votre prospect d'entrée de jeu des méthodes traditionnelles. Le forfait, c'est berk !

Désolé, je ne peux pas vous fournir de devis. Je ne travaille pas comme ça. On ne travaille plus comme ça dans l'industrie ! (à prononcer sur un ton outré)

J'explique ensuite que ce genre de méthodes de travail n'est pas adapté aux spécificités du développement logiciel. À la base, les méthodes employées pour construire des logiciels dérivaient des méthodes employées dans le bâtiment. Dans le BTP, l'architecte est chargé de recueillir les besoins et de tracer les plans. Ensuite, le processus de constuction suit fidèlement les plans pour fournir ce que le client attendait.

On a commencé par croire qu'on pourrait fonctionner à l'identique pour construire des sites web. D'abord, on recueille des besoins, on écrit un document de spécifications, puis on développe en suivant les spécifications avant de livrer un produit fini.

Seulement voilà ! Dans le bâtiment, traduire un besoin en plan est relativement aisé. Vous voulez un mur ? Tracez un trait et hop ! Vous avez un mur. Par contre, une fois la construction commencée, il n'est plus possible de modifier les plans.

Dans le logiciel, c'est différent. C'est même tout le contraire ! Il est relativement facile de modifier l'existant. On peut toujours ajouter une nouvelle fonctionnalité, en modifier, etc. Par contre, traduire un besoin en un cahier de spécifications détaillé et exhaustif est un exercice hautement périlleux.

Un logiciel est quelque chose d'immensément complexe. Il n'est pas possible de décrire un logiciel sur papier avec un niveau de détail suffisamment précis pour ne laisser aucune place à l'interprétation. Il reste toujours une part de subjectivité.

Par conséquent, toute méthode de gestion de projet qui n'est pas basée sur un échange permanent entre un client et son prestataire est vouée à l'échec.

Présenter l'alternative : les divines méthodes agiles.

Sans entrer dans les détails, vous commencez à faire comprendre à votre prospect que son projet va potentiellement foirer, et que vous savez des choses qu'il ne sait pas. Le moment est venu de montrer votre expertise en présentant l'alternative.

Quand on a constaté ces problèmes, des experts reconnus de l'industrie se sont réunis pour inventer de nouvelles méthodes de gestion de projet, adaptées aux spécificités du développement logiciel

J'aime bien insister sur le fait que mes méthodes de travail, je ne les ai pas inventées. Puisqu'on vous dit que ce sont des experts !

J'enchaîne ensuite en évoquant scrum, les concepts de backlog, de priorité des tâches, d'itérations etc. J'essaye de rester synthétique et d'éviter de remplir une grille de buzzword bingo en trois phrases. Le but n'étant pas de discourir sur les bienfaits de l'agile, mais d'expliquer de manière concrète et pédagogique comment pourrait se dérouler notre collaboration au quotidien.

Important, j'explique également que toute la phase préalable de rédaction de spécifications est abandonnée, ce qui réduit les coûts du projet.

Je continue en montrant que le concept de priorisation des tâches garantit au client le meilleur retour sur investissement par rapport à son budget, et ce à tout moment. Les cycles de livraison trés courts permettent une meilleure visibilité sur l'avancement du projet. Et le fait de pouvoir stopper le travail après chaque itération offre un contrôle maximum au niveau du budget.

Enfin, je sors de ma manche mon atout maître, mon argument qui tue. La première livraison, ce n'est pas dans un an. Ce n'est pas dans six mois. C'est dans DEUX SEMAINES. Dans deux semaines, je vous livre votre première itération fonctionnelle !

Je peux vous garantir que vos propects, qui ont peut-être été habitués à travailler avec des prestataires qui livraient une v1 après 9 mois de dev, quand vous leur expliquez qu'ils pourront tester un truc en deux semaines, ils vous prennent pour le messie.

Calmos amigos ! Expliquer ses responsabilités à votre futur client

Vous avez redonné le moral à votre prospect. C'est bien. Il faut maintenant lui faire comprendre que l'agile, ce n'est pas de la magie. Une collaboration agile implique un partage des responsabilités entre le client et le prestataire, et une implication forte de la part de votre prospect. Il faut le lui faire comprendre dés maintenant.

D'abord, j'explique à mon prospect que j'exige de lui une certaine disponibilité, pour ne pas dire implication (En fait, on peut dire implication). Lui aussi, il va devoir bosser, trier le backlog, écrire les stories, répondre à mes questions, participer aux réunions, tester les releases, etc. Toutes ces tâches demandent du temps, et il faut qu'il en soit conscient. Sans jardinier, pas de jardin.

Cela signifie que nous allons partager la responsabilité de la réussite du projet. Moi, prestataire, ne suis pas en mesure de m'engager seul sur la réussite d'un projet qui ne dépend pas de moi.

C'est un moment clé de l'entretien, c'est à ce moment là que vous allez avoir un aperçu de la maturité de votre interlocuteur.

Mais b**el, combien ça coûte !

À ce moment de l'entretien, votre interlocuteur devrait être un peu confus. Car même si vous avez été convainquant, vous n'avez pas répondu à sa question principale : combien ça coûte ?! C'est à ce moment là que surviennent en général les objections.

Tout ça, c'est bien beau, mais j'ai quand même besoin de savoir combien ça coûte, non ?

C'est une interrogation qui est sommes toutes légitime. Et d'ailleurs, je pense qu'il faut l'exprimer tout haut.

Je vous comprends tout à fait. Ce sont vos sous, il est normal que vouliez avoir une idée de combien va coûter ce projet. C'est une interrogation qui est parfaitement légitime.

J'engage alors mon prospect à faire une expérience (tout le crédit du paragraphe suivant revient au sieur Stéphane Langlois, merci à lui) : je lui conseille d'envoyer son cahier des charges à dix SSII, et lui explique qu'il recevra alors dix devis, tous chiffrés au centime près, mais avec des différences pouvant aller jusqu'à plusieurs milliers d'euros. D'où viennent ces différences ?

Elles ont plusieurs explications.

D'abord, comme nous l'avons expliqué plus haut, il est impossible de décrire sur papier un logiciel avec un niveau de détail parfait. Par conséquent, il restera toujours une part d'interprétation dans la lecture du cahier des charges. Et cette différence d'interprétation, que vous ne pouvez pas prévoir avant la livraison effective du projet, aura nécessairement un impact sur l'estimation du projet.

Entre ce que vous avez dans la tête, et ce qui est dans la tête de la personne qui chiffre votre projet, il y a parfois une différence énorme.

Il faut ensuite comprendre qu'écrire un logiciel n'est pas une science exacte. Un développeur dispose toujours d'une certaine flexibilité dans l'implémentation d'un besoin. Peut-être que votre demande vous parait limpide, mais est-ce le cas du développeur qui a réalisé 15 projets similaires, chacun avec ses spécificités ?

Par conséquent, pour établir un devis qui correspondrait exactement à votre besoin, à ce que vous avez dans la tête, il faudrait que je sois capable de lire dans vos pensées. Pour ma part, j'estime que quand on prétend faire de la voyance, c'est de la pure malhonnêteté intellectuelle.

Ce que je vais chercher à faire, en revanche, c'est vous donner tous les outils possibles pour gérer au mieux votre projet et votre budget.

À chaque instant, vous saurez précisément ce qui a été développé et ce qui reste à faire, et quel budget a été consommé. Ces indicateurs vont nous permettre de savoir quand et comment jouer sur les différents paramètres expliqués plus tôt, pour atteindre vos objectifs avec les contraintes qui sont les votres.

L'avantage, c'est qu'on minimise les risques. En cas de problème, ou d'imprévu, nous allons nous en rendre compte tout de suite, et vous pourrez réagir au plus tôt, minimisant ainsi le gaspillage de budget.

Pour résumer, vous ne pouvez pas savoir à l'avance combien va coûter votre projet. C'est un fait. Vous avez deux possibilités. Soit vous essayez de vous rassurer en travaillant avec un prestataire qui prétend le contraire, mais vous allez au devant de sérieuses déconvenues. Soit vous en prenez votre parti en travaillant avec une méthode créée expressément pour tenir compte de ces contraintes.

Répondre aux objections

Cette histoire de budget est plus ou moins difficile à avaler en fonction des personnes et de leur maturité. Mais d'autres objections peuvent surgir.

Des fondations solides pour une relation saine

Le premier entretien avec votre futur client est primordial. Il faut bien évidemment vous vendre en lui prouvant que vous êtes le meilleur. Vous devez également lui expliquer les rôles et responsablités de chaque acteur du projet. Enfin, profitez en pour tester son niveau de maturité, ce qui vous évitera de travailler avec des gros cons.

En un mot, dés les premières minutes, posez des briques solides pour bâtir une relation saine et productive.