http://www.miximum.fr/wp-content/uploads/2012/12/handshakes_in_afghanistan-300x200.jpg

L'industrie du développement logiciel adopte de plus en plus massivement les méthodes agiles, avec raison. Et pour cause, l'agilité apporte des solutions pertinentes aux problèmes posés par la gestion de projet old school.

Il va sans doute devenir de plus en plus facile de convaincre votre patron de lorgner du côté des méthodes agiles. Par contre, du côté des clients, c'est une autre paire de manches. En tant que développeur web freelance (Oui, je travaille mon seo), j'ai souvent l'occasion d'être en contact avec des clients potentiels dont le domaine d'activité n'a rien à voir avec le développement. Par conséquent, l'agilité est un concept complètement nouveau pour eux.

Il y a quelques mois, j'ai eu la chance et l'honneur de participer à Sud Web 2012 en tant qu'orateur, en présentant une conférence intitulée « Comment vendre des prestations agiles ? » (La vidéo est disponible). Ce billet reprend grosso modo le contenu de cette présentation.

En tant que développeur freelance, je suis régulièrement contacté par des personnes qui ont des besoins spécifiques en matière de développement. Trés fréquemment, dés le premier coup de fil, mon interlocuteur me demande des estimations en terme de tarifs et de délais, alors que le besoin exprimé reste trés flou. « Je ne sais ce que je veux, mais je veux savoir combien ça coûte ».

Je considère pour ma part qu'un engagement forfaitaire en début de projet est complèment incompatible avec l'adaptabilité qui entre en jeu dans une prestation agile. J'ai toutefois fini par comprendre qu'à la question « Combien ça coûte ? », il faut répondre avec subtilité si l'on ne veut pas effrayer d'entrée un prospect habitué au classique « appel d'offre / cahier des charges / devis / specs ».

− Bonjour, j'aimerais savoir combien coûte mon projet ?
− Je ne sais pas Monsieur…
− Ah ? Bon ! Et bien au revoir !

Expliquer dés le premier coup de fil qu'on a des méthodes de travail différentes nécessite un peu de travail de préparation. Voici quelques éléments tirés de l'argumentaire que j'utilise.

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.

L'objection du coût global

Assez fréquemment, on me répond au téléphone que « tout ça c'est bien beau, mais ça coûte trop cher ». À cela je répond que quand on paye des cacahuettes, on fini par travailler avec des singes.

J'utilises aussi l'exemple des meubles. Quand on veut une table préfabriquée, on va chez Ikea. Mais si on souhaite un meuble sur mesure de grande qualité, il faut aller chez un artisan menuisier. Forcément, le coût n'est pas le même. Espérer la qualité du sur mesure pour le prix du préfabriqué, c'est manquer de clairvoyance et s'exposer à de facheuses pertes de temps et d'argent.

L'objection de la disponibilité

C'est une objection qui revient souvent de la part de chefs d'entreprises, par exemples, qui ont bien compris mon argumentation, mais n'ont pas la disponibilité de s'impliquer personnellement dans le projet.

Je leur répond qu'il peuvent déléguer cette responsabilité à une personne de confiance et qui aura effectivement le pouvoir de prendre des décisions. Ou alors aller voir un autre prestataire. Parce que si eux mêmes ne font pas l'effort de s'impliquer pour la réussite de leur propre projet, je ne vois pas pourquoi moi je le ferais ?

Convaincre, rassurer, persuader

Il faut bien avoir conscience que les gens qui achètent des prestations de développement informatique sont parfois sur le point d'investir des sommes folles de leurs fonds propres pour un résultat hasardeux, sans rien y connaître au domaine.

Il est normal qu'ils aient peur. L'implication émotionnelle étant trés forte, il ne faut donc pas seulement les convaincre, mais aussi les persuader. Ce genre de profil a besoin d'être rassuré. Attention, donc, à ne pas négliger l'aspect émotionnel de la discussion : votre interlocuteur reste un humain.

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.