第二章 评审场景识别：需求变更、原型交付前、跨团队协作、关键决策点
边界评审并非万能药，只有在正确的时机、正确的场景下执行才能发挥最大价值。本章给出四种最典型且必须用边界评审来管控风险的场景。每个场景都包含从触发到落地的完整 SOP，帮助评审组织者“该做就做，不该做不乱做”。
核心观点：评审不是走流程，而是防风险。识别“什么时候必须评”比“怎么评”更重要。本章的四个场景覆盖了 90% 以上的边界失控案例。
1. 需求变更场景
适用场景
- 产品负责人或客户提出新增、修改或删除功能（包括优先级调整）。
- 开发过程中发现设计假设与真实用户场景不符，需要调整原型方向。
- 政策法规、市场环境变化导致必须修改需求边界。
前置条件
- 变更请求已形成书面描述（含变更原因、预期收益）。
- 当前版本的原型或需求文档基线已锁定（版本号明确）。
- 至少有一位可做技术可行性评估的工程师参与。
操作步骤
- 接收与登记：需求负责人将变更请求记录到边界变更日志中。
- 影响分析：分析变更对已有功能、数据结构、第三方接口的影响范围。
- 边界评审预沟通：发起人、产品经理、技术负责人三方初步对齐。
- 召开评审会：按标准议程（变更描述→影响→风险评估→决策）。
- 批准/驳回：记录决策结论并更新原型基线。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 变更请求单（文字/邮件/工单） | 边界评审结论书（含影响分析表） |
| 当前原型文件（基线版） | 更新后的原型（或驳回通知） |
责任边界
- 需求负责人：撰写变更请求、组织评审会。
- 技术代表：提供可行性及工作量评估。
- 决策者（产品经理/Sponsor）：最终批准或驳回。
- 原型设计师：更新原型文件并记录变更历史。
记录材料
- 边界变更日志（包含时间、变更内容、决策、责任人）。
- 评审会议纪要（含签名或电子确认）。
- 原型版本差异对比表。
异常处理
当技术评估显示变更将导致 2 个以上 sprint 延期或破坏已有兼容性时，应升级至项目高层决策，并触发更完整的风险评审流程（非本场景边界评审可覆盖）。此时需暂停当前原型修改，直到获得书面风险接受书。
验收标准
- 变更请求单已闭环（批准/驳回）。
- 原型基线已更新，变更日志已补充。
- 所有参与方对变更影响达成共识。
2. 原型交付前场景
适用场景
- 原型达到可交互演示状态，准备交付给下一个环节（如开发、用户测试）。
- 原型上线前最后一次边界确认（如内测版、公测版）。
- 跨阶段移交（如从设计团队移交至开发团队）时。
前置条件
- 原型已完成所有预设功能点，并经过至少一轮内部自测。
- 边界清单（含约束条件）已准备就绪。
- 接收方已指定接口人。
操作步骤
- 自检清单核对：原型设计师按《原型交付前自检表》逐项确认。
- 边界清单匹配：将原型功能与需求边界清单逐条对照，标记差异。
- 召开交付前评审会：演示原型，展示边界覆盖情况。
- 客观缺陷登记：记录未覆盖的边界或超出边界的冗余功能。
- 交付签字：双方确认并归档。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 可交互原型（URL/文件） | 交付确认单（含边界覆盖矩阵） |
| 边界清单（最新版） | 缺陷/差异清单（如有） |
| 自检表 | 原型基线冻结标记 |
责任边界
- 原型设计师：提供原型、参与演示、记录缺陷。
- 接收方代表：对照边界清单逐项验收。
- 测试/QA（可选）：辅助确认边界覆盖。
记录材料
- 交付前边界覆盖矩阵（功能 vs 边界条件）。
- 自检表完成签名版。
- 评审会签到的记录（含参会人）。
异常处理
若发现原型严重偏离边界（例如遗漏了 20% 以上的核心约束），应中止交付流程，退回至设计阶段重新调整。回退后需重新触发变更场景，并更新原型。不得在交付前评审中临时修补。
验收标准
- 原型边界覆盖率达到 100%（所有已知边界条件均已实现或明确排除）。
- 无未解决的边界冲突。
- 接收方对交付物签字确认。
3. 跨团队协作场景
适用场景
- 原型依赖外部团队的数据接口、算法、第三方 SDK 才能完整演示。
- 两个以上团队需要就同一原型的功能边界达成一致。
- 涉及外部供应商/合作伙伴提供的组件集成。
前置条件
- 跨团队协作的边界协议草稿已编写（如接口定义、错误处理约定、超时规则）。
- 各团队已指定联络人。
- 集成测试环境（mock 或沙箱）已就绪。
操作步骤
- 边界协议预审：各团队分别审查自己涉及的边界条款。
- 联合评审会议：逐条走读协议，确认双向边界。
- 原型联调演示：将双方的原型进行端到端链路验证。
- 争议点仲裁：记录未达成一致的部分，由项目决策层拍板。
- 协议定稿：更新边界协议并签署。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 跨团队边界协议草稿 | 跨团队边界协议定稿（含签名） |
| 各团队原型/接口文档 | 联调测试报告 |
| 争议记录清单 | 仲裁结论书 |
责任边界
- 集成负责人：协调会议、记录争议、跟踪协议落地。
- 各团队接口人：确保本团队的边界条件准确传达。
- 项目总监/Sponsor：对未达成共识的争议做最终裁决。
记录材料
- 跨团队边界协议 PDF。
- 联合评审会议纪要（含 log 或录音）。
- 联调环境配置记录。
异常处理
若多个团队对同一边界条件持不可调和意见，应暂停联调并启动升级流程：技术仲裁（架构组）→业务仲裁（产品委员会）→项目暂停。在所有仲裁完成前，原型不得向下游移交。
验收标准
- 所有关键边界条款已定稿。
- 原型在联调环境中能够按协议正常运行。
- 无未提交、未分类的争议项目。
4. 关键决策点场景
适用场景
- 原型设计涉及重大成本投入（如构建完整后端 mock、采购第三方服务）。
- 原型成果将决定项目方向（如是否继续投资/上线/终止）。
- 出现必须进行商业边界权衡的时刻（如功能范围 vs 截止日期）。
前置条件
- 已有多个可选项（至少两个不同的边界范围方案）。
- 已有量化的成本/时间/风险对比数据。
- 具备财务或业务决策权的人出席。
操作步骤
- 边界假设清单构建：列出每个决策选项对应的边界假设。
- 方案影响评估：每个方案对交付时间、预算、用户满意度的影响。
- 召开决策评审会：演示不同边界下的原型表现，展示权衡。
- 投票/决策：按预决策机制（如加权评分、RICE 打分）选最优解。
- 决策通讯：将决策结果写入边界决策日志并通知所有相关方。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 候选方案边界文档 | 边界决策报告（含选择原因） |
| 成本/时间/风险报表 | 更新后的项目计划与原型需求基线 |
| 原型演示文件（多个版本） | 决策日志条目 |
责任边界
- 产品负责人：准备方案、组织决策材料。
- 分析师：提供量化数据。
- 决策者（如副总裁/产品委员会）：做出最终选择并承担后果。
- 项目经理：将决策转化为具体行动计划。
记录材料
- 关键决策点记录表（含决策日期、参会人、表决结果）。
- 方案对比矩阵（多维度评分）。
- 原型对应的边界假设日志。
异常处理
如果决策评审会上无法达成一致（例如票数持平或数据不充分），应推迟决策至获得更全数据后再评审，但推迟不得超过 2 个工作日。超过时限后由最高决策者单独拍板，并记录为“特权决策”，加入组织流程改进项。
验收标准
- 有明确的决策输出（文字描述、选定的边界方案）。
- 决策记录已归档，可追溯。
- 所有参会人员对决策过程认同（不要求对结果认同）。
总结：上述四个场景构成了最核心的评审触发清单。当要开展评审时，先问“这是什么场景？”然后用对应 SOP 快速启动。建议团队将这四种场景的判断条件贴到墙上（或放入团队 Wiki），作为每日站会的快速引用工具。