适用场景：产品需求、项目需求、用户故事、迭代排期；不同方法各有适用场景，实际工作一般组合使用，不单独依赖某一种。
1. MoSCoW 法则（最经典，项目 / 产品通用）
把需求分成 4 类：
Must have（必须有）：不做项目就无法交付，核心底线，P0。
Should have（应该有）：重要，但没有也可以上线，P1。
Could have（可以有）：锦上添花，影响体验但不影响核心流程，P2。
Won’t have（暂不做）：本次版本不实现，放入后续 backlog，P3。
✅优点：简单易懂，适合对内对外沟通，敏捷项目很常用 ❌缺点：缺少量化，容易大量需求都标 Must have，需要人为约束
2. RICE 评分模型（量化打分，产品经理常用）
对每个需求计算分数：
RICE = (Reach × Impact × Confidence) / Effort
Reach（覆盖人数）：会影响多少用户
Impact（影响程度）：对用户 / 业务价值，1‑5 分
Confidence（置信度）：数据确定性百分比
Effort（投入成本）：人天 / 人周，完成这个需求需要多少工作量
分数越高优先级越高。
✅优点：量化，减少主观拍脑袋，适合大量需求对比 ❌缺点：打分比较耗时，需要数据支撑；评估 effort 容易不准
3. KANO 模型（从用户体验角度分类）
把需求分为 5 类：
基本型需求（必备）：用户认为理所应当，不做会差评，做了不会加分 → 高优先级
期望型需求（一元）：做得越好用户越满意，功能越强评分越高 → 中等‑高优先级
兴奋型需求（魅力）：不做用户没意见，做了会惊喜，超出预期 → 资源富余再做
无差异需求：做不做都不影响用户感受 → 不做
反向需求：做了反而用户反感 → 坚决不做
✅优点：站在用户体验视角，区分 “必须” 和 “惊喜” ❌缺点：不考虑研发成本，不能直接用于排期，要结合成本一起看
4. 价值‑成本矩阵（二维四象限，技术 & 产品对齐）
两个维度：业务价值（纵轴） vs 实现成本（横轴），划分 4 个象限：
高价值、低成本：优先做（黄金区）
高价值、高成本：重点规划，拆分、分期实现
低价值、低成本：有空顺带做
低价值、高成本：尽量不做，直接砍掉
✅优点：研发、产品、业务方很容易达成共识，可视化强 ❌缺点：价值和成本评估依赖经验，主观成分较大
5. 优先级矩阵（紧急‑重要矩阵 / 艾森豪威尔矩阵）
维度：重要（业务 / 用户价值） vs 紧急（时间压力）
重要且紧急：立刻做
重要不紧急：计划排期做（重点投入）
紧急不重要：尽量授权、简化或者合并
不紧急不重要：延后或砍掉
✅优点：适合业务突发需求、外部倒逼需求 ❌缺点：容易被 “紧急” 绑架，忽视长期重要需求
6. 商业价值排序法（面向业务、ToB 项目）
核心指标：收益、风险、合规。
收益：增收、降本、留存提升
风险：合规风险、安全风险、客户流失风险
约束：上线时间节点、政策要求
合规 / 风险类需求往往直接拉高优先级，哪怕收益不大。
✅优点：适合政企、ToB 项目，合规强约束场景 ❌缺点：用户体验权重低
7. 故事点加权 / 投票法（敏捷团队）
群体投票：产品、研发、测试共同投票打分
先评估业务价值，再评估工作量，输出排序 适合小团队，快速头脑风暴。 ❌缺点：容易受强势角色影响。
实操落地建议（组合工作流）
先用 MoSCoW 做第一轮粗筛，过滤掉本次不做的需求；
用 价值‑成本矩阵 做二维评估，识别黄金需求；
重要项目可以叠加 RICE 量化打分；
引入 KANO 校验：保障基本型需求优先，不要把大量资源投入魅力型需求；
叠加紧急‑重要处理突发、合规需求；
输出 P0/P1/P2/P3 优先级，同时记录：价值说明、评估依据、工作量。
避坑提醒：
P0 不要泛滥，一个迭代 P0 控制少量；
优先级不是一成不变，迭代要定期重评估；
优先级不等于排期，还要考虑依赖关系、资源瓶颈。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢