第4章 需求澄清会议

4.1 适用场景

需求澄清会议适用于以下三类典型场景，团队可根据触发条件决定是否立即召开或合并至常规例会：

• 新需求初始描述模糊： 业务方提交的需求描述缺少核心要素（如用户故事未覆盖边界条件、验收标准为空）。
• 多方需求冲突： 不同利益相关方对同一需求的优先级、实现方案、预期效果存在明显分歧，需现场对齐。
• 需求依赖关系复杂： 单一需求涉及多个子系统、多个团队协作，或与已有功能产生预期外耦合。

4.2 前置条件

会议召开前必须满足以下条件，否则应推迟会议并补齐缺失项：

4.3 参会角色与责任边界

需求澄清会议的角色定义遵循“RACI 矩阵”原则，每个角色在会前、会中、会后有明确的可交付物边界。

4.4 会议议程（操作步骤）

标准化议程采用“30-60-90 分钟”弹性时间盒，每阶段均有明确输出物。以下为 60 分钟标准议程模板：

4.5 决议记录

每项需求在会后必须有明确的决议状态。决议记录应结构化地写入需求管理工具中，格式建议如下：

4.6 异常处理

需求澄清会议中常见的两类异常为需求模糊和需求冲突，必须使用标准处理流程，避免会议超时或决议悬空。

4.6.1 需求模糊处理流程

• 识别标志： 参会者无法复述需求的核心目标，或连续提出 3 个以上“什么场景下算完成”类问题。
• 处理动作：
  1. 主持人暂停当前流程，标记该需求为“模糊-待补充”。
  2. 现场通过“5W1H 追问法”补充：Who（谁用）、What（做什么）、When（何时用）、Where（在哪用）、Why（为何做）、How（期望怎么做）。
  3. 若 5 分钟内无法达成清晰描述，将该需求移出本次会议议程，分配责任人在 3 个工作日内补充后二次澄清。
• 规避原则： 模糊需求不得进入“一致通过”决议，必须至少达到“条件通过”状态。

4.6.2 需求冲突处理流程

• 识别标志： 两个或以上角色对同一需求的取值范围、实现方案、价值判断给出互斥意见。
• 处理动作：
  1. 主持人确认冲突各方是否掌握相同信息；若存在信息差，先补充信息。
  2. 使用“利弊对比表”现场记录每方意见的收益与成本，量化差异。
  3. 若 10 分钟内仍无法达成一致，升级至项目发起人或产品委员会裁决。
  4. 升级后的裁决结果以书面形式存档，作为后续 RICE 评分的约束条件。
• 规避原则： 冲突升级期间，对应需求标记为“持续冲突”，不计入评分队列。

4.7 需求澄清会议流程图

下图完整展示了从会前准备到会后决议的完整链路，以及异常分支的处理路径：

4.8 输入输出物

4.9 验收标准

需求澄清会议结束后，必须满足以下标准方可视为有效完成：

• 决议覆盖率 ≥ 100%： 会议中讨论的每项需求均被标记为“一致通过”、“条件通过”、“持续冲突”或“搁置/取消”，无遗漏项。
• 纪要分发及时性： 会议结束 2 小时内，会议纪要已通过邮件或协作工具送达所有参会者及缺席者。
• 需求状态可追溯： 需求管理工具中每条需求的“决议状态”、“最后更新人”、“更新原因”字段均已填写，留痕可查。
• 异常需求有主： 被标记为“模糊”或“冲突”的需求均已分配唯一责任人，且系统记录了预计完成日期。
• 评分准入条件： 只有标记为“一致通过”或“条件通过（条件已满足）”的需求才会流入下一章“RICE 评分”环节。