4. 需求优先级排序技术:MoSCoW、Kano模型、加权评分法
需求优先级排序是将项目范围从“全部想要”收敛到“必须交付”的核心决策过程。本流程 SOP 系统讲解三种主流排序技术:MoSCoW 法(快速分级)、Kano 模型(用户满意度驱动)和加权评分法(多维度量化决策)。团队可根据项目阶段、数据可得性与决策层级灵活选用或组合使用。
4.1 适用场景
三种技术各自擅长不同的决策环境,选择不当将导致排序结果偏离实际项目目标。
| 技术 | 适用场景 | 不适用场景 |
|---|---|---|
| MoSCoW 法 | 敏捷迭代、MVP 定义、范围基线确立、短期冲刺规划 | 需求间无明显价值差异时强行分类会导致主观臆断 |
| Kano 模型 | 产品功能规划、用户满意度提升、创新功能筛选 | 缺乏用户调研数据时分类结果不可靠;纯技术型需求难以映射 |
| 加权评分法 | 跨部门资源争夺、预算分配、投资回报论证 | 评分维度不统一或权重设置随意时产生虚假精度 |
4.2 前置条件
- MoSCoW 法:需求列表已完成初步分类(功能/非功能、业务/技术);干系人已明确项目约束(时间、成本、质量)。
- Kano 模型:已完成至少一轮用户问卷或深度访谈,覆盖至少 30 份有效样本;需求条目独立且用户可理解。
- 加权评分法:已确定评分维度(如业务价值、实现成本、风险、ROI);各维度已达成共识权重百分比。
- 通用:需求已编号并录入管理工具(如 Jira、Excel 列表);干系人代表已确认参与评审。
4.3 操作步骤
MoSCoW 法(适用快速分级)
- M - Must Have(必须):不满足则项目失败,是最小可行产品不可或缺的需求。
- S - Should Have(应该有):非常重要但暂时缺失不会导致项目取消,可延迟到下一版本。
- C - Could Have(可以有):有价值的增强功能,资源富余时实现。
- W - Won't Have(不会做):明确排除在当前版本之外,不承诺未来。
- 分组校验:确保 M 类需求比例不超过总工作量的 60%,否则需要重新协商范围。
Kano 模型(按满意度分类)
- 编制问卷:针对每个需求编写“具备/不具备”两种情境下的功能反应选项(喜欢/当然如此/无所谓/可以忍受/不喜欢)。
- 聚类分析:根据问卷结果将需求归入五类:
- 基本属性:不实现则用户极度不满(如:登录、支付安全)。
- 期望属性:实现程度与满意度正相关(如:响应速度)。
- 魅力属性:不实现无不满,实现则大幅提升满意度(如:个性化推荐)。
- 无差异属性:实现与否不影响满意度(如:界面背景动效)。
- 反向属性:实现反而引起不满(如:自动弹出广告)。
- 排序优先级:基本属性 > 期望属性 > 魅力属性;无差异属性和反向属性不纳入当前迭代。
加权评分法(多维度量化)
- 确定维度清单:至少包含业务价值、实现复杂度、风险等级、用户覆盖度、合规要求,共 5 个维度。
- 设定权重:总权重 100%,例如业务价值 40%、实现复杂度 -20%(反向)、风险 15%、用户覆盖度 15%、合规 10%。
- 逐项打分:每个需求按 1-5 分对每个维度评分(1 最低,5 最高)。
- 计算总分:
总分 = Σ(维度得分 × 权重百分比),反向维度需取负分或调整公式。 - 排序输出:总分从高到低排序,取前 N 个需求进入迭代。
4.4 输入输出物
| 技术 | 输入 | 输出 |
|---|---|---|
| MoSCoW | 需求列表(条目化)、项目约束(时间/成本/质量) | M/S/C/W 四类清单 |
| Kano | 需求列表、用户问卷数据(≥30份) | 需求属性分类表、优先级建议 |
| 加权评分法 | 需求列表、维度权重矩阵、评分标准 | 加权排序表、Top-N 推荐清单 |
4.5 责任边界
- 产品经理 / 需求分析师:准备需求条目,组织排序会议,记录最终优先级决策。
- 用户研究员(仅 Kano):设计问卷,执行用户调研,完成属性分类统计。
- 开发组长 / 架构师:评估实现复杂度和风险,提供技术维度评分(加权评分法)。
- 关键干系人 / 业务负责人:参与排序会议,确认 M 类及高优先级需求,承担范围决策责任。
- Scrum Master / 项目经理:控制排序时长,保障流程合规,推动冲突协商。
4.6 记录材料
每项需求在完成排序后,必须记录以下字段并归档至需求管理工具:
需求编号: REQ-0042
需求标题: 用户注册手机号验证
排序技术: MoSCoW + 加权评分法
MoSCoW 分类: M (Must Have)
Kano 属性: 基本属性
加权评分: 业务价值 5, 复杂度 2(反向), 风险 3, 覆盖度 5, 合规 5
加权总分: 5×0.4 + 2×(-0.2) + 3×0.15 + 5×0.15 + 5×0.1 = 3.25
决策人: 张颖 (产品总监)
评审日期: 2025-04-10
4.7 异常处理
| 异常场景 | 处理措施 |
|---|---|
| M 类需求超过工作量 60% | 重新协商项目约束(延长工期/增加资源/缩减质量要求),否则必须将部分 M 降级为 S。 |
| Kano 调研样本量不足 30 | 改为加权评分法补充分类;或等待补充调研完成后再做优先级决策。 |
| 加权评分维度权重分歧严重 | 强制使用“AHP 层次分析法”或“匿名打分+均值”消除人为偏好,达成基线权重。 |
| 同一需求跨团队分类结果矛盾 | 升级至项目指导委员会(PSC)仲裁,以业务价值最高目标为最终依据。 |
| 排序结果被干系人频繁要求重排 | 锁定排序冻结期(如当前 Sprint 内禁止重排),任何变更走正式变更控制流程。 |
4.8 验收标准
- 完整性:全量需求列表(不含已删除)已分配至「MoSCoW 分类」或「Kano 属性」或「加权总分」之一。
- 正确性:M 类需求与项目基线 / MVP 边界一致;Kano 类属性与实际用户调研统计匹配;加权评分无计算错误(抽查率 ≥10%)。
- 可追溯:每一排序结论均关联到原始记录(问卷数据、评分矩阵、评审会议纪要)。
- 共识机制:排序结果已通过团队评审会议确认,且记录中明确记录了分歧与最终决策依据。
- 工具落地:排序后的需求优先级队列已在管理工具(如 Jira / TAPD / Excel)中更新,并可导出为附录文档。
实战建议:在同一个项目中可以“组合使用”三种技术。例如:先用 Kano 模型筛选出高用户价值的需求,再用加权评分法细化排名,最后用 MoSCoW 切分版本边界。