Transforme ce que l'utilisateur ne peut pas trancher seul en questionnaire : un document Markdown qu'il transmet à une personne pour qu'elle le remplisse en asynchrone, ou qu'ils remplissent ensemble en réunion. Le destinataire détient une connaissance qui manque à l'utilisateur ; le questionnaire va la chercher.

Interroge l'envoi, pas le sujet. Ne questionne l'utilisateur que sur l'envoi, à quoi il peut toujours répondre : à qui ça part, et ce qu'il a besoin de récupérer. Les questions du document visent ensuite l'écart entre ce que le destinataire sait et ce qu'il manque à l'utilisateur.

1. À qui ça part ? Demande, en un seul échange, le rôle du destinataire, son domaine d'expertise et son lien avec l'utilisateur. C'est ce qui fixe le ton du questionnaire et la quantité de contexte qu'il doit porter. Terminé quand tu sais qui est le destinataire et ce qu'il sait que l'utilisateur ignore.
2. Qu'est-ce qu'il faut récupérer ? Demande, en un seul échange, les décisions ou les faits précis que l'utilisateur ne peut pas résoudre seul et qu'il attend de cette personne. Terminé quand tu as une liste concrète de ce que l'utilisateur doit pouvoir faire ou décider à l'arrivée.
3. Rédige le questionnaire. Formule les questions visant l'écart identifié aux étapes 1 et 2, en suivant la structure ci-dessous. Écris-le dans questionnaire-<slug>.md dans le répertoire courant (slug tiré du sujet) et indique le chemin. Terminé quand le fichier existe et que chaque élément nommé à l'étape 2 est couvert par une question.

Structure du document

Présente le document comme un questionnaire de découverte : l'utilisateur manque de contexte, le destinataire le détient. Classe les questions par importance décroissante — en asynchrone, tu n'auras peut-être qu'un seul passage — et regroupe-les par thème sous des titres ## dès qu'il y en a plus d'une poignée. Rédige-le à partir du modèle suivant.

<Titre du questionnaire>

Objet : pourquoi ce questionnaire existe et la décision qui en dépend.

De : <l'utilisateur>, Pour : <le destinataire>, Usage de vos réponses : <ce qu'elles vont servir à décider>

Contexte

Un paragraphe pour situer un destinataire qui n'était pas dans la tête de l'utilisateur. De quoi répondre correctement, pas une page.

Comment répondre

Échéance et effort approximatif. Les réponses partielles et les « je ne sais pas » sont utiles : signalez ce dont vous n'êtes pas sûr plutôt que de passer la question.

<Titre de thème>

Une section ## par thème. Dessous, ses questions, par importance décroissante. Chaque question porte une seule idée, jamais deux, avec un emplacement de réponse juste en dessous, et un pourquoi ça compte d'une ligne uniquement là où la question pourrait être mal comprise ou appeler une réponse expédiée.

Pourquoi ça compte : cela décide si l'on dimensionne dès maintenant pour les pics de trafic ou si on le reporte.

Autre chose ?

Une question ouverte pour finir : y a-t-il quelque chose que nous n'avons pas demandé et que nous devrions savoir ?

Adaptation française de to-questionnaire de Matt Pocock (licence MIT). La méthode est la sienne, intégralement. Écarts assumés : la langue et les intitulés du modèle, le nom du skill (questionnaire, pour ne pas entrer en collision avec l'original si le plugin est installé un jour) et celui du fichier produit (questionnaire-<slug>.md, dont le préfixe décrit le document plutôt que le skill).