设计研发需求访谈提纲

这个场景能帮你做什么

准备需求访谈时，只问“想要哪些功能”，得到的往往是一张愿望清单。研发更需要知道：谁在什么工况下做什么，现有办法为什么不够用，例外怎样处理，怎样才算改善。

WorkBuddy 可以依据已有项目资料准备访谈提纲，把已经知道的事实、需要验证的假设和应当追问的问题分开。它帮助准备提问，真实需求仍要通过访谈和现场证据取得。

开始前需要准备什么

• 本轮访谈要支持的决定，例如改进现有设备的换型过程，而非泛泛了解整个工厂。
• 访谈对象的角色、使用场景及已确认背景。操作者、维护人员和采购负责人的问题应分开。
• 已取得的投诉、销售记录、现行操作说明、故障或返工记录；附日期与适用型号。
• 企业不能改变的条件，例如尺寸、接口、交付期限和允许讨论的技术范围。

没有现场资料时，可以准备开放问题，但不能让 AI 编出客户的流程、预算和损失。

具体怎么做

第一步：明确这次要弄清的决定

给 WorkBuddy 一句话目标，再列出已知事实与暂时假设。例如“确认换型慢是否主要由参数设置造成”。这只是待验证方向，不能把提纲写成诱导客户认同这一结论。

第二步：按真实工作过程展开问题

先问最近一次具体经历：如何开始、经过哪些操作、谁参与、最终得到什么。再追问最费时或容易出错的地方，要求举例并说明当时条件。最后问例外路径和理想结果，让“希望更快”逐渐变成可讨论的任务条件。

第三步：为不同角色调整追问

让 AI 将同一问题拆成角色版本。操作者说明操作与限制，维修人员提供异常和恢复过程，负责人说明影响和验收方式。不要让某一个角色替所有人确认事实，也不要把三份提纲重复问一遍。

第四步：检查提问是否有诱导和遗漏

要求标出预设答案、一次问多件事、缺少时间与型号、直接让客户选择技术方案的问题。将“你是不是需要自动调参”改为“最近一次调参时做了哪些操作，哪里必须由人判断”。保留可要求对方展示的单据、记录或现场步骤。

可以直接交给 WorkBuddy 的完整要求

请为本次研发需求访谈准备提纲。研究目标、对象角色、已知资料和不可变条件见附件。
先列已知事实、尚待验证的假设和资料缺口，不能补造客户背景。
围绕“流程描述—最近一次具体问题—例外处理—希望改变的结果”组织问题。
每题注明：想验证什么、主问题、必要追问、可请求展示的证据、适合回答的角色。
问题应开放、中性、一次聚焦一件事，不预设客户需要某项功能。
对操作者、维护人员和业务负责人分别调整追问。最后标记诱导性问题、重复问题和未覆盖环节。
输出可在访谈中直接使用的提纲，以及访谈后需要补齐的证据清单；不要模拟受访者回答。

完成后会得到什么

一份按工作过程组织的提纲，每个问题都指向一个待验证事项。一个合适的条目可以是：“最近一次换型发生在什么型号之间？请按顺序说明操作；哪些参数需要试几次才能确定？有没有当班记录？”这是提问示例，不代表任何客户确有此问题。

结果应该怎么检查

检查关键假设有没有对应问题，是否问到正常与例外路径，是否能够取得记录或具体事件。再检查角色是否找对：实际使用者能够描述过程，预算与批准条件通常需要有权限的人回答。

遇到这些情况怎么处理

客户只说“效率低”时，追问最近一次事件、发生频率、等待位置和结果；不急着估算损失。客户直接指定功能时，继续问它要替代什么动作、过去试过什么。不同角色说法冲突时，列为待验证事项，安排现场或记录核对。

哪些必须人工决定

产品或研发负责人确定访谈目标、对象和优先顺序，并在沟通中判断是否继续追问。WorkBuddy 不能代替真实访谈，也不能从提纲推断客户已确认需求、预算或采购承诺。