3. 评审节点设定原则
评审节点是上线验收流程的骨架。若节点过密，团队陷入“评审疲劳”；节点过疏，风险可能被隐藏至交付末期。本原则将评审节点分为三类，形成三层防线：关键节点（细粒度检查点）、阶段门（跨阶段阻断闸）、里程碑（重大标志性决策点）。三者协同，既保证日常质量收敛，又提供阶段性的“放行/回退”决策锚点。
核心设计思想：关键节点负责“事中纠偏”，阶段门负责“阶段接管”，里程碑负责“全局进度承诺”。三类节点映射到统一的时间轴与职责矩阵，避免节点冲突或责任真空。
实践提示：对已上线产品做复盘时，若发现某次发布后故障集中爆发，往往是因为该功能对应的阶段门被“软跳闸”——评审人员基于非正式承诺放行。本节原则可帮助你重建刚性节点。
适用场景
- 上线验收流程尚处设计阶段，需要确立节点颗粒度与分类标准。
- 现有评审节点过多（>20个/项目）导致评审流于形式，需精简并分层。
- 跨团队（Dev/QA/Ops/SRE）职责不清，需要以节点为界划分交付物与决策权。
- 高风险功能（金融交易、医疗数据、公共安全）要求强控制闸门。
前置条件
- 已定义“上线验收生命周期”的阶段划分（如：需求冻结→设计评审→开发完成→集成测试→预发验证→上线审批）。
- 已收集团队历史发布中风险等级最高的3~5个事故根因，作为节点优先级参考。
- 已明确组织层面的重大里程碑清单（如季度发布、法规合规完成、主版本号跳变）。
- 拥有可操作的项目时间线与资源日历，避免节点设定脱离实际节奏。
操作步骤：三类节点设定流程
- 识别生命周期阶段：将交付过程划分为4~6个主要阶段（如需求、设计、编码、测试、预发、生产）。每个阶段必须有明确的入口和出口。
- 植入关键节点：在每个阶段内部，选择2~3个高风险活动点（如接口定义完成、单元测试覆盖率达标、安全扫描结束），标记为关键节点。这些节点由技术负责人执行检查，无需跨团队决策。
- 设立阶段门：在每个阶段出口处设置一个阶段门。阶段门要求提交该阶段的全部交付物（文档、代码、报告），由质量经理/架构师联合评审，决策是否允许进入下一阶段。阶段门一旦关闭，禁止逆向修改（除非触发异常流程）。
- 标定里程碑：在项目级时间线上，选择与外部承诺、合规审计、资源释放高度相关的节点，提升为里程碑。里程碑必须包含可量化的验收条件（如“通过全部P0测试用例”），且必须由项目总监或以上级别签字确认。
- 映射责任矩阵：为每类节点指定唯一的审批角色组合（详见“责任边界”表格），避免多人负责=无人负责。
- 裁剪与校准：根据项目规模、风险等级、团队成熟度，可合并或拆分同类节点，但三类节点必须至少各保留1个。完成后输出节点清单表（见记录材料）。
三类节点对比表
| 维度 | 关键节点 | 阶段门 | 里程碑 |
|---|---|---|---|
| 颗粒度 | 细（单个活动） | 中（整个阶段） | 粗（多阶段组合） |
| 触发条件 | 活动完成（如代码提交） | 阶段出口时间到或交付物提交 | 预定日历节点 + 条件达成 |
| 决策权归属 | 技术负责人/小组长 | 质量经理 + 架构师 | 项目总监 + 业务负责人 |
| 典型否决后果 | 局部返工（如重写接口） | 阶段延期，进入缓冲路径 | 项目暂停，触发升级会议 |
| 输出物要求 | 轻量检查清单 | 阶段总结报告 + 数据 | 里程碑验收报告 + 签字 |
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 关键节点 | 阶段内活动列表、历史缺陷记录 | 节点检查清单（节点ID-条件-责任人） |
| 阶段门 | 阶段交付物（文档/代码/报告）、阶段风险日志 | 阶段门审批表（放行/有条件放行/驳回） |
| 里程碑 | 项目计划、合规要求、外部合同条款 | 里程碑验收报告（含量化指标达成证明、干系人签字） |
责任边界
- 关键节点负责人（技术骨干）：必须完成检查清单内所有项，签注通过/不通过；不通过时通知相关开发人员3小时内修复。
- 阶段门审批人（质量经理+架构师）：共同评估阶段完整性，任何一方投否决票则门关闭；需在评审记录中注明否决原因与补偿措施。
- 里程碑签署人（项目总监/业务线负责人）：仅在收到里程碑验收报告及全部附属附件后才可签字。禁止“先签字后补材料”。
- 异常升级通道：当阶段门或里程碑被连续否决2次，自动升级至CTO/VP级决策，原审批人降为建议角色。
记录材料
每个节点设定完成后，必须记录以下内容并归档至项目质量仓库（Git/Wiki/文档管理平台）：
节点清单表（样例）
| 节点ID | 类型 | 所处阶段 | 检查条件 | 责任人 | 审批角色 |
|---------|------------|----------|--------------------------------------------|-----------------|-------------------------|
| DEL-001 | 关键节点 | 设计 | 所有接口API文档已通过技术评审 | 陈晓（架构师） | 技术负责人 |
| DEL-002 | 阶段门 | 开发→测试| 单元测试覆盖率≥70%，无P0/P1未修复缺陷 | 质量经理+架构师 | 质量经理+架构师 |
| MIL-001 | 里程碑 | 测试完成 | 全量自动化测试通过率≥95%，性能基线达标 | 项目总监 | 项目总监+业务负责人 |
异常处理
| 异常场景 | 处理措施 | 记录要求 |
|---|---|---|
| 关键节点检查未通过，但时间紧迫需要继续 | 节点责任人需提交“例外放行申请”，附风险缓解计划与最终回退截止时间；批准权归下一级阶段门审批人 | 写入节点检查清单备注栏，项目周报同步 |
| 阶段门被否决后，团队未修复即越过阶段继续开发 | 回溯该阶段所有已完成的关键节点，重新评估并强制重新执行阶段门评审；责任人在质量月报中公示 | 异常事件报告（模板：ANOMALY_阶段门_YYMMDD.md） |
| 里程碑条件已满足，但关键干系人无法参加签署会议 | 允许线上电子签章（需留存审批链截图），但需在首次可用工作日补做口头确认 | 里程碑验收报告附加“签章延迟说明” |
验收标准
本章设定的节点原则是否有效，可用以下标准检验：
- 唯一性：每个节点有且仅有一个审批负责人或审批小组，无“双头领导”情况。
- 可测量性：节点检查条件全部为二进制（通过/不通过）或百分比阈值，不出现“基本完成”“差不多”等模糊表述。
- 全覆盖：从需求冻结到上线执行，每段生命周期至少被一个关键节点或阶段门覆盖；里程碑覆盖所有影响对客户承诺的日期。
- 可审计性：所有节点的审批记录、检查清单、异常报告均可导出，保留周期不低于项目交付后6个月。
- 可裁剪性：组织可通过修改节点清单表中的“类型”列调整节点级别（如将某个关键节点提升为阶段门），无需重构整个流程。