从业务问题与业务规则提炼需求，关键是把“感觉有问题”转成可指认的问题陈述，把目标转成可判断的期望结果，把规则拆成约束与例外，再合成为可追溯、可确认的需求条目。本文按问题、目标、规则、合成、澄清、检查的顺序给出操作方法与表格模板，适用于需求进入建模与评审之前的提炼阶段。
要点总览（TL;DR）
- 从业务问题出发，先把模糊痛点还原成包含业务对象、发生场景、受影响角色和影响的问题陈述，再进入目标与规则分析。
- 把方向性目标转成可判断的期望结果，写清对象、动作、可观察变化、基线与责任人，作为需求提炼的锚点。
- 业务规则按适用对象、触发条件、约束动作、例外四段书写，制度文件、审批口径与一线惯例的冲突单独列为待确认项。
- 需求条目由来源问题、期望结果、规则依据、范围边界和待确认点组成，颗粒度以一位业务负责人能否明确确认为拆分标准。
- 澄清会议按场景—目标—规则—边界—验收的顺序提问，确认结论、回执方式和遗留问题都要留痕，遗留问题关闭前不视为需求已确认。
先还原业务问题：从现象到可描述的问题陈述
业务方提出的往往是现象，例如“审批太慢”“客户老是投诉”“月底总要加班对账”。这些说法指向真实困扰，但还不能直接分析。第一步是把现象还原成包含对象、场景、角色和影响的问题陈述，让团队对“问题发生在哪里”形成一致认识。
记录时建议固定字段，避免每次描述口径不同。一份可用的业务问题陈述表包含以下内容：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 问题现象 | 可观察到的具体表现，带数量或频次 | 大客户合同审批平均耗时5个工作日 |
| 发生场景 | 什么业务环节、什么触发条件下出现 | 合同金额超过50万元的销售合同提交审批时 |
| 受影响角色 | 谁遇到问题、谁承担后果 | 销售负责人、法务审核人、财务复核人 |
| 业务对象 | 问题作用在哪些单据、记录或数据上 | 销售合同及其折扣条款 |
| 影响 | 对周期、成本、合规或客户体验的具体影响 | 签约周期拉长，个别客户转向竞品 |
| 待验证假设 | 对原因的判断，标注尚未证实 | 假设：法务与财务串行审核导致等待时间叠加 |
区分症状与原因，靠提问方式实现。面对“审批太慢”，可以追问：慢在哪个节点、由谁造成等待、等待期间发生了什么、哪些类型的合同慢得最明显、如果只改一个环节最可能改善哪里。这类提问把注意力从情绪评价引向可核查的事实。原因判断在此时只作为假设记录，避免过早锁定方案。
问题陈述的完成标志是：能指认具体业务对象，能说明发生场景与触发条件，能列出受影响角色及其承担的影响。三条都满足，问题就具备了进入下一步分析的基础；缺其中任何一条，说明还需要补充访谈或数据。
把业务目标转成可判断的期望结果
目标是方向性表述，例如“提升合同审批效率”；期望结果是目标在具体对象上的可观察变化，例如“金额50万元以上的销售合同，从提交到审批完成的中位时长由5个工作日降至2个工作日”。目标回答“为什么做”，期望结果回答“做到什么程度算达成”，后者才能作为需求提炼的锚点。
把目标转成期望结果，需要明确三个判断口径：作用对象是谁或什么，发生什么动作或状态变化，变化如何被观察到。仍以上述目标为例，对象是特定金额区间的销售合同，动作是从提交到审批完成，可观察变化是处理时长的统计值。三个口径写清楚，后续讨论范围与验收时才有共同参照。
目标表述含糊时，可用以下问题清单澄清：
- 这个目标针对哪类业务对象或哪类客户，是否区分优先级？
- 希望改变的是周期、准确率、合规覆盖率还是人工投入，主次如何？
- 当前基线是多少，数据从哪里取，统计口径由谁确认？
- 改善到什么程度可以接受，什么程度算超出预期？
- 目标达成的时间范围是什么，是否分阶段？
- 这个目标由谁最终认定达成，谁对结果负责？
澄清结果整理为目标—期望结果对照表，每行包含目标原文、拆解后的期望结果、判断口径（对象、动作、观察方式）、基线与目标值、责任人。一个目标可以对应多条期望结果，但每条都要能独立判断是否达成。责任人一栏不可空缺，否则后续验收容易出现无人拍板的情况。
拆解业务规则：约束、条件与例外分支
业务规则是需求中最容易被口头带过的部分。业务方常说“按制度来”，但制度条文、审批习惯和一线变通之间常有差异。拆解规则的任务是把这些差异显性化，形成可逐条讨论的规则清单。
规则来源通常有三类：制度文件与管理办法，审批口径与授权矩阵，一线操作惯例。三类来源要分别识别并标注出处。制度文件提供正式约束，审批口径反映实际授权边界，一线惯例往往包含未写入文件的例外处理。三者不一致之处，正是澄清的重点。
每条规则建议按统一结构书写：适用对象、触发条件、约束动作、例外情形。例如“销售合同折扣低于八折时，须经销售总监审批；战略客户年度框架协议内的折扣按协议约定执行，不重复审批”。这条规则中，适用对象是销售合同折扣，触发条件是低于八折，约束动作是销售总监审批，例外是框架协议内折扣。
规则之间出现冲突或口径不一致时，不要在现场强行裁决，而是记录为待确认项，写明冲突的两条规则、各自来源、影响范围和建议裁决人。常见冲突包括：制度规定与系统实际控制不一致、不同部门对同一条件的阈值理解不同、例外条款的适用范围没有界定。把这些条目集中列出，交由规则归属方确认，比在需求文档里含糊带过更可靠。
从问题、目标与规则合成需求条目
前三步的产出是分散的：问题陈述说明现状，期望结果说明方向，规则清单说明约束。合成阶段把它们组织成一条条可分析、可确认的需求条目，每条都能回答“为什么需要它、它要达成什么、受什么约束、边界在哪里、还有什么没定”。
需求条目建议包含以下组成：来源问题（引用问题陈述编号）、期望结果（引用对照表条目）、规则依据（引用规则清单编号）、范围边界（本次包含与不包含的内容）、待确认点（尚未达成一致的问题及责任人）。这种写法让每条需求都可追溯，评审时能快速判断依据是否充分。
颗粒度控制遵循两条原则。其一，一条需求对应一个可独立确认的业务能力或规则变化，避免把多个不相关的诉求塞进同一条。其二，当一条需求内部存在多个条件分支且分支的确认人不同时，按分支拆分，使每条都能由明确的角色确认。拆分过细会增加管理成本，判断标准是：这条需求能否由一位业务负责人给出明确的确认或否定意见。
合成阶段只处理“需求是什么、边界在哪、依据是什么”。具体的流程建模、状态设计、界面表达、数据字段定义，留给需求建模与表达阶段；需求质量检查与正式评审流程，属于需求评审与确认环节。在提炼阶段提前展开这些内容，容易在口径未定时反复返工。
澄清会议怎么开：角色、问题清单与确认记录
澄清会议的目标是逐条消除需求条目中的待确认点，并形成可回执的确认记录。会议能否有效，取决于角色是否到齐、问题是否按顺序提出、结论是否当场留痕。
角色分工上，业务方负责说明问题背景、期望结果和业务取舍；需求分析人员负责组织问题清单、记录结论、识别遗漏；规则归属方（如法务、财务、合规的授权人）负责确认规则口径与例外边界。三类角色缺一，规则类问题往往只能得到“回头再问”的答复。
提问顺序建议按场景—目标—规则—边界—验收推进。先确认问题发生的场景是否描述准确，再确认期望结果的判断口径与基线，然后逐条过规则的条件与例外，接着明确本次范围包含与不包含什么，最后确认每条需求的验收依据。按此顺序提问，前面的结论可以作为后面讨论的前提，减少来回跳跃。
确认记录建议包含：需求条目编号、确认事项、确认结论、确认人、确认日期、回执方式、遗留问题及下次确认时间。回执方式可以是会议纪要邮件回复、文档批注确认或工作项状态变更，关键是留下可查证的确认痕迹。遗留问题单独成表跟踪，避免散落在会议纪要正文中被遗忘。
当需求条目、确认记录和遗留问题需要在多人之间持续流转时，可以把它们放进统一的工作项与文档空间管理：需求条目作为工作项记录来源问题与规则依据，确认结论和回执附在条目下，遗留问题保持待办状态直到关闭。ONES 支持工作项与文档的关联管理，适合承载这类需要持续跟踪的澄清过程；具体配置方式按团队现有流程设定。
示例：一条业务需求从问题到可确认
以下示例为演示情景，用于说明各步骤产出的衔接方式。
问题陈述。现象：采购付款申请在财务复核环节平均滞留3个工作日。场景：单笔金额20万元以上的采购付款申请提交后。受影响角色：采购经办人、财务复核人、供应商。业务对象：采购付款申请单。影响：供应商账期被拉长，个别供应商要求现款提价。待验证假设：复核人需手工比对合同与发票信息，比对耗时集中在附件不全的单据上。
期望结果。目标原文为“加快付款复核”。拆解后：金额20万元以上的采购付款申请，从提交到财务复核完成的中位时长由3个工作日降至1个工作日；因附件不全退回的比例由当前水平下降。判断口径为付款申请单的复核完成时间与退回记录，基线数据由财务提供，责任人为财务复核负责人。
规则拆解。规则一：单笔20万元以上付款须经财务复核，适用对象为采购付款申请，触发条件为金额阈值，约束动作为复核，无例外。规则二：合同、发票、验收单三单齐全方可复核通过，例外为框架协议内月度汇总付款可凭汇总单复核。规则三：供应商银行账户变更后的首笔付款须双人复核，来源为财务内控办法。冲突待确认项：一线惯例中存在“紧急付款先放行后补单”的做法，与规则二不一致，需财务负责人确认是否保留及适用条件。
合成后的需求条目。来源问题引用问题陈述编号；期望结果引用时长与退回比例两条；规则依据引用规则一至三；范围边界为本次仅覆盖20万元以上采购付款的复核环节，不涉及付款审批链上游；待确认点为紧急付款例外是否保留、附件完整性校验由谁执行。确认结论：财务负责人确认保留紧急付款例外但须在系统中标注原因并事后补单，附件完整性由采购经办人提交时自查、复核人抽查。遗留问题：抽查比例待定，责任人为财务复核负责人，两周内确认。
完成检查：需求达到可分析可确认的判断标准
提炼与澄清是否完成，可以用一份清单逐项核对。以下条目全部通过，需求才具备进入建模与评审的条件。
- 问题陈述包含可指认的业务对象、发生场景、受影响角色与具体影响，待验证假设已标注。
- 每条期望结果都有对象、动作、可观察变化三个口径，基线与目标值有来源，责任人明确。
- 规则清单覆盖制度文件、审批口径、一线惯例三类来源，每条规则写明适用对象、触发条件、约束动作与例外。
- 规则冲突与口径不一致已记录为待确认项，标注了建议裁决人。
- 每条需求条目可追溯到来源问题、期望结果与规则依据，范围边界写明包含与不包含。
- 待确认点均有责任人与确认时限，已确认事项有回执记录。
- 验收依据逐条可判断，不依赖“符合业务需要”这类无法核对的表述。
检查不通过时，按缺口类型退回对应步骤补充：问题描述缺对象或场景，退回问题还原；期望结果缺基线或责任人，退回目标澄清；规则缺例外或来源不明，退回规则归属方确认；需求条目无法追溯，退回合成环节补齐引用。遗留问题在关闭前不应视为需求已确认，可在需求条目上保留待办状态，待回执后再转为已确认。
常见问题
业务方只给出一句“流程太慢”，第一步应该问什么？
先把评价性说法转成可核查的事实。可以按顺序追问：慢在哪个环节、由谁造成等待、等待期间发生了什么、哪类单据或客户受影响最明显、当前耗时数据从哪里取。回答落到具体业务对象和场景后，再填入问题陈述表的现象、场景、角色、对象、影响几栏。原因判断此时只作为待验证假设记录，不急着定方案。
业务目标本身就有多个版本，澄清时以哪个为准？
先把各版本目标并列写出，标注提出人和出处，再逐条追问判断口径：针对哪类对象、希望改变的是周期还是准确率、基线数据由谁提供、达成时间范围是什么、由谁认定达成。口径能对齐的部分直接形成期望结果；仍不一致的，记录为待确认项并指定裁决人，避免在需求条目里同时保留互相矛盾的目标表述。
一线实际操作与制度文件不一致时，规则该怎么记？
两条都记录，不要在现场强行统一。制度条文标注文件出处，一线惯例标注访谈来源和适用范围，然后写明冲突点、影响范围和建议裁决人。例如“紧急付款先放行后补单”与“三单齐全方可复核”并存时，把是否保留例外、适用条件和补单时限交给规则归属方确认。确认前，相关需求条目保留待确认状态。
一条需求拆到什么程度算合适？
判断标准是能否由一位业务负责人给出明确的确认或否定意见。一条需求对应一个可独立确认的业务能力或规则变化；当内部存在多个条件分支且各分支确认人不同时，按分支拆开。拆得过细会增加跟踪成本，拆得过粗会让确认人无法对整条需求表态，两种情况都应在合成阶段调整。
澄清会议开完，怎样算需求已经确认？
确认需要留下可查证的痕迹：每条需求的确认事项、结论、确认人、日期和回执方式都有记录，验收依据逐条可判断，遗留问题有责任人和确认时限。遗留问题未关闭前，需求条目保持待办状态，待回执后再转为已确认。仅有会议纪要中的口头同意，不足以作为确认依据。
