4 需求优先级排序：MoSCoW法、Kano模型、价值-成本矩阵、四象限优先级
需求优先级排序是PRD到原型映射中的关键决策环节。面对用户访谈收集到的“愿望清单”、业务方提出的“紧急需求”以及团队内部的“技术改进”，你需要一套可复用的判断框架，确保有限的研发资源投入在最能创造业务价值和用户满意度的需求上。本章将结合用户场景、业务问题和验收标准，讲解四种主流优先级排序方法，并给出可落地的交付物模板。
4.1 为什么需要优先级排序？
在真实的工作场景中，产品经理经常面临以下业务问题：
- 用户访谈中收集了50个需求，但下个迭代只能交付10个。
- 业务方说“这个功能是最高优先级”，但所有业务方都这么说。
- 团队花了两周做了某个功能，上线后发现用户根本不使用。
优先级排序的目标不是“选出一个最重要的”，而是在约束条件下产出最大价值组合。你需要从用户场景出发，结合商业价值、开发成本和风险，得出可量化的排序结果，并在PRD中清晰表达。
4.2 四种优先级排序方法精讲
4.2.1 MoSCoW法
MoSCoW法将需求分为四类：Must have（必须有）、Should have（应该有）、Could have（可以有）、Won't have（不会有）。它适用于时间固定的迭代场景，例如版本发布前必须完成的合规需求划为M，提升体验的优化需求划为S/C。
| 类别 | 含义 | 示例（在线教育平台） |
|---|---|---|
| Must have | 不实现则项目失败 | 用户登录、课程播放、支付 |
| Should have | 重要但可延迟 | 学习进度同步、考试自动判分 |
| Could have | 锦上添花 | 课程笔记导出、学习排行榜 |
| Won't have | 本次不做 | 社交互动、直播连麦 |
验收标准：每个需求必须清晰标注MoSCoW类别，并在PRD中用标签注明。例如：[M] 用户注销账号。
4.2.2 Kano模型
Kano模型从用户满意度角度划分需求：基本型需求（不做用户会非常不满）、期望型需求（做得越好用户越满意）、兴奋型需求（超出预期带来惊喜）、无差异需求（做了没影响）、反向需求（做了反而负面影响）。该模型适合用户调研驱动的场景，需要结合用户访谈和问卷验证。
| 类型 | 用户心理 | PRD中的处理方式 |
|---|---|---|
| 基本型 | 理所当然，不做差评 | 必须纳入Must have，不能砍 |
| 期望型 | 线性价值，做多好评 | 用价值-成本矩阵进一步排序 |
| 兴奋型 | 意料之外，口碑引爆 | 低成本可尝试，高成本慎重 |
4.2.3 价值-成本矩阵
将需求按业务价值和实现成本两个维度放入四象限：高价值-低成本（优先做）、高价值-高成本（策略性投入）、低价值-低成本（可以尝试）、低价值-高成本（坚决不做）。这种方法需要你为每个需求估算量化价值（如预计带来XX万DAU或XX%转化提升）和成本（开发人天）。
交付物模板：
优先级四象限表格（用于PRD附录）
| 需求名称 | 业务价值（1-5） | 成本（人天） | 象限 | 排序 |
|----------|----------------|-------------|------|------|
| 自助退款 | 5 | 3 | HV-LC | 1 |
| 个性化推荐 | 4 | 15 | HV-HC | 2 |
| 主题换肤 | 1 | 2 | LV-LC | 3 |
| 用户证书生成 | 1 | 8 | LV-HC | 4 |4.2.4 四象限优先级综合法
在实际项目中，你往往需要综合使用上述方法。四象限优先级法将用户满意度影响和商业价值作为两个轴，形成一个2×2矩阵。结合Kano模型和MoSCoW，你可以得到更细致的排序依据：
- 第一象限（高商业价值+高满意度影响）：P0 必须做，通常是基本型+期望型中价值高的需求。
- 第二象限（低商业价值+高满意度影响）：P1 应该做，可能是兴奋型低成本需求。
- 第三象限（低商业价值+低满意度影响）：P3 可以放弃或推后。
- 第四象限（高商业价值+低满意度影响）：P2 可以做，但需验证是否伪需求。
4.3 方法对比与选择指南
| 方法 | 适用场景 | 输入数据 | 输出结果 |
|---|---|---|---|
| MoSCoW法 | 固定时间/资源的版本规划 | 需求列表、业务约束 | Must/Should/Could/Won't 分类 |
| Kano模型 | 用户满意度驱动的差异化竞争 | 用户访谈、双因素问卷 | 基本/期望/兴奋/无差异分类 |
| 价值-成本矩阵 | 需要数据化决策的排期 | 价值估算、成本估算 | 四象限排序+ROI权重 |
| 四象限优先级 | 融合多维度信息的终局决策 | 商业价值、用户满意度 | P0-P3 优先级标签 |
4.4 从用户场景到排序结果的完整示例
假设你在做一款在线协作白板工具，通过用户访谈收集到4个需求：
- 需求A：多人实时光标（用户说“没有这个根本没法协作”） → Kano基本型 → MoSCoW Must
- 需求B：自动保存历史版本（用户说“有就方便很多”） → Kano期望型 → 价值高、成本中 → 第一象限 P0
- 需求C：画布星空主题（用户说“哇好酷”） → Kano兴奋型 → 价值低、成本低 → 第二象限 P1
- 需求D：导出为PDF时加水印（业务方要求） → 商业价值高、满意度低（用户反感） → 第四象限 P2，需权衡
你将以上分析写入PRD的“需求优先级汇总”章节，并附上优先级标记和决策理由，方便设计、开发、测试对齐。
4.5 验证与验收标准
完成优先级排序后，你需要设定验收标准来确保排序被正确执行：
- 需求必须带有优先级标签：每个PRD需求条目都应有P0/P1/P2/P3或MoSCoW标记，否则驳回。
- 排期覆盖率：当前迭代P0需求完成率100%，P1需求完成率不低于80%。
- 变更管理：任何优先级变更必须经过需求评审会，并提供影响分析。
- 需求清单（Excel或PRD内嵌表格）包含：需求描述、优先级标注、排序方法来源、价值/成本评分（可选）
- 优先级决策日志：记录每个高优需求背后的业务理由和用户访谈原文引用
- 排序结果可视化图表（见下方SVG）
4.6 本章交付物模板清单
完成本章学习后，你应该能够在PRD中输出以下内容：
- 优先级映射表：将需求列表转化为带优先级的表格，标注使用的方法（例如“[MoSCoW-M] [Kano-基本] [P0]”）
- 排序决策说明：对每个P0和P1需求，写一段简短的业务理由，引用用户访谈原文或数据
- 迭代计划草稿：基于优先级和成本估算，给出当前迭代和未来2个迭代的初步排期
- 风险备忘：记录那些被降级为Won't have的需求，并说明后续评估条件
记住：优先级的本质是“在有限资源下，放弃什么”。好的PRD不仅仅是罗列需求，还应该让读者一眼看出团队的价值取向。