Comment vendre des prestations agiles ? Thlbault Jouannic

L’agile, c’est bien. Mais avant d’en faire, il faut en vendre.

De plus en plus de professionnels du développement logiciel sont convaincus du bien fondé des méthodes agiles, qui proposent des réponses pertinentes aux problèmes posés par les méthodes de gestion de projet « traditionnelles ».

En revanche, l’agilité reste inconnue auprès de nombreux acheteurs de prestations de développement, tout simplement parce qu’ils ne sont pas du métier.

Travailler avec les méthodes agiles nécessite un cadre commercial approprié qui a ses spécificités, et qui peut dérouter voire rebuter des acheteurs habitués au classique « appel d’offre / cahier des charges / devis / specs / deadline ».

Quels arguments présenter, et surtout à quelles objections s’attendre lors d’une prospection commerciale en vue de vendre un cadre de travail agile ?

Transcript de la vidéo : https://raw.github.com/DirtyF/Transcripts-Sud-Web-2012/master/Vendre%20des%20prestations%20agiles%20-%20Thibault%20Jouannic.md

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