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 ce qui est sûr
c'est qu'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 pouvoir raccrocher.
(rires)
Ça vous donne une idée du niveau où j'en suis rendu
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 a un impact assez fort sur 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
c'est à dire 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 un petit peu
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 travaiiler, 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 vous avez comme ça quelqu'un qui veut un devis
qui veut 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 votre compétence 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 de gestion de projet traditionnelles
sont obsolètes
Prrrrr
Alors 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 d'abord
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ée sur un échange permanent,
sur un aller-retour permanent entre le client et le prestataire est vouée à 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 petit 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 de projet 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
Déjà 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 gagné
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 utiles pour vous
et donc qu'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 ont 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
c'est lui qui va être responsable de trier le backlog,
de définir les fonctionnalités, etc.
C'est lui qui va devoir être responsable de participer
aux différentes réunions, de répondre à mes questions, etc.
Donc 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'ils le prévoient dès maintenant
il faut qu'ils prévoient 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 que
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'envoyez à une dizaine de SSII
vous demandez des devis
Vous allez voir que vous allez recevoir dix devis, tous chiffrés au centime prêt
mais avec des différences de 1000,
5000, 10 000 euros
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, entre 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'efforts
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 corresponde 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'avenir
et de prédire l'évolution de vos besoin
à 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 comme ça
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
et 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 imprévu
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 vraiment 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.
Donc là 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 petit 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 vraie 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