第4章 需求分类与优先级排序：Kano模型、MoSCoW法、权重打分表

需求分类与优先级排序是从“需求池”走向“路线图”的关键枢纽。单一方法难以兼顾用户感知、项目约束与量化比较，因此本章将 Kano 模型（定性分类）、MoSCoW 法（分层博弈）和 权重打分表（定量排序）整合为一条可执行的 SOP 流程，使硬件团队在面对大量需求时能快速达成共识、输出可追溯的优先级列表。

4.1 适用场景

• 需求池膨胀：原始需求超过 30 条，无法直接放入路线图，需要系统性压缩与排序。
• 跨职能意见冲突：市场、研发、测试、供应链对“先做什么”各执一词，缺少统一框架。
• 资源严重受限：硬件开发周期固定、BOM 成本敏感、人力不足，必须精确取舍。
• 用户感知模糊：不清楚哪些功能是“必须做”的底线，哪些是“做了会惊喜”的加分项。
• 路线图评审前准备：在月度/季度路线图评审会之前，需要一份经过严格排序的需求优先级清单。

4.2 前置条件

• 已维护的 需求池（至少包含需求 ID、名称、来源、简要描述、提出时间）。
• 用户画像/场景描述：每个需求关联的目标用户和使用场景（参考第 3 章输出）。
• 跨职能评审团队：至少包含产品经理（主持）、系统架构师、硬件研发代表、测试负责人、供应链代表。
• Kano 问卷数据（可选但推荐）：针对 10–20 个核心需求提前收集用户正反评价。
• 工具准备：电子表格 / 权重打分模板 / 协作白板（在线或物理）。

4.3 操作步骤

1. 需求条目整理与初始清洗
   • 从需求池中提取所有待排序需求，去重、合并语义重复项。
   • 对描述模糊的需求，打回提出人补充用户场景和验收标准。
   • 输出：待分类需求清单（建议不超过 25 条，超过则先做一轮粗筛）。
2. Kano 模型分类
   • 将待分类需求制成 Kano 双向问卷（正向：具备该功能感觉如何？反向：不具备该功能感觉如何？）。
   • 回收问卷后对照 Kano 评价表（如下），将每个需求归入：
     基本型（M）、期望型（O）、兴奋型（A）、无差异型（I）、反向型（R）。
   • 保留 M、O、A 三类需求进入下一阶段；I 和 R 需求打回或放入“观察区”。
   • 输出：Kano 分类后的需求子集（标注 M/O/A）。
3. MoSCoW 法分层讨论
   • 组织跨职能会议，对 Kano 筛选后的需求逐条讨论。
   • 按以下规则分层：
     • Must have：缺少则产品无法上市或核心用户流失（通常是 Kano 基本型）。
     • Should have：重要但可延迟到下一迭代（通常是 Kano 期望型）。
     • Could have：有则更好，但无实质影响（通常是 Kano 兴奋型中的低分项）。
     • Won‘t have：本次版本明确不纳入，记录在案供后续参考。
   • 团队举手表决或使用 dot-voting 解决分歧，产品经理拥有最终裁定权。
   • 输出：MoSCoW 分层矩阵（四象限列表）。
4. 优先级维度定义与权重分配
   • 结合硬件项目特点，确定 3–5 个评估维度，例如：
     • 商业价值（收入 / 战略对齐）
     • 用户影响力（覆盖用户数 / 使用频率）
     • 实现成本（硬件 BOM / 研发人月 / 模具投入）
     • 技术风险（新器件 / 新算法 / 认证难度）
   • 使用 AHP 或团队投票为每个维度分配权重，所有权重之和为 1.0。
   • 输出：权重分配表（维度 + 权重 + 评分标准说明）。
5. 逐项打分与加权计算
   • 团队成员依据评分标准（1–5 或 1–10 分制）对每个需求逐维度打分。
   • 计算加权得分：综合得分 = Σ (维度得分 × 维度权重)。
   • 成本类、风险类维度取负向或倒数处理，确保得分越高优先级越高。
   • 输出：需求加权得分明细表（含每个需求的维度分、权重、综合分）。
6. 综合排序与优先级输出
   • 按综合得分从高到低排列需求。
   • 结合 MoSCoW 分层进行人工校验：Must have 需求不得落在后 50%；如有冲突，以 MoSCoW 为硬约束，调整权重或重新打分。
   • 将排序结果划分为三档：P0（核心必做）、P1（尽力而为）、P2（机会主义）。
   • 输出：优先级排序列表（含 P0/P1/P2 标记、综合得分、Kano 分类、MoSCoW 层级）。

4.4 输入输出物

4.5 责任边界

• 产品经理：主持全流程，维护需求池，输出最终优先级列表，对排序结果负责。
• 系统架构师：评估技术风险维度，对“实现成本”和“技术风险”打分负责。
• 硬件研发代表：提供硬件 BOM 变更量、开发人月估算，参与成本和风险评分。
• 测试负责人：提供测试覆盖难度、认证周期等输入，参与风险评分。
• 供应链代表：提供物料交期、备货周期、模具周期等约束信息。
• 市场/销售代表（可选）：补充商业价值和用户影响力维度的输入。

4.6 记录材料

• Kano 分类记录表：需求 ID、需求名称、正向分数、反向分数、Kano 类别（M/O/A/I/R）。
• MoSCoW 分层讨论纪要：记录分层决策依据、争议点及最终裁定人。
• 权重分配表：维度名称、权重值、评分标准（1–N 分的描述锚点）。
• 需求加权得分明细表：需求 ID、各维度原始分、加权分、综合得分、排序序号。
• 优先级排序列表：P0/P1/P2 标记、Kano 类别、MoSCoW 层级、综合得分、备注。

4.7 异常处理

4.8 验收标准

• ✅ 每个进入排序的需求都有明确的 Kano 分类（M/O/A），无遗漏。
• ✅ MoSCoW 分层中 Must have 需求不超过总需求的 30%，且全部属于 Kano 基本型或期望型。
• ✅ 权重分配表包含至少 3 个维度，权重总和为 1.0，且每个维度有 书面评分标准。
• ✅ 加权得分明细表中每个需求都有完整的原始分和综合得分，无空值。
• ✅ 最终优先级列表已标记 P0/P1/P2，且 P0 需求与 Must have 一一对应（允许 P0 包含少量 Should have）。
• ✅ 所有记录材料（分类表、分层纪要、权重表、打分表、优先级表）已归档至共享文档，团队可追溯。