La question qui contenait sa propre réponse
Une question orientée en séance de discovery a coûté deux mois d'automatisation que personne n'a utilisée. Les trois règles d'entretien que je suis depuis.
Au début de mes années de conseil, j'ai participé à une séance de discovery avec la responsable des opérations d'un client. Je voulais comprendre comment son équipe traitait un fichier de rapprochement quotidien. J'avais une hypothèse : le travail était répétitif, il gagnerait à être automatisé, l'équipe était probablement en sous-effectif pour le volume.
La première chose que j'ai demandée, c'est : « Vous ne pensez pas que ça aiderait si on automatisait ça ? »
Elle a dit oui. Évidemment qu'elle a dit oui. Je lui avais demandé, devant son propre patron, si elle aimerait que son équipe soit soulagée. La seule réponse qui ne la faisait pas passer pour ingrate était celle que j'avais déjà écrite dans la question.
Nous avons passé deux mois à construire l'automatisation. L'équipe l'a utilisée une semaine, puis elle est discrètement retournée sur Excel.
Quand je suis revenu demander pourquoi, la vraie histoire est sortie. Le rapprochement n'était pas la partie pénible de leur journée. La partie pénible, c'était le fichier en amont : il arrivait en retard, dans des formats incohérents, avec des lignes qui contredisaient celles de la semaine précédente. Le fonctionnement sous Excel s'était construit autour de ces bizarreries. L'automatisation que nous avions construite était stricte là où ils avaient appris à être souples, et elle cassait à la première ligne mal formée.
La vraie correction se situait en amont, et elle n'était pas technique. C'était une conversation avec le producteur des données sur des garanties de format. Une conversation que nous n'avons jamais eue, parce que ma première question lui avait fermé la porte avant même qu'elle s'ouvre.
Cette séance est le moment où j'ai commencé à prendre l'entretien au sérieux, comme un métier. J'ai reconstruit ma pratique de la discovery autour de trois règles, et je les suis depuis.
Pas de questions en forme de solution. La forme de la question contraint la forme de la réponse. « Est-ce que ça vous aiderait d'avoir X ? » obtiendra un oui poli. « Racontez-moi la dernière fois que ça a fait mal » obtiendra l'histoire dont vous avez besoin.
Les cinq pourquoi, sans raccourci. La première réponse est la surface. La deuxième est le contournement. La troisième est généralement la contrainte. Au-delà de la quatrième, vous touchez le vrai moteur, qui est presque toujours organisationnel, économique, ou lié à la peur de mal paraître.
Écrire les Faits d'abord, les Insights ensuite, les Recommandations en dernier. Les deux mois perdus sur la mauvaise automatisation étaient deux mois de recommandations bâties sur un seul fait biaisé. Si j'avais écrit « J'ai posé une question orientée ; elle a dit oui » dans la couche des Faits, aucun Insight honnête n'aurait survécu à son contact.
La discipline n'a rien de glamour et elle n'impressionne pas dans une proposition commerciale. Mais c'est la seule chose que je connaisse qui empêche le mode d'échec silencieux : livrer la mauvaise chose, dans les délais, dans le budget, correctement construite, et discrètement inutilisée.
La méthode complète est sur la page Méthode. La version courte est celle du début : passer plus de temps à comprendre le problème qu'à concevoir la solution.