to-questionnaire

转化为问卷

将用户无法独自回答的问题转化为一份问卷：一份 Markdown 文档，交给某个人异步填写，或在会议中共同填写。接收者拥有用户缺乏的知识；问卷负责把这些知识挖掘出来。

审问"发送"而非"主题"。 只询问用户关于"发送"的问题：这是他们总能回答的：发给谁，以及需要什么回来。文档中的问题则针对接收者所知与用户所需之间的差距。

1. 发给谁？ 用一个来回问清楚接收者的角色、专长，以及和用户的关系。这决定了问卷的语气和需要携带多少上下文。完成条件：你知道了接收者是谁，以及他们知道什么用户不知道的东西。

2. 你需要什么回来？ 用一个来回问清楚用户无法独自解决、需要从这个人那里获得的具体决策或事实。完成条件：你有了一个具体的清单，列出用户必须能据此做出或决定的事情。

3. 撰写问卷。 针对步骤 1-2 中确定的差距起草问题，遵循下面的文档结构。将问卷写入当前目录下的 to-questionnaire-<slug>.md 文件（slug 来自主题），并报告文件路径。完成条件：文件存在，且用户在步骤 2 中提到的每一个项目都有对应的问题覆盖。

文档结构

将文档定位为一份发现问卷：用户缺乏上下文，接收者掌握它。按重要性排序：异步意味着你可能只有一次机会：当问题超过几个时，用 ## 标题按主题分组。使用下面的模板编写。

<问卷标题>

目的： 此问卷存在的原因以及它所影响的决策。

来自： <用户> ： 发给： <接收者> ： 你的回答将用于： <去向>

背景

一段话，为不了解用户背景的接收者提供上下文。足以让他们回答好问题，不超过一页。

如何回答

截止日期和大致的投入时间。部分回答和"我不知道"同样有用：如果你对任何内容不确定，请标注出来，而不是跳过它。

<主题标题>

每个主题一个 ## 部分。每个部分下按重要性排序的问题。每个问题只有一个想法：绝不复合：每个问题下方直接留有回答位置，并且仅在问题可能被误解或导致敷衍回答时才添加一行_为什么这很重要_。

### 系统预计在发布时承担多少负载？

为什么这很重要：它决定了我们是现在为突发流量做准备，还是推迟到以后。

还有其他问题吗？

一个开放的收尾问题：我们没问到但你应该告诉我们的任何事？