# Vendre des prestations agiles - Thibault Jouannic

Merci, merci beaucoup.

Donc les plus sagaces d'entre vous l'auront deviné, je m'appelle Thibault et cette conférence s'intitule comment vendre des prestations agiles.

Alors comme j'ai que vingt minutes je vais rentrer assez rapidement dans le vif du sujet.

Et peut-être avant je vais déjà vous expliquer de quoi je ne vais pas parler.

Déjà je ne vais pas parler d'agile, enfin je vais pas expliquer ce que c'est en fait, ce n'est pas le but de la conférence.

Si vous n'êtes pas forcément à l'aise avec les concepts de backlog, itération, etc, bon ben vous serez obligés de copier sur vos petits camarades.

Je vais pas non plus parler de contractualisation parce je n'ai aucune compétence dans le domaine ;)

Par contre plutôt que de vous expliquer de quoi je vais parler, je vais l'illustrer avec une situation

Alors c'est une situation qui est tirée de la vie réelle et qui est pas quotidienne mais presque pour moi parce que je suis freelance, développeur indépendant et assez fréquemment mon téléphone sonne sur mon bureau et au bout du fil c'est un client potentiel qui cherche un prestataire pour un projet.

Alors cette personne au bout du fil, typiquement elle ne sait pas forcément très précisément ce qu'elle veut

Son besoin n'est pas forcément précisément défini, par contre  elle veut savoir très précisément combien ça coûte et combien de temps ça va prendre.

Ça c'est du pur vécu hein.

Alors c'est la situation de départ et pourquoi j'ai choisi de parler de ça en fait c'est parce que j'ai une confession à vous faire.

C'est la minute psychanalyse de Sud Web : en fait je suis terrifié par les téléphones.

Je sais pas si parmi vous y'en a qui ont peur des araignées, des serpents, des trucs un peu velu, visqueux tout ça

Moi c'est pareil mais avec les téléphones

C'est à dire j'suis mauvais au téléphone, je bégaye, je bafouille, je raconte n'importe quoi, je suis pas forcément très à l'aise.

Pour vous donner un exemple, pas plus tard que la semaine dernière un téléprospecteur de … je crois que c'était SFR … m'a contacté pour me vendre un forfait mobile ou je sais pas… 

Et au bout de cinq minutes c'est lui qui a trouvé une excuse bidon pour raccrocher.

Ça vous donne une idée du niveau où j'en suis rendu (rires)

Bon quand on est indépendant, c'est handicapant c'est vrai, parce que faut faire bouillir la marmite et c'est d'autant plus handicapant que moi je travaille au quotidien avec les méthodes agiles, j'essaie de m'en rapprocher le plus possible.

Et quand on fait de l'agile ça va avoir un impact assez fort avec la relation qu'on va avoir avec son client au quotidien.

Alors qu'est-ce que j'entends par là ?  Bon ça c'est pareil on pourrait en discuter ce serait une conférence à part entière mais pour ma part j'estime que quand on fait de l'agile, on vend pas du forfait.

La manière dont je travaille, c'est le client qui a la main sur le périmètre fonctionnel, donc moi je ne m'engage pas sur un budget au départ, donc je vends de la régie.

C'est pareil, j'estime en fait que j'attends de la part de mon client une certaine implication.

J'attends une implication de sa part parce qu'il va devoir participer à différentes réunions, etc. 

Ça, ça va lui prendre du temps et on va partager en fait la responsabilité de la réussite du projet.

Et tout ça en fait il faut l'expliquer dès le premier entretien téléphonique.

Alors quand vous avez quelqu'un qui vous appelle et qui veut un devis, pour lui expliquer dès le début qu'en fait vous travaillez pas comme ça ?

Moi, mon expérience, c'est que la méthode triviale, la méthode naïve, c'est à dire l'improvisation ne fonctionne pas.

Ça ne fonctionne pas.

Donc quand j'ai compris que si je voulais continuer à manger il allait falloir que j'améliore ma compétence de vendeur j'ai pris un peu le taureau par les cornes et je me suis dit ben je vais essayer de bâtir de peaufiner un argumentaire pour promouvoir mes méthodes de travail.

Et donc c'est ce travail là que je vais vous présenter maintenant.

Quand on avait comme ça quelqu'un qui veut un devis, un engagement sur un budget, c'est quoi la première étape ?

Moi j'aime bien commencer par le dégoûter. Faut lui faire peur c'est vrai. C'est l'occasion de prendre la main dans l'entretien, de montrer un peu vos compétences et de balancer des phrases chocs avec des bons mots clefs qui vont bien.

Par exemple je dis : "Mais Madame, Monsieur un devis ? On travaille plus comme ça dans l'industrie, moi je travaille plus comme ça. Les méthodes traditionnelles de gestion de projet sont obsolètes. Prrrr 

Pourquoi je vous dis ça ?
Parce qu'en fait les méthodes de gestion de projet traditionnelles, j'entends par là tout ce qui est cahier des charges, spécifications, devis, forfait, contrat, etc. sont globalement inspirées du BTP.

Dans le BTP on fait un plan et après on construit.

Le problème c'est que le BTP et le logiciel c'est pas pareil. 
Dans le BTP c'est assez facile de définir ce qu'on veut. C'est à dire qu'on veut un mur : on trace un trait sur un plan et on sait qu'il faut faire un mur. Par contre modifier l'existant c'est vachement plus dur. 

Vous pouvez aller voir votre architecte et lui demander de modifier l'emplacement des murs porteurs alors qu'ils sont en train de mettre les tuiles … bon il va vous rire au nez.

Dans le logiciel, c'est pas pareil, c'est même l'inverse. 

Dans le logiciel quand c'est bien fait, c'est relativement facile de modifier l'existant. 

C'est à dire qu'on peut toujours rajouter une fonctionnalité, l'adapter, etc.

Par contre définir son besoin c'est vachement plus difficile. Parce que d'abord un logiciel c'est quelque chose qui est immensément complexe et puis un besoin quoi qu'on en dise c'est quelque chose qui reste assez subjectif.

Donc en fait toute méthode, toute tentative de bâtir un logiciel, toute méthode de gestion de projet qui n'est pas basé sur un échange permanent, sur un aller-retour permanent entre le client et le prestataire est voué à l'échec.

Encore deux trois mots-clefs

En fait le résultat c'est que le pauvre gars qui vous appelle vous le prenez dans une vague vous lui cassez le moral.

Alors lui en plus il y connait rien, il est un peu pris de court, et donc là le moment est venu de présenter l'alternative.

Ce que je dis à ce moment là c'est que bon moi j'utilise des méthodes alternatives, je peux vous présenter un peu comment je travaille.

Alors ce sont des méthodes, ce n'est pas moi qui les ai inventées.

En fait, face à ces problèmes que je viens de vous décrire, des experts reconnus de l'industrie se sont réunis pour bâtir des méthodes de gestion qui sont adaptées aux spécificités du développement logiciel.

Donc là c'est un peu l'effet. Encore une fois c'est l'effet "Vu à la Télé". C'est pas moi qui l'ai inventé, c'est des experts, ils sont reconnus donc ça doit fonctionner.

Là le moment est venu de présenter un petit peu comment on travaille, c'est à dire de présenter, je sais pas si vous faites du SCRUM ou d'autres choses, d'introduire un petit peu sa méthode de travail. 

Par contre c'est important de rester synthétique, de pas trop rentrer dans les détails, on est pas là pour expliquer en détail ce qu'est l'agile, le but c'est de promouvoir encore une fois ces méthodes de travail d'une manière assez pragmatique.

J'explique comment ça fonctionne. Déjà le cahier des charges, les spécifications tout ça, on vous en fait cadeau.

On passe pas deux mois à rédiger un document qui tente de décrire exhaustivement le logiciel et qui sera obsolète dans deux mois et que de tout façon personne ne va lire.

Donc tout ça c'est du temps de gagner. Non ce qu'on fait c'est qu'on commencer par définir une liste globale et grossière de vos besoins dans un formalisme qu'on expliquera plus tard. 
et vous le triez par priorité en permanence. Et on ne va définir précisément que les fonctionnalités qui sont en haut de la pile donc celles qui sont le plus utile pour vous et donc on va développer en premier.

Et en fait on va travailler par itérations très courtes, à tout moment dans le projet vous définissez les priorités, nous on prend ce qu'il y a en haut de la pile, on le développe et on vous le livre. Et on va fonctionner comme ça avec un aller-retour.

Quand vous estimez qu'on a développé tout ce qui était essentiel pour vous, ben on arrête, on arrête de dépenser du budget pour rien, c'est pas la peine de dépenser plus de sous.

L'avantage c'est qu'avec cette méthode de travail, à tout moment vous êtes garanti d'avoir le meilleur retour sur investissement par rapport à votre budget.

Alors là c'est des arguments que j'aime assez parce qu'en même temps on explique la méthode de travail, on est un peu pragmatique puis en même temps si le mec a plutôt un profil de manager tout ça quand même retour sur investissement, tout ça ça lui parle quoi.

Alors l'argument qui tue, ça vraiment c'est du vécu. C'est

La première livraison c'est pas dans six mois, c'est pas dans deux mois, c'est dans deux semaines.

Et ça c'est vraiment l'argument, c'est à dire c'est vraiment du vécu, un client qui a l'habitude de travailler avec des prestataires qui on des délais six mois plus trois mois de retard, quand vous lui dites "première livraison dans deux semaines" mais vous êtes le messie, c'est vraiment fantastique, c'est vraiment l'argument qui tue.

Bon là on essaie d'être enthousiaste au téléphone tout ça, ce qu'on explique ça a l'air super, le gars il commence à retrouver le sourire mais il faut lui faire comprendre dès maintenant que l'agile c'est pas de la magie quoi. 

Le projet il va pas sortir du chapeau parce qu'on a mis l'étiquette agile dessus. 

Il faut expliquer dès maintenant au futur client quelles vont être ses responsabilités et son travail au cours du projet.

Donc ce que je commence à expliquer à mon futur client, c'est qui lui aussi il va devoir bosser, je vais pas être le seul à travailler sur le projet.

Ça veut dire que c'est lui qui va devoir être responsable de trier le backlog, de définir les fonctionnalités, etc.

C'est lui qui va devoir être responsable d'être présent aux différentes réunions, de répondre à mes questions, etc.

Lui aussi il va bosser, il va bosser et ça ça va demander du temps. 

Donc il faut expliquer à vos futurs clients que l'agile ça prend du temps et il faut qu'il le prévoit dès maintenant, il faut qu'il prévoit quelqu'un qui va s'occuper du projet et il faut prévoir quelques heures par jour pour être vraiment à la disposition du projet.

Et tout ça ça se traduit par quoi, ça se traduit par en fait ce qu'il faut expliquer c'est qu'en fait on partage les responsabilités de la réussite du projet.

C'est à dire moi prestataire, je ne m'engage pas seul sur la réussite du projet puisque cette réussite ne dépend pas que de moi, donc on partage les responsabilités, faut que chacun fasse son travail sinon ça peut pas fonctionner.

Et ça dépend un petit peu de la maturité de la personne qu'il y a en face mais parfois, c'est un argument qui est assez dur à avaler, il faut bien l'avouer

A ce moment là de l'entretien, j'aime bien faire un point.

Parce que bon au téléphone, avec un peu d'entraînement, on arrive à être percutant, convaincant, on est professionnel mais il faut se mettre à la place de votre interlocuteur, qui a cette petit voix dans sa tête qui dit :

Hey minute papillon, moi j'appelais à la base c'est pour avoir un devis et là tu essayes de m'embrouiller mais je sais toujours pas combien ça coûte.

C'est vrai que l'argument, quelqu'un qui gère un projet il a besoin de visibilité sur le budget de son projet, c'est normal.

Et d'ailleurs moi je pense qu'il faut le verbaliser et moi je le dit "Madame, Monsieur, je comprends vos attentes, vos réticences, vis à vis de cet aspect du projet et c'est tout à fait normal. Je vous comprends.

Laissez moi vous dire une chose …

Je vous engage à faire l'expérience suivante : vous prenez votre cahier des charges, vous l'envoyer à une dizaine de SSII, vous demandez des devis.

Vous allez voir que vous allez recevoir dix devis différents, tous chiffrés au centime prêt, mais avec des différences de 1000, 5000, 10 000 EUR. 

D'où viennent ces différences ? C'est assez facile à expliquer finalement. 

D'abord il faut bien se rendre compte que la lecture d'un cahier des charges, c'est un exercice d'interprétation.

C'est à dire qu'entre votre besoin, ce que vous écrivez dans le cahier des charges, entre ce que votre prestataire va lire, ce qu'il va comprendre et  ce qu'il va réaliser, des fois il y a un monde.

Et forcément cette différence dans l'interprétation va avoir un impact sur l'estimation du coût du projet. D'où la différence dans les devis.

Alors un autre aspect c'est que 

Faut bien se rendre compte que dans le développement logiciel, on a une certaine flexibilité dans les développements.

C'est à dire qu'on peut mettre plus ou moins d'effort dans le développement de tel ou telle fonctionnalité.

Peut-être que pour vous qui n'êtes pas du métier vous décrivez votre besoin ça vous parait limpide mais pour un prestataire dont c'est le métier peut-être que lui il va avoir plusieurs façons d'envisager les choses. 

Peut-être que par rapport à votre besoin, votre prestataire va pouvoir mettre une place une solution très simple, intégrer quelque chose qui existe, faire quelque chose de basique mais qui fonctionne qui va lui prendre deux heures ou alors peut-être qu'il va pouvoir envisager une solution beaucoup plus complexe, beaucoup plus avancée, qui va demander des développements spécifiques et qui va prendre 5 jours ou 10 jours à développer.

Deux heures, cinq jours, c'est pas la même chose. 

Et pourtant il se peut que ces deux fonctionnalités correspondent texto à ce qui est décrit dans le cahier des charges.

Donc vous vous rendez bien compte que si moi si je voulais faire un devis qui correspondent très précisément à votre besoin, il faudrait que je sois capable de lire dans vos pensées, il faudrait aussi que je sois capable de prédire l'évolution de vos besoins à moyen et à long terme.

Moi j'estime que quand on prétend faire de la voyance, c'est de la malhonnêteté intellectuelle.

Moi j'ai une conscience professionnelle, je m'y refuse.

Pour autant, je comprends votre besoin de visibilité vis à vis de votre budget, c'est normal on ne travaille pas en balançant de l'argent sans savoir où ça va, je comprends.

C'est pour ça que les méthodes de travail que je mets en place vous donnent tous les outils pour gérer au mieux votre projet et votre budget.

C'est à dire qu'en permanence, vous savez très précisément ce qui a été développé, ce qui a été consommé au niveau du budget et ce qu'il reste à faire.

En fonction de ces indicateurs, au quotidien nous allons jouer sur les différents paramètres qui sont à notre disposition pour atteindre vos objectifs.

Donc l'avantage de cette méthode de travail, c'est qu'on minimise l'incertitude, on minimise les risques.

Au cours du projet, si il y a un problème, un problème technique, une difficulté quelconque, un besoin qui a été mal exprimé ou vous changez d'avis, ou un besoin qui a été mal compris, on s'en rend compte tout de suite, on n'attend pas six mois avant de s'en rendre compte avec les effets désastreux que l'on connait.

Au niveau du budget, il peut arriver dans l'entretien que la conversation dure un petit peu mais comme je vais être à court de temps, on va devoir passer mais en gros le gros des arguments est là, après il s'agit de convaincre de rassurer la personne qu'il y a en face.

Quand même à ce niveau là de l'entretien il y a d'autres remarques qui peuvent arriver aussi assez régulièrement mais mon expérience c'est qu'en général il n'y a rien de très compliqué à argumenter, ce sont des remarques qui sont assez faciles à balayer finalement.

Par exemple il y a l'argument du coût global.

Quelqu'un qui vous dit : "C'est pas mal votre truc, mais quand même c'est trop cher".

Là j'ai un argument , j'ai une réponse toute faite  qui marche assez bien

Je dis Madame, Monsieur,

"Si vous payez des cacahouètes, en face vous aurez des singes."

Alors (rires) pas mal hein ?

C'est pas très difficile à argument parce que finalement 

C'est vraiment les cas que j'ai rencontré.

Les gens finalement sont assez ouverts au fait que quand on veut de la qualité, de toute façon il faut mettre le prix.

Donc c'est pas une remarque qui est très difficile à argumenter.

Une autre remarque qui revient souvent c'est par exemple  "J'ai pas le temps"

Quelqu'un qui vous dit, ben c'est super votre méthode tout ça mais moi trois heures par jour tout ça, mais moi j'ai pas le temps, j'suis tout le temps en déplacement, etc.

Là aussi c'est pareil j'ai une réponse tout faite, je leur dit "Écoutez Soit vous déléguez cette responsabilité à quelqu'un qui va avoir le temps et qui aura effectivement le pouvoir de prendre les décisions au niveau du projet, soit vous trouvez un autre prestataire.

Parce que si vous même n'êtes pas prêt à mettre en oeuvre ce qu'il faut pour que votre projet réussisse, je vois pas pourquoi moi je le ferais.

Donc OK je comprends vos problèmes mais je ne travaille pas comme ça, vous trouvez quelqu'un d'autre.

Voilà, alors on en vraiment à la fin de l'entretien, y'a d'autres remarques pareil qui viennent assez régulièrement mais comme je l'ai dit, il n'y a rien de très compliqué donc je passe et on pourra en discuter éventuellement un petit peu plus tard.

Donc quand même le résultat de cet entretien pour conclure un peu.

Qu'est-ce qui se passe lorsqu'on déroule ce genre d'entretien et d'argumentaire ?

Ben finalement votre interlocuteur, vous l'avez convaincu de votre compétence. 

Vous l'avez convaincu de la pertinence de votre méthode de travail. 

Vous avez commencé à le faire adhérer aux principes et aux valeurs des méthodes agiles. 

Et vous avez posé les premières pierres d'une relation de confiance avec votre futur client.

Ça veut dire quoi, ça veut dire que dès le premier entretien, dès le premier contact, vous avez posé des fondations saines d'un projet réussi. 

Voilà, j'ai fini merci.