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