第2章 质量门禁概念：定义、目标、在产品验收中的角色
质量门禁（Quality Gate）是产品验收流程中强制执行的检查节点，只有通过所有预置条件的验收项才能继续进入下一阶段。本章从SOP操作视角明确定义、分解目标、锁定角色，确保团队对“门禁”的理解和动作一致。
核心定义：质量门禁是一组预设的、基于KANO分类及验收标准的是/否检查规则集合，用于在产品验收通道的特定节点阻止不合格工件流转。
适用场景
- 版本发布前验收：开发完成后的内部验收，需逐项确认需求满足度。
- 里程碑转段：从研发阶段转入测试、或从测试转入发布时设置门禁。
- 缺陷修复回归：修复后的功能重新进入验收通道时触发门禁。
- 跨团队移交：从开发团队移交至验收团队前强制检查。
前置条件
| 条件项 | 说明 |
|---|---|
| 已建立KANO分类 | 所有需求已完成KANO问卷调查与分类，输出KANO分类表。 |
| 验收条目已定义 | 每条用户故事或特性已编写验收标准，并与KANO类别关联。 |
| 门禁规则已配置 | 确定每个门禁点的检查项（如：必备质量通过率≥100%、期望质量通过率≥80%）。 |
| 环境与数据就绪 | 验收环境、测试数据、权限账号准备完毕。 |
操作步骤
- 启动门禁检查：验收组长在项目管理工具中开启本次验收门禁实例，加载待验收工件清单。
- 加载KANO门禁规则：系统自动读取当前版本的门禁规则集（必备质量、期望质量、魅力质量的通过阈值）。
- 逐项执行验收测试：验收人员根据KANO分类执行测试用例，记录结果（通过/失败/未测试）。
- 门禁评估与判定：
- 必备质量项：必须100%通过，任何一条失败即门禁不通过。
- 期望质量项：通过率≥预设阈值（如80%），否则不通过。
- 魅力质量项：通过率≥预设阈值（如60%），否则不通过。
- 生成门禁报告：自动汇总通过/失败条目、未达标的KANO类别，输出《质量门禁检查报告》。
- 决策与通报：若门禁通过，允许工件进入下一阶段；若不通过，拒绝并附修复建议，退回开发团队。
输入输出物
| 类型 | 物品名称 | 责任人 |
|---|---|---|
| 输入 | 待验收产品（含执行文件、部署包、变更列表） | 开发团队 |
| 输入 | KANO分类表（含类别、验收标准URL） | 产品经理 |
| 输入 | 验收测试用例集 | QA |
| 输出 | 质量门禁检查报告（通过/拒绝、未达标清单） | 验收组长 |
| 输出 | KANO门禁判定记录（日志） | 系统自动 |
责任边界
- 产品经理：维护KANO分类表，定义每项需求的验收标准，对门禁规则阈值合理性负责。
- 开发团队：交付满足门禁条件的工件，并在门禁拒绝后7个工作日内完成修复。
- QA：执行验收测试，记录结果，确保测试覆盖所有KANO类别。
- 验收组长：启动门禁、审核报告、做出最终通过/拒绝决策，并通报相关方。
- 项目管理：监督门禁执行情况，确保制度落地。
记录材料
记录材料清单：
1. 质量门禁检查报告（包含每个验收项的通过/失败、KANO类别、检查时间）
2. KANO门禁判定日志（自动记录每次阈值计算过程）
3. 异常处理记录（若触发异常分支，记录原因与处理结果）
4. 门禁规则版本快照（每次门禁执行时的规则全集快照）异常处理
常见异常及应对：
- KANO分类缺失：暂停门禁，通知产品经理补充分类，补完后重新启动。
- 验收环境不可用：切换备用环境验证，若24小时内无法恢复，允许基于代码审查通过，但环境恢复后需补测。
- 门禁规则争议：由验收组长召集产品经理、QA、架构师组成仲裁小组，投票决定是否通过或调整阈值。
- 部分非核心功能未覆盖测试：标记为“有条件通过”，要求在下一迭代中补测，否则视为不合格。
验收标准
质量门禁是否通过，需同时满足以下全部条件：
- 所有必备质量（KANO M类）验收项通过率 = 100%
- 期望质量（KANO O类）通过率 ≥ 80%（可配置）
- 魅力质量（KANO A类）通过率 ≥ 60%（可配置）
- 无未解决的P0级缺陷（必备质量缺陷直接导致门禁不通过）
- 门禁报告已完整生成并由验收组长签名确认