第2章 需求原型边界确认的术语统一

适用场景

• 项目启动阶段，需求文档首次产出的评审准备会议
• 多部门协作（产品、设计、开发、测试）的术语对齐环节
• 新成员加入后，需要快速建立团队通用语言
• 需求评审前发现关键概念存在歧义（如“原型”与“高保真设计”混淆）

前置条件

1. 已有需求初稿（可以是PRD、用户故事或业务描述）
2. 已产出至少一版原型（低保真/高保真均可，但需明确版本）
3. 确定评审会议的组织者（通常是BA或PM）
4. 评审会议前24小时将术语统一议题通知所有参与者

操作步骤

1. 组织者逐条定义四个术语：按下方表格内容向团队宣读，并给出项目实际案例。
2. 识别常见误区：对照“常见误区”列，让团队判断是否在项目中遇到过类似情况。
3. 团队确认并修正：允许参与者提出补充或修改，但在会议内达成一致版本。
4. 形成术语共识记录：将定义、示例、误区整理为一张术语表，共享到项目空间。
5. 签字或打赏确认：要求核心成员在共识记录上确认（在线或纸质），避免后续翻旧账。

术语定义与常见误区对照表

术语关系与误区总览图

输入输出物

责任边界

• 组织者（PM / BA）：负责编写术语定义初稿、主持统一会议、记录并分发共识。
• 设计师：确认原型概念是否与团队定义一致，指出可能混淆的细节（如“原型=低保真草图”还是“原型=可交互高保真”）。
• 开发工程师：从实现角度验证定义是否无歧义，特别是“边界”术语是否包含了技术约束。
• 测试人员：确保“确认”概念包含可测试的标准，避免“确认=验收”的经典误区。

记录材料

1. 术语统一共识表（推荐格式）：

| 术语   | 本团队定义                                                 | 常见误区             | 示例                                                         |
|--------|------------------------------------------------------------|----------------------|--------------------------------------------------------------|
| 需求   | 用户故事+验收条件，优先级由PM标记                           | 原型=需求            | 原型仅作演示，具体需求见Jira #123                            |
| 原型   | Figma交互原型，版本V1.2，仅用于功能验证                    | 原型=最终UI规范      | 原型中反馈文字位置非最终布局                                 |
| 边界   | 输入值域、异常流程、系统极限                                | 边界=测试用例        | 金额字段：0、负数、超出上限、非数字                          |
| 确认   | 会议纪要+Jira评论双记录，所有参会者24h内反馈                | 确认=口头同意        | 评审会后输出确认清单，每人需回复“已确认”                     |

2. 会议纪要：包含时间、参会人、讨论要点、最终决议。
3. 确认截图或电子签名：用于归档审计。

异常处理

验收标准

• ✅ 所有四个术语（需求、原型、边界、确认）均在会议中完成定义对齐。
• ✅ 至少识别并记录2条以上常见误区，且对应到具体项目场景。
• ✅ 术语共识表已上传至项目空间，所有核心成员已阅读并回复“已确认”（或相等效的确认动作）。
• ✅ 确认记录可追溯：包括会议纪要、终版术语表、确认截图。
• ✅ 在后续评审中引用本术语表时，没有人提出新的歧义点（或提出后被立即纳入更新）。