客户一开口就说“要做一个报表看板”“要加一个审批流”，说明他已经跳到方案层。澄清的任务是把方案还原成问题：先记录客户原话中的方案动作，再逐层追问这个方案要解决谁的什么业务问题、问题在什么场景下发生、现状如何处置、期望结果如何判断。本文按“方案复述—目的追问—场景还原—结果定义—边界确认”五步展开，给出可直接使用的追问清单、角色分工、记录字段和完成检查标准，帮助需求分析人员在一次沟通内把方案描述转成可确认的业务需求陈述。
要点总览（TL;DR）
- 客户讲方案时，先复述其方案原话，再追问方案要解决谁的什么业务问题，避免直接否定引发防守。
- 按“原样记录方案—追问目的—还原场景—定义期望结果—确认边界约束”五步推进，每步都有输入、动作、输出和完成标志。
- 业务方、方案提出人、需求分析人员分别承担说明目标、补充背景、组织追问与推动确认的职责，澄清记录需包含原话、问题、场景、期望结果、约束和待确认项。
- 四类核心信息齐备、待确认项有责任人和时间、客户确认结论后即可转入需求建模与评审；方案配置类问题留到后续阶段。
先接住方案，再把话题拉回业务问题
客户用方案语言表达需求，是需求沟通中常见的起点。客户往往已经在自己熟悉的解决路径上思考过一段时间，直接说“这个方案不对”会让对方转入防守，后续追问更难展开。更有效的切入方式是先接住方案：复述客户说的方案动作，确认自己理解无误，再追问这个方案要达成的目的。澄清的目标是拿到问题陈述、发生场景、期望结果和约束条件，方案本身留到需求表达阶段再讨论取舍。
方案复述可以按“动作＋对象＋预期效果”的结构进行。例如客户说“要在合同模块加一个三级审批”，可以复述为：“您希望在合同模块增加三级审批，让合同在签署前经过三道审核。”复述之后紧接着问目的：“目前合同签署前是怎么审核的，哪一类合同让您觉得需要再加一道？”这样既表明听懂了客户的话，又把话题从“加几级审批”引向“哪类合同在什么情况下审核不足”。记录时保留客户原话，不要在这一步就改写成自己的理解，原话是后续核对澄清结论是否偏离的依据。
第一层追问可以围绕四个方向展开，形成一份“方案原话—追问问题”对照清单：
- 这个方案做出来之后，谁会在什么工作环节使用它？
- 现在没有这个方案时，这件事是怎么处理的，哪里让您觉得不顺？
- 这个问题多久发生一次，最近一次发生是什么情况？
- 如果方案上线了，您会用什么现象判断它起作用了？
这四个问题分别指向使用者与场景、现状与痛点、发生频率、期望结果，回答之后基本能判断客户说的是真问题还是惯性方案。需要区分的是，澄清阶段只负责把问题问清楚并形成记录；把澄清结果整理成用户故事、流程图、需求规格等结构化表达，属于需求建模与表达的工作；对需求条目做完整性、一致性、可测试性的正式检查，属于需求评审与确认的工作。澄清做扎实，后两个阶段才有稳定的输入。
五步澄清流程：从方案描述到业务需求陈述
五步流程适合在一次或连续两次沟通内完成，每步都有明确的输入、动作、输出和完成标志。下表给出整体框架，后文逐项说明操作要点。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 原样记录方案描述 | 客户提出的方案原话 | 逐句记录方案动作、提出人、提出场合 | 方案原话清单 | 客户确认记录没有曲解其意思 |
| 2. 追问目的 | 方案原话清单 | 针对每个方案动作追问要解决的业务问题 | 问题陈述初稿 | 每个方案动作都能对应至少一个业务问题 |
| 3. 还原场景 | 问题陈述初稿 | 追问问题发生的环节、频率、涉及角色和现状处置方式 | 场景描述 | 能用一段话讲清问题在何时何地由谁遇到、现在怎么处理 |
| 4. 定义期望结果 | 场景描述 | 追问改善后的可观察现象和判断标准 | 期望结果与判断标准 | 双方对“怎样算解决”有共同说法 |
| 5. 确认边界与约束 | 前四步输出 | 确认范围、时间、合规、系统等约束和不在范围内的内容 | 约束条件与范围边界 | 客户确认哪些做、哪些不做、受什么限制 |
第一步：原样记录方案描述与提出人
记录时保留客户使用的词，例如“看板”“审批流”“自动提醒”，不要急着替换成“报表”“工作流”“通知”。同时记录提出人及其角色，因为不同角色提出的同一方案，背后的问题可能不同：销售负责人要审批流，可能是为了控制折扣权限；财务人员要审批流，可能是为了付款合规。提出人信息还决定了后续由谁确认澄清结论。
第二步：追问目的，识别要解决的业务问题
追问目的常用“为什么需要它”“没有它会怎样”“它帮您避免什么”三类问法。客户回答后，把回答整理成一句问题陈述，格式可以是“谁在什么情况下，因为什么原因，难以完成什么”。如果客户回答仍是方案语言，例如“因为需要一个统一入口”，就继续追问统一入口解决的是找不到信息还是重复录入。完成标志是每个方案动作都能对应至少一个业务问题，对应不上的方案动作标记为待确认，不直接纳入需求。
第三步：还原发生场景、频率与现状处置方式
场景还原要问清四件事：问题发生在哪个业务环节，涉及哪些角色，发生频率如何，现在用什么方式处理。现状处置方式尤其重要，它往往包含客户已经习惯的替代做法，例如用邮件加表格人工核对。了解现状能判断问题的严重程度，也能在后续方案设计时评估迁移成本。完成标志是能用一段连贯的话描述问题场景，而不是罗列零散抱怨。
第四步：定义期望结果与判断标准
期望结果要落到可观察的现象，例如“合同从提交到完成审核的平均时间缩短”“月底对账不再需要人工逐条比对”。判断标准可以是时间、数量、差错率或某个业务动作能否顺利完成。客户说不清标准时，可以请其回忆最近一次处理顺利的情况，从中提取共同点。完成标志是双方对“怎样算解决”有共同说法，而不是停留在“更方便”“更高效”这类无法验证的描述。
第五步：确认范围边界与约束条件
边界确认包括两部分：这次要覆盖哪些业务范围、哪些明确不在本次范围；以及有哪些约束，例如上线时间、合规要求、必须沿用的现有系统、数据权限规则。约束条件要和结论写在一起，避免后续方案讨论时被忽略。完成标志是客户对做与不做、受什么限制给出明确确认。
角色分工与澄清过程要留下的交付物
澄清不是需求分析人员单方面的提问，业务方和方案提出者都要承担确认责任。角色不清时，常见结果是记录写了一堆，但没人对结论负责，进入评审后又被推翻。下表给出三类角色在澄清中的职责。
| 角色 | 主要职责 | 需要确认的内容 |
|---|---|---|
| 业务方 | 说明业务目标、现状流程和判断标准，指定业务侧确认人 | 问题陈述、期望结果、范围边界 |
| 方案提出人 | 说明方案原话和提出背景，补充其了解的场景细节 | 方案原话记录是否准确、待确认项 |
| 需求分析人员 | 组织追问、整理记录、识别待确认项、推动结论确认 | 澄清记录完整性与结论一致性 |
澄清记录建议包含以下字段，每个字段都对应后续可核对的结论：
- 方案原话：客户提出的方案描述，保留原始用词和提出人。
- 业务问题：由方案追问得到的问题陈述。
- 发生场景：环节、角色、频率、现状处置方式。
- 期望结果：改善后的可观察现象与判断标准。
- 约束条件：时间、合规、系统、权限等限制。
- 待确认项：尚未得到回答的问题，注明责任人与确认时间。
- 确认记录：客户确认结论的方式、确认人和确认时间。
确认方式可以是会议纪要回传后书面回复，也可以在需求管理工具中由客户对澄清记录进行确认。记录留痕的价值在于，后续需求表达和评审出现分歧时，能回到原始问题和客户确认过的结论上核对。对于多角色参与、待确认项较多的项目，把澄清记录和待确认项放进统一的需求池管理，可以让业务方、产品经理和研发团队看到同一份信息。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，便于追溯需求与问题来源；在会议、反馈和文档等输入场景中，ONES Assistant 可提炼要点、待澄清问题与拆解建议，帮助团队整理澄清材料，具体能力范围以实际产品版本与配置为准。
需要留给后续阶段的内容包括：把问题陈述转成用户故事或用例、绘制业务流程与状态、编写需求规格说明，这些属于需求建模与表达；对需求条目做完整性、一致性、可测试性检查和正式评审结论，属于需求评审与确认。澄清记录是这两个阶段的输入，不在澄清阶段提前完成。
示例：一句“要加审批流”如何澄清成业务需求
以下示例为演示情景，用于说明五步流程的填写方式，不代表真实客户案例。
原始方案描述：某制造企业的销售运营人员提出：“要在订单系统里加一个折扣审批流，超过一定折扣就要走审批。”提出人为销售运营专员，提出场合为季度业务复盘会。
逐层追问与回答：
- 追问目的：“为什么需要折扣审批？”回答：上季度出现几笔折扣明显低于报价标准的订单，管理层事后才发现，希望事前控制。
- 追问场景：“这类订单一般怎么产生，多久出现一次？”回答：集中在月末冲量时，由区域销售直接与客户确认折扣，平均每月两三笔，目前靠销售主管事后翻订单核对。
- 追问现状处置：“现在发现问题后怎么处理？”回答：主管发现后找销售补说明，有时已经发货，只能记录备案。
- 追问期望结果：“怎样算这个问题解决了？”回答：低于报价标准的折扣在订单确认前必须经过主管确认，月末不再需要人工翻单核对。
- 追问边界与约束：“哪些订单需要审批，审批人怎么定，有没有必须沿用的规则？”回答：只覆盖标准产品订单，项目型订单另有报价流程；审批人按区域划分；折扣标准以现行报价制度为准。
澄清后的问题陈述：月末冲量期间，区域销售在订单确认前直接与客户确定低于报价标准的折扣，销售主管只能在事后核对订单时发现，导致低价订单在发货后才被记录，缺少事前控制。
期望结果与判断标准：低于报价标准的折扣订单在确认前完成主管审批；月末人工核对低价订单的工作不再需要；判断标准为连续一个季度内低价订单均在确认前留有审批记录。
约束条件：仅覆盖标准产品订单；审批人按区域配置；折扣标准沿用现行报价制度；需与现有订单确认环节衔接。
待确认项与处理：“超过一定折扣”的具体阈值未在沟通中确定，标记为待确认，责任人为销售运营专员，约定一周内提供报价制度中的折扣档位；项目型订单是否纳入本次范围，由销售负责人在下次沟通中确认。两项确认完成前，该需求不进入正式评审。
完成检查：澄清到什么程度可以进入下一阶段
澄清不足会让评审反复，澄清过度则会拖长前期沟通、挤压方案设计时间。可以用下面的清单逐项判断，四类核心信息齐备、待确认项有归属、客户确认结论之后，即可转入需求表达与评审。
- 问题陈述是否写清了谁、在什么情况下、遇到什么业务问题，且能对应客户提出的方案动作？
- 场景是否包含发生环节、涉及角色、发生频率和现状处置方式？
- 期望结果是否有可观察的现象或判断标准，而不是“更方便”“更高效”一类描述？
- 约束条件是否覆盖时间、合规、现有系统和权限等已知限制，并写明了不在本次范围的内容？
- 每个待确认项是否都有责任人和确认时间，且不影响已确认结论的使用？
- 客户是否以书面回复、会议纪要确认或工具内确认等方式认可澄清结论？
停止追问的时机可以按两个信号判断：一是四类核心信息已经齐备，继续追问只是在补充细节；二是剩余问题属于方案设计范畴，例如审批节点怎么配置、看板用什么图表，这类问题应留到需求表达和方案讨论阶段。若客户对期望结果始终给不出判断标准，可以把“确定判断标准”列为待确认项，先推进问题陈述和场景部分，避免整轮澄清停滞。澄清结论确认后，将记录连同待确认项交接给需求建模与评审环节，由后续阶段继续跟踪闭环。
常见问题
客户坚持“先做出来看看”，不愿继续回答追问，怎么处理？
可以先把客户提出的方案作为待验证假设记录下来，与客户约定一个最小的验证范围，同时把追问聚焦到两个问题上：这个方案做出来后由谁在什么环节使用，以及用什么现象判断它有效。这两个问题回答后，至少能形成问题陈述和期望结果的初稿。若客户仍不愿展开，将未回答的部分列为待确认项，注明责任人和确认时间，先推进已确认内容，避免整轮沟通停滞。
追问目的时，客户反复用方案语言回答，如何继续往下挖？
客户回答仍是方案语言，通常说明他习惯从解决路径思考。此时可以换用具体事件提问，例如“最近一次遇到这个问题是什么情况，当时怎么处理的”，把话题从抽象方案拉到具体场景。也可以请客户描述如果没有这个方案，当前工作会卡在哪一步、由谁承担后果。回答落到具体人、具体环节和具体后果后，再整理成问题陈述，比继续追问“为什么”更容易得到有效信息。
澄清记录由谁确认，客户口头同意算不算完成？
口头同意可以作为沟通过程中的阶段性认可，但建议留下可追溯的确认记录，例如会议纪要回传后书面回复，或在需求管理工具中由客户对澄清记录进行确认。确认人应是业务方指定的负责人，确认内容至少覆盖问题陈述、期望结果和范围边界。对于多角色参与的项目，把澄清记录和待确认项放进统一的需求池管理，可以让各方看到同一份信息。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，便于追溯需求与问题来源，具体配置以实际产品版本为准。
待确认项还没关闭，需求能不能先进入评审？
取决于待确认项影响的是结论本身还是实现细节。如果未确认的是折扣阈值、覆盖范围这类会改变问题陈述和期望结果的内容，建议先不进入正式评审，避免评审基于不完整信息做出结论。如果未确认的属于方案配置层面，例如审批节点如何设置、看板用什么图表，可以在澄清记录中标注后先行交接，由需求表达和方案讨论阶段继续处理。判断标准是：待确认项是否影响“要解决什么问题”和“怎样算解决”这两个结论。
澄清阶段和需求建模、评审的边界怎么划？
澄清阶段负责把方案还原成问题，产出问题陈述、发生场景、期望结果、约束条件和待确认项，并由客户确认。把问题陈述整理成用户故事、用例、流程图或需求规格说明，属于需求建模与表达；对需求条目做完整性、一致性、可测试性检查和正式评审结论，属于需求评审与确认。澄清记录是这两个阶段的输入。边界清晰可以减少重复沟通，也能避免在澄清阶段过早陷入方案细节。
