3. KANO 与质量门禁的融合：如何用 KANO 驱动验收标准

3.1 适用场景

本流程适用于以下场景：

• 需求颗粒度细化阶段：从 PRD 或用户故事提取具体验收点时，需要判断该验收点满足的是哪一层用户期望。
• 验收标准模板编制阶段：团队在定义“完成定义”（DoD）时，需按 KANO 属性分配不同的硬性检查项。
• 跨角色评审节点：产品经理、QA 与开发在质量门禁前对标认知，避免“开发认为做完，产品认为不够”的认知偏差。

3.2 前置条件

序号	条件项	说明
1	需求源已拆分	至少完成用户故事拆分，粒度不超过 1 人日。
2	KANO 分类已输出	已通过问卷或团队共识为每个需求贴上 KANO 属性标签（M / O / A / I / R）。
3	验收项模板就绪	存在可复用的“功能验证-性能验证-负面场景”验收项模板。
4	团队 KANO 基础培训	QA、开发、产品三方均理解 KANO 四种基础属性的及格线与加分线。

3.3 操作步骤

1. STEP 1：需求分类标注

   针对每个需求条目，明确其在 KANO 模型中的分类（必须型 M、期望型 O、魅力型 A、无差异型 I）。

   建议使用“正向/反向”双确认法：正向具备该功能满意度如何，反向不具备是否接受。
2. STEP 2：映射验收属性

   为每个 KANO 属性定义验收标准的结构模板：

   1. M（基本型）：强制通过。验收标准中必须包含 【硬性检查项】，如：
      功能不可缺、无崩溃、数据保存合规。
   2. O（期望型）：线性满足。验收标准中包含 【性能阈值】 与 【易用性锚点】。
   3. A（魅力型）：鼓励超越。验收标准中包含 【亮点体验】，如：
      动画流畅度 ≥ 60fps、一手操作可达率 100%。
3. STEP 3：验收项清单编制

   按“属性-功能点-验收点”三维矩阵，将验收标准拆解为最小可测单元。每个单元需标注 KANO 标签。

4. STEP 4：门禁阈值设定

   定义质量门禁的 “红灯-黄灯-绿灯” 规则：

   • 红灯：任何 M 类验收点失败 → 质量门禁不通过。
   • 黄灯：O 类 ≤ 20% 失败，A 类全部通过可降黄灯加观察。
   • 绿灯：所有 M 类全通过，O 类通过率 ≥ 90%，A 类 ≥ 1 项通过。
5. STEP 5：验收执行与判定

   执行测试或走查，逐条核对验收点，分别统计 M/O/A 的达成率，依据 STEP 4 的门禁阈值给出最终门禁结果。

3.4 输入输出物

方向	物	内容要点
输入	需求功能清单（带 KANO 属性）	需求 ID、功能描述、KANO 分类、优先级。
输出	KANO 驱动验收标准矩阵	功能点 → 验收属性 → 验证方法 → 门禁阈值。
输出	质量门禁判定报告	M/O/A 通过率、不达标项清单、门禁结论。

3.5 责任边界

角色	职责内容	不承担职责
产品经理 (PM)	提供 KANO 属性初始分类，确认 M 类底线定义。	不负责测试用例编写。
用户体验研究员 (UX)	提供 A 类验收的体验侧描述（如愉悦度）。	不制定性能阈值。
测试 / 质量保障 (QA)	将 KANO 验收点转化为可测用例，执行门禁判定。	不拒绝 PM 确认过的分类。
开发工程师 (Dev)	依据验收点自测，确保 M 类全绿。	不调整门禁阈值。

3.6 记录材料

每次门禁需保留以下 3 份记录：

• 验收标准矩阵（须带 KANO 标签）：用于追溯某次门禁为何通过或失败。
• KANO 分类争议记录：若某需求分类存在分歧，记录原始分类、争议点与最终决议。
• 门禁判定快照：包括 M/O/A 通过率与不达标具体条目。

3.7 异常处理

异常场景	处理方案
M 类验收点不明确	第一时间与 PM 和 QA 三方对齐，以“该功能缺失用户是否不可使用”重新锚定。
某需求同时符合 M 与 O 特征	取最严厉等级：按 M 类处理门禁，并在记录中标记为“M+O 混合”。
A 类验收标准过高无法达成	门禁不记红灯，转加入“体验债”队列，不阻塞当前版本。
验收点样本量不足	要求至少 80% 的验收点具备可测性，不足部分留空并注明“待补充”，不作为扣分项。

3.8 验收标准（本章输出物的通过标准）

• 【完整性】每个需求条目都被标注 KANO 属性（M/O/A/I/R）。
• 【一致性】M 类验收点 无遗漏且全部为硬性检查项（不可为建议项）。
• 【可测性】每个验收点描述中至少包含“预置条件 + 操作 + 预期结果”三项。
• 【门禁公式化】门禁通行阈值已明确写出，且满足 KANO 属性权重规则。