195 lines
12 KiB
Markdown
195 lines
12 KiB
Markdown
|
# Le client ne sait pas ce qu'il veut. Sauf si... vous communiquez.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
## Le client doit vous fournir sa Vision
|
|||
|
J'ai souvent été confronté, en tant que développeur, et sur des projets de toutes tailles
|
|||
|
(très grosses applications financières, petits intranet, sites web...) à cette situation : des
|
|||
|
clients étaient incapables de me décrire ce qu'ils voulaient que je réalise pour eux.
|
|||
|
|
|||
|
A chaque fois, dans ce cas, il m'a fallu moi-même interpréter leurs souhaits, à partir de captures d'écrans de
|
|||
|
sites concurrents, de discussions interminables... Et pour un résultat pas toujours très heureux.
|
|||
|
|
|||
|
A quoi la faute ? Au client ? Pas forcément : après tout, ce n'est pas parce qu'on est patron d'entreprise
|
|||
|
ou que l'on a un besoin bien précis que l'on sait comment résoudre ce besoin, ou l'exprimer clairement.
|
|||
|
|
|||
|
Est-ce la faute du développeur, qui semble incapable de comprendre ce qu'on lui demande ? Personnellement
|
|||
|
j'ai toujours essayé de faire de mon mieux, même si je suis conscient de ne pas avoir toujours été à la hauteur.
|
|||
|
Et je crois que la plupart des développeurs font de même.
|
|||
|
|
|||
|
Alors ? Et si personne n'était en tort ? En réalité, la plupart des projets informatiques échouent car
|
|||
|
ils ne sont pas motivés par une Vision. Certes on veut délivrer un super site web, avec plein de fonctionnalités
|
|||
|
qui vont tuer la concurrence, on veut faire mieux que son voisin... Mais on oublie l'essentiel : un projet doit
|
|||
|
voir un but.
|
|||
|
|
|||
|
Quel est ce but ? Peu importe : changer le monde, rendre service à une catégorie de personne, se faire de
|
|||
|
l'argent... Tout est bon à prendre, du moment que cet objectif, cette Vision, reste le seul et unique maître
|
|||
|
du projet.
|
|||
|
|
|||
|
On le comprend bien alors : ce n'est pas parce qu'un concurrent propose un service qu'il faut le recopier.
|
|||
|
Non, on propose un nouveau service parce qu'il sert la Vision du projet.
|
|||
|
|
|||
|
Vous l'aurez compris : la Vision est essentielle, et c'est justement le rôle de votre client de la fournir.
|
|||
|
Sans Vision, le projet est condamné à être un échec, ou au mieux une semi-réussite.
|
|||
|
|
|||
|
Votre client doit impérativement vous fournir cette Vision. S'il en est incapable, insistez pour qu'il soit
|
|||
|
aidé : faites lui lire le premier tome de ce livre, faites le coacher par une société spécialisée...
|
|||
|
Sans cela, vous ne pourrez pas travailler efficacement avec lui et ne prendrez pas autant de plaisir
|
|||
|
que vous le méritez dans votre travail.
|
|||
|
|
|||
|
> La plupart des projets informatiques échouent car ils ne sont pas motivés par une Vision.
|
|||
|
|
|||
|
|
|||
|
## Votre Client ne parle pas la même langue que vous
|
|||
|
|
|||
|
Vous l'avez vécu : votre client et vous ne vous comprenez pas toujours. Pour vous, un "réseau social"
|
|||
|
c'est une plate-forme communautaire, avec des amis, relations, des groupes, des flux de messages...
|
|||
|
Bref c'est Facebook.
|
|||
|
|
|||
|
Pour votre client, un "réseau social" c'est (par exemple) un espace où des employés font des demandes
|
|||
|
de documents, découvrent les actualités de l'entreprise, échangent des informations sur les commandes...
|
|||
|
Bref, c'est un intranet.
|
|||
|
|
|||
|
Attendez... Mais comment donc voulez-vous réussir à satisfaire votre client si vous n'employez
|
|||
|
pas le même vocabulaire sur des choses si fondamentales ?
|
|||
|
|
|||
|
Ajoutez à cela que votre client va toujours avoir tendance à faire deux choses :
|
|||
|
|
|||
|
+ employer des acronymes, sigles et autre vocabulaire fonctionnel
|
|||
|
+ employer des termes techniques ("base de données", "formulaire", "sauvegarder") sans savoir précisément ce qu'ils signifient
|
|||
|
|
|||
|
La première chose à faire lorsque vous démarrez un projet avec un client, c'est donc de vous
|
|||
|
créer un vocabulaire commun. Il va falloir inventer une nouvelle langue, qui ne laisse plus la
|
|||
|
place aux ambiguïtés, où chaque mot n'a qu'une seule signification.
|
|||
|
|
|||
|
J'ai une mauvaise nouvelle pour vous : ce nouveau vocabulaire, c'est à vous de l'apprendre, pas
|
|||
|
à votre client. Cela vous évitera des débats interminables et vous permettra de mieux comprendre
|
|||
|
le besoin du Client.
|
|||
|
|
|||
|
Si votre client, lorsqu'il dit "bus", parle en réalité d'un véhicule avec des ailes et que vous
|
|||
|
retrouvez dans un aéroport, ne lui dites pas qu'il a tort. Non, désormais, lorsque vous parlerez
|
|||
|
avec lui, vous emploierez le mot "bus" pour désigner ce que LUI entend par "bus".
|
|||
|
|
|||
|
Bien entendu, ce vocabulaire commun, vous devez le constituer ensemble. Si votre client parle de
|
|||
|
"bus", et que c'est important dans le projet, discutez-en ensemble, et mettez noir sur blanc une
|
|||
|
définition simple de ce qu'il entend par là.
|
|||
|
|
|||
|
Faites de même pour chaque expression que votre client emploie régulièrement. De cette manière vous
|
|||
|
n'aurez plus aucune ambiguïté dans votre quotidien.
|
|||
|
|
|||
|
C'est le postulat de base du Développement piloté par le Comportement : vous devez élaborer avec votre
|
|||
|
client une Langue Commune.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
## Engagez-vous à livrer régulièrement
|
|||
|
|
|||
|
Quoi de plus frustrant, après de longues semaines de travail acharné, d'entendre un si triste
|
|||
|
"Mais ce n'est pas du tout ce que j'avais demandé" ?
|
|||
|
|
|||
|
Et même un simple "ne pourrait-on pas juste changer..." peut s'avérer totalement démoralisant,
|
|||
|
compte-tenu de tout ce qu'il faudra refaire techniquement pour gérer cette demande, et sachant
|
|||
|
surtout combien cela aurait été simple si seulement on vous avait prévenu quelques semaines à l'avance.
|
|||
|
|
|||
|
Comment éviter d'être touché par ce malheureux constat d'échec, ou de semi-réussite ?
|
|||
|
|
|||
|
La réponse est en théorie simple : il suffit de livrer son travail très régulièrement au client, de sorte qu'il
|
|||
|
puisse rapidement s'apercevoir le plus tôt possible que le projet n'est pas parti dans la direction
|
|||
|
à laquelle il s'attendait.
|
|||
|
|
|||
|
Cette démarche est celle des méthodes agiles, particulièrement de Scrum. Le principe est le suivant :
|
|||
|
plutôt que de livrer votre projet une bonne fois pour toute (lorsque le travail est terminé), vous vous engagez à livrer des
|
|||
|
bouts de fonctionnalités très régulièrement (une fois toutes les deux semaines par exemple).
|
|||
|
|
|||
|
C'est ce qu'on appelle le développement par itérations, par opposition au cycle en V. Vous développez
|
|||
|
grossièrement une fonctionnalité, puis vous l'affinez, l'affinez encore si besoin, jusqu'à arriver au
|
|||
|
résultat final. De cette manière le client peut réorienter le projet à chaque itération sans que n'en
|
|||
|
soyez affecté négativement.
|
|||
|
|
|||
|
Imaginez, par exemple, que votre travail consiste à peindre le célèbre tableau La Joconde. Avec la
|
|||
|
méthodologie classique, votre devriez travailler de manière à finir chaque fonctionnalité de bout
|
|||
|
en bout, puis, une fois qu'elle est entièrement terminée, passer à la suivante.
|
|||
|
|
|||
|
|
|||
|
![ Méthodologie classique : le travail et découpé en lots, chaque lot est totalement réalisé avant de passer à la suite. Le changement fonctionnel en cours de route est difficile. ]
|
|||
|
(mona-lisa-incremential.jpg)
|
|||
|
|
|||
|
Avec les méthodes agiles la démarche est inverse : vous esquissez d'abord les traits de ce que vous avez
|
|||
|
à développer, afin de permettre au client d'avoir un aperçu du produit final et de bénéficier rapidement
|
|||
|
du feedback des utilisateurs, puis vous affinez, selon la priorité de chaque fonctionnalité : une
|
|||
|
fonctionnalité plus complète par là, un autre lors de l'itération suivante...
|
|||
|
|
|||
|
![Méthodologie agile : le tableau s'affine petit à petit. Le changement fonctionnel est facile, même en cours de route ]
|
|||
|
(mona-lisa-iterative.jpg)
|
|||
|
|
|||
|
|
|||
|
Bien entendu, cela ne va pas sans un changement des méthodologies de travail : il va falloir découper
|
|||
|
les fonctionnalités pour faire en sorte qu'elles puissent être développées rapidement, il faut optimiser
|
|||
|
les recettes (pourquoi ne pas en profiter pour utiliser des tests automatisés, comme des tests
|
|||
|
unitaires ?)...
|
|||
|
|
|||
|
Mais, croyez-moi, ces efforts valent la peine : non seulement les relations avec votre client / patron
|
|||
|
seront de plus en plus saines (le projet devient totalement transparent pour tous), mais en plus vous
|
|||
|
arriverez vite à livrer du code fonctionnel régulièrement.
|
|||
|
|
|||
|
Et ô combien cela fait plaisir de voir que l'on avance ! Cela vous permettra même de gérer plus
|
|||
|
facilement les demandes de changements fonctionnels : il est toujours plus facile de revenir sur
|
|||
|
deux semaines de travail que sur trois mois, et c'est bien moins démoralisant.
|
|||
|
|
|||
|
Je vous conseille même de faire quelque chose qui peut sembler assez étrange : à chaque fois que vous
|
|||
|
livrerez un lot fonctionnel, n'hésitez pas à présenter, pendant une heure ou deux, le fruit de votre
|
|||
|
travail à votre client. Oui, comme un commercial ! Prenez même un vidéo-projecteur.
|
|||
|
|
|||
|
Calez systématiquement une réunion à chaque fin d'itération, et prenez la parole : montrez ce que
|
|||
|
vous avez fait, et soyez-en fier ! Après tout, si vous avez donné le meilleur de vous même, il est
|
|||
|
légitime que tout le monde sache de quoi il était question.
|
|||
|
|
|||
|
> Prenez la parole ! N'entendez plus jamais le fameux "Ce n'est pas ce que j'avais demandé".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
## Adoptez le point de vue de l'utilisateur final
|
|||
|
|
|||
|
Chaque projet informatique, qu'il s'agisse d'un site web, d'un intranet, d'une application... tout
|
|||
|
projet dessert un objectif : rendre service à quelqu'un. Il faut vous mettre dans la peau de cette personne.
|
|||
|
|
|||
|
Lorsque vous développez une boutique eCommerce, le service est rendu à un potentiel acheteur; lorsque
|
|||
|
vous développez un intranet, ce sont les employés qui utiliseront l'intranet qui sont les bénéficiaires
|
|||
|
du service.
|
|||
|
|
|||
|
Dans les deux cas, vous aurez besoin de comprendre comment le Produit va être utilisé. Finalement, à quoi
|
|||
|
sert cette fonctionnalité ? Pourquoi est-elle utile ? Comment va t-elle rendre service ? Va t-elle faciliter
|
|||
|
la vie de l'utilisateur ? Va t-elle lui permettre de réaliser quelque chose de nouveau ? Lui faire gagner
|
|||
|
du temps ? Bref, quel est le bénéfice métier de la fonctionnalité que je vais développer ?
|
|||
|
|
|||
|
Pourquoi se poser ces questions ? Tout simplement pour prendre plus de plaisir dans votre travail, et pour
|
|||
|
être plus efficace. Tant que ça ? Oui oui...
|
|||
|
|
|||
|
Après tout, si vous connaissez les personnes qui vont utiliser ce que vous êtes en train de développer, vous
|
|||
|
pouvez discuter avec elles, adopter leur vocabulaire, et donc profiter directement de leur feedback. Petit à
|
|||
|
petit, ce feedback sera de plus en plus positif ; ce sera alors de plus en plus agréable de voir que les gens
|
|||
|
sont contents de ce que vous leurs offrez.
|
|||
|
|
|||
|
Cela vous permettra aussi de quitter à l'occasion la casquette de développeur pour, pourquoi pas, proposer
|
|||
|
des améliorations, discuter de l'orientation du projet... Si vous savez comment va être utilisé le Produit,
|
|||
|
qu'est-ce qui vous empêche d'essayer de l'améliorer ?
|
|||
|
|
|||
|
Changer de casquette peut parfois être difficile. Vous pouvez très bien travailler sur des projets dont
|
|||
|
vous n'avez rien à faire ; c'est triste, mais ça arrive fréquemment. Il arrive de devoir travailler sur
|
|||
|
un projet pour des besoins alimentaires. C'est légitime. Mais autant faire en sorte que même ces projets,
|
|||
|
alimentaires, vous apportent de la satisfaction humaine. Adopter la vision de l'utilisateur final vous
|
|||
|
permettra toujours d'échanger : échanger avec votre client, les utilisateurs finaux, vos collègues...
|
|||
|
|
|||
|
Il y a quelques temps, j'ai lancé un sondage auprès des développeurs de la société que j'ai accompagnée.
|
|||
|
Une des questions était à peu près la suivante : "Prenez-vous plaisir dans votre travail?".
|
|||
|
Près d'un quart des réponses étaient négatives. Quel dommage !
|
|||
|
|
|||
|
N'oubliez pas que vous travaillez dans un monde d'humains : plus vous interagirez avec eux, plus vous
|
|||
|
fournirez un travail qui leur procurera satisfaction, plus vous même éprouverez du plaisir à travailler.
|
|||
|
Le métier de développeur offre une chance unique : il permet de prendre plaisir en travaillant ; autant
|
|||
|
en prendre le maximum !
|
|||
|
|
|||
|
> Changez de casquette pour prendre le maximum de plaisir dans votre métier de développeur.
|