S.Lott est un excellent informaticien, très connu dans le monde de Python. J’ai régulièrement eu affaire à lui sur stackoverflow, et il sait de quoi il parle.
Je lisais son (excellent) article qui expliquait la difficulté à faire perdre aux gens leur habitude de penser en tables.
Malheureusement, si l’auteur a parfaitement réussi à faire passer son message aux lecteurs, il a complètement échoué à communiquer avec son client.
Voyez-vous, S.Lott fait preuve ici d’un péché auquel de nombreuses personnes intelligentes s’adonnent : il a raison.
Mais le client s’en branle.
Le client se fout complètement de savoir pourquoi on ne peut pas dumper ses données MongoDB telles-quel dans un tableau Excel. Il se fout complètement d’avoir tort.
Le client a un problème, et il souhaite une solution.
Notre taf n’est pas d’avoir raison. Notre taf est de résoudre des problèmes. On ne nous paie pas pour donner des leçons de justesse.
Donc, quand un client arrive avec une demande impossible à satisfaire, la bonne réaction à avoir n’est pas de lui expliquer que ce n’est pas possible. C’est inutile, improductif, et ça n’aide personne.
La bonne réaction à avoir, c’est de redéfinir le problème :
- Quel objectif souhaite-t-il atteindre ?
- Pourquoi il a défini cette solution ?
- Quelles sont ses contraintes ?
Vous pouvez, bien entendu, dans le cadre de la démarche vers la mise en place de la bonne solution, lui expliquer pourquoi c’est la manière la plus appropriée. Pourquoi sa solution initiale ne va pas lui résoudre son problème.
Par exemple, dans le cadre de l’article, des gens demandent un dump de données hiérarchiques (document Mongo) vers un format tabulaire (tableau, Excel, csv…).
La mauvaise réponse est de dire que c’est impossible. Zéro intérêt pour les gens en face, et peut-être un léger sentiment d’humiliation. Ce n’est ni le lieu ni le moment pour l’enseignement, il y a d’autres opportunités bien plus appropriées pour ça.
Il y a pourtant une réponse très simple:
Je vois. Donnez-moi le schéma de vos données et à quoi doit ressembler la feuille Excel.
Il faut que vous sachiez qu’une base Mongo a un format de stockage très différent d’une feuille Excel, donc il est possible que ça demande des aménagements, où peut être choisir une solution différente. Il risque d’y avoir de la perte d’informations, ou pas mal de travail manuel pour dénormaliser les données. Il faut donc qu’on passe un peu de temps ensemble pour définir clairement le cadre de tout ça. J’aurais besoin de faire un tête-à-tête avec une personne qui sait à quoi va servir la feuille Excel en détail, savoir qui va la lire, dans quel but, etc. On peut prendre rendez-vous ?
Bien entendu, le client peut être votre patron. Ou votre collègue de bureau. Auquel cas le format de la conversation va changer, mais pas le sens général.
Le but est de comprendre ce que la personne veut faire.
Parfois (souvent même), en définissant clairement le problème, la personne voit que sa solution ne lui convient pas et vous demande par elle-même une alternative.
Une fois sur deux, vous n’aurez pas besoin de prendre rendez-vous, car la personne sent que quelque chose se passe et va se lancer dans la conversation : son problème simple à l’air plus compliqué que prévu. Elle va se rebeller : « c’est simple, tu me fais juste un dump de la base dans un bête fichier Excel, c’est tout ».
Les mots-clés sont « juste », « bête », « c’est tout ». On peut avoir aussi « simple », « évident », « c’est pas bien compliqué »…
Il suffit de rester calme, et avoir un comportement respectueux, mais d’expert. « J’ai déjà travaillé sur un problème similaire, je sais que je ne saurais pas résoudre ce problème correctement sans ces informations. Vous avez 2 minutes pour griffonner à quoi doit ressembler le fichier Excel sur un papier ? »
Vous la prenez à son propre jeu. Ça ne durera pas deux minutes. Car pour faire ça il faut avoir le schéma des données, les bonnes personnes en jeu, et une idée claire de l’usage final, ce qui rend de plus en plus clair, et sans argumenter, que le problème demande plus de travail que « juste », « bête » et « c’est tout ». C’est l’occasion de trouver la solution ensemble.
Bref, « laisse-moi te démontrer que c’est con ce que tu dis » n’est jamais une bonne phrase à dire, même enrobée dans des termes polis et une explication technique. Il faut rester factuel : voilà comment je comprends le problème, voilà ce qu’il me faut pour le résoudre.
En plus, le meeting de définition du problème, vous pouvez le facturer. Hey :)
Merci pour cet article qui tombe à pic.
C’est dur à encaisser le “mais arrête de me saouler avec tes questions, t’as juste à me faire ça et puis basta” J’ai l’impression que mes questions sont prises comme un moyen de nous défausser.
Un autre moment qui me laisse en plan, c’est quand j’essaye de savoir si le client ( … le patron ) préfère telle ou telle approche, telle ou telle fonctionnalité. En réponse j’obtiens un “bein t’as qu’à faire les deux”. Pour l’utilisateur, plus il y a de fonctionnalité et mieux c’est.
Indépendamment de la faisabilité du truc, j’ai toujours trouvé ça débile de la part des utilisateurs de se plaindre de ne pas avoir les bons outils pour gérer leurs données, mais dès qu’on leur développe un outil, la première fonctionnalité qu’ils demandent sont des fonctions d’import/export Excel…
Très intéressant.
Juste une coquille : au début : “faire prendre aux gens” => “faire perdre aux gens”
“prendre aux gens leur habitude de penser en tables” => perdre* plutôt que prendre
C’est vrai… et souvent on se rend également compte que son réel besoin n’a aucun rapport avec sa demande initiale.
Super article, bravo ! Je lis exactement ce que je pense, en mieux ! Ca s’appelle l’AMOA ce processus, non ? ;o)
Pour éviter ce genre de problèmes j’ai ma procédure à moi :
Le client mérite-t’il qu’on se fasse autant chier pour lui ?
1) Il paye bien et/ou très bonne volonté (ou c’est le fils du patron) => Oui, je ferme ma gueule et je bosse
2) Il paye mais il est un peu concon => Oui mais pour plus cher
3) Il paye mal, c’est un connard et en plus à chaque fois qu’il m’appelle je sais que ça va me prendre la tête : Je copie la base entière sous forme de string dans la cellule A1 et j’envoie tel quel avec la facture. Si il revient il passe en 2).
Encore mieux : ne pas utiliser toutes ces merdes de NoSQL. Le NoSQL c’est bien pour des sites de e-commerce et pour le marketing…Pour les vrais hommes, ceux de l’industrie, on n’utilise pas des technos de tapettes de marketeux (tu sais les casse-couilles qui veulent des rapports d’indicateurs qualité, des interfaces kikoo lol style Kibana, pour se branler derrière le bureau…).
Une bonne analyse Merise, un bon SGBDR à la postgresql et ton client sera heureux…sur les bases NoSQL, on gère mal les migrations et on gère mal les sécurités d’accès…On fait croire que c’est nouveaux, les tables clé/valeur ça existe depuis 45 ans si ce n’est pas plus.
Et puis sérieusement, assurer la cohérence d’un schéma dans l’applicatif, y a que des débutants pour faire cela, on a pas fait de l’algèbre relationnelle pour rien, mais bon c’est vrai, les ingénieurs de maintenant ne font plus de maths, il font du management et du marketing, on comprend mieux le merdier. La cohérence du schéma dans l’applicatif, vous comprenez pourquoi on redéveloppe tous les 6 mois les applications nodejs/nosql/javascript…
Depuis 30 ans, on normalise, quand on en a marre, on dénormalise puis on se rend compte que c’est le bordel, du coup on renormalise…c’est un processus sans fin…on a fait pareil avec la notion de client/serveur.
Et si ton client te fait vraiment chier, tu lui dis de faire du offshore avec l’Inde, tu verras au bout de 6 mois, il revient chez toi et tu le refactures 20% de plus car il faut réparer ce que ces nazes d’indiens on fait (c’est du vécu)…faut arrêter de regarder la TV, même en informatique, le marketing tue toutes les activités humaines, le marketing c’est du hacking social, on se fait hacker le cerveau.
@Anon
J’adore ton point 3), je l’ai déjà fait aussi ça, un export pourri en A1 ;)
@Anon: tout à fait. Mais parfois le connard est ton patron, et là perso je démissionne, mais beaucoup n’ont pas cette flexibilité.
Après il faut définir “se faire chier”. Car prendre le temps de comprendre le besoin du client ça fait parti du boulot. C’est même plus important que savoir coder.
C’est le genre de truc important qui devrait être évident, mais ça demande du temps.
Le taff c’est pas livrer une feature bien ficelée, mais répondre à un besoin. Le besoin, surtout accompagné d’une solution, est pas forcément clair ou réalisable à la première itération. Plutôt que d’être négatif, se butter et fermer la situation, il faut savoir rebondir et impulser vers quelque chose de mieux qui fera en sorte que tout le monde soit content.
Bonjour! Effectivement c’est très compliqué ce gerne de problème!
L’approche suggerée ressemble beaucoup au principe de CNV (communication non violente) ou d’aikido-verbale (ttps://fr.wikipedia.org/wiki/A%C3%AFkido_verbal), ce que j’approuve totalement! pour ceux qui ne connaissent pas, le but n’est pas d’aller contre le client, mais aucontraire dans sons sens et l’accompagner ves l’echec (lui mettre le net dans ses propres incoherances!).
L’avantage est double :
-On ne perd pas d’énergie a luter en face a face.
-Le client se contredit tout seul, vous l’aurait simplement “accompagné” vers son echec!
Le problème de la CNV c’est que :
Après, j’ai vu des changements drastiques en utilisant moi-même la CNV dans mes relations avec les autres, donc je ne peux pas dire que ça ne marche pas.
“Laisse moi te démontrer que c’est con, ce que tu demandes”, c’est une phrase que j’ai utilisé quasi texto lorsqu’un relou me demandait quelque chose du même genre que demandé dans l’article, et qu’il n’en démordait pas malgré tous mes efforts pour lui proposer des solutions alternatives. Bizarrement, le lendemain j’étais viré. Depuis, je suis passé freelance. Comme ça, quand un mec me demande un truc super long à faire, je lui dit (avec les manières) que c’est de la merde, et si il insiste, je le fais : après tout, que ce soit pour faire de la merde ou des trucs bien, je suis payé la même chose. L’avantage de la merde, c’est que je double les délais (et la facturation), histoire d’avoir le temps de faire des trucs à moi.
C’est con, ça me paraît être la base de notre boulot d’informaticien en général : si le client comprenait comment ça fonctionne, il n’aurait pas besoin de nous… Et pourtant, je vois rarement cette méthode appliquée.
J’aurais simplement souligné (c’est dit implicitement par le titre) que le principal apport de cette approche n’est même pas l’utilité de ce qu’on développe, mais le gain énorme de crédibilité auprès du client.
Les clients c’est comme les politiques, ce sont des sous-merdes, au bûcher !
Article intéressant, la mise en pratique demande du boulot…
Ca me fait beaucoup penser à cette vidéo assez connue sur le dialogue ingénieur / commercial / client.
@Sam
J’ai ma propre définition,
Se faire chier pour une âme innocente => Mélioratif, glorieux, béatitude.
Se faire chier pour le dernier des connards => Péjoratif, humiliant, sodomie.
Mon schéma à l’air négatif mais en vrai c’est beaucoup plus facile, la plupart du temps c’est “ok c’est vous le pro” et tout le monde est content.
Je suis parfaitement d’accord avec toi sur l’aspect communication et sur la nécessité impérieuse de transformer la demande technique en une expression d’un besoin fonctionnel auquel le dev va apporter la bonne réponse technique. Ce qui est paradoxalement plus facile avec un client “utilisateur final” qu’avec un client technique, genre ton patron direct.
Maintenant, en lisant le dialogue, j’ai surtout une question qui m’interpelle au plus profond de mon vécu : MangoDB est-il un outil adapté à des données qu’un utilisateur peut légitimement vouloir présenter dans excel comme des tableaux de chiffres ?
Si le dev trouve souvent, légitimement, que le “client” lui demande des trucs cons, le dev a aussi des a priori sur ce que le client devrait demander, et manque “parfois” d’ouverture, jusqu’à ce qu’on arrive à le planter devant le PC de l’utilisateur et à lui faire faire le boulot de ce dernier.
Oui, en général ça veut dire que le client ne veut pas exporter toutes les données, mais seulement un sous ensemble voir une synthèse, qui est adapté au format tabulaire.
Ca ressemble beaucoup au XY problem
J’ai du mal à comprendre cette violence envers le noSQL.
En l’occurrence MongoDB propose de base un outil pour exporter ses collections en format csv, donc le travail est vite fait ! Alors effectivement ce ne sera sans doute pas 100% ce que veut le client (typiquement problème d’imbrication : si le document contient un champ contenant une liste de dictionnaire, celui-ci sera mis tel-quel dans une cellule), mais le problème sera pas loins d’être le même avec une base relationnel (le client veut-il vraiment la table des jointures à part ?)
@coolsucker:
Je suis assez d’accord pour certains aspects concernant la BDD NoSQL
– Pas de “transparence” de la donnée au sens SQL du terme (Pas de Toad like à ma connaissance, diverses problématiques de performance suite à une conception “trop” objet…)
– Impossibilité d’y connecter aisément des outils de productivité (BO par exemple)
Mais de là à dire que cela ne peut pas supporter d’énormes volumes ou résister à une prod massive, là ce serait faire du troll gratuit.
Cependant… je suis plutôt contre le NoSQL, ne serait-ce que parce que faute d’un langage unifié (d’où la création de SQL!!!), cela ne peut mener qu’à des problèmes de relecture des données post-vie au projet.
Une excellente vidéo qui illustre parfaitement cet article: https://www.youtube.com/watch?v=BKorP55Aqvg
J’arrête pas de le regarder…
C’est excellent ! Bravo pour ces conseils et de nous ramener chaleureusement vers le bon sens. C’est juste dommage que je lise ça 6 mois après la fermeture de ma boîte. En effet, mes clients me sollicitaient régulièrement, sans prendre la moindre précaution ni demander la moindre suggestion. Ça a fini par tellement me ronger que j’ai rendu les gants, par lassitude (ou lâcheté).