功能优先级排序法
# 功能优先级排序法
RICE/ICE评分法、MoSCoW、机会成本——有限的资源做最对的事
# 一、优先级排序的本质：不是排"做什么"，是排"不做什么"
一个典型的迭代启动场景：产品经理拿着 15 个需求来找你，运营那边又加了 5 个，技术债还欠着 8 个。你只有 5 个人、10 个工作日。
优先级排序不是挑出"最好的 3 个"——是有勇气放弃另外 12 个。
不做某事的机会成本 = 如果我用同样的时间做另一件事，能产生多大价值？
你选择了做 A，就意味着放弃了 B、C、D……它们中最有价值的那一个，才是你真正的成本。
2
3
对工程师来说，这意味着：你花 3 天重构一个没人抱怨的模块，可能意味着一个用户呼声很高的功能推迟上线 3 天。优先级框架就是帮你量化这种权衡。
# 二、RICE 评分法：四维度量化
RICE 是 Intercom 内部推广开的优先级模型，用四个维度给每个需求打分：
RICE 得分 = (Reach × Impact × Confidence) / Effort
覆盖面 影响力 信心度 投入成本
2
# 2.1 四个维度详解
| 维度 | 含义 | 打分方式 | 例子 |
|---|---|---|---|
| Reach（覆盖面） | 这个功能影响多少人？ | 一段时间内的用户数/事件数 | "每月 5000 个运营人员会用到" → 5000 |
| Impact（影响力） | 对用户目标的影响有多大？ | 3=巨大, 2=高, 1=中, 0.5=低, 0.25=极低 | "批量导入让效率提升 80%" → 3 |
| Confidence（信心度） | 你的判断有多靠谱？ | 100%=有数据支撑, 80%=有用户反馈, 50%=直觉 | "有 20 个用户工单" → 80% |
| Effort（投入成本） | 需要多少人·月？ | 实际估算，单位"人·月" | "后端+前端各 1 人，1 周" → 0.5 |
# 2.2 一个真实打分过程
场景：后台管理系统的下个迭代，候选需求如下——
需求 A：批量导入 Excel 更新商品价格
Reach: 200 个运营/月
Impact: 3（目前单人逐一修改，效率极低）
Confidence: 80%（20+ 运营工单反复提到）
Effort: 0.5 人·月
→ RICE = (200 × 3 × 0.8) / 0.5 = 960
需求 B：后台页面支持暗黑模式
Reach: 5000 用户/月
Impact: 0.25（锦上添花，没有也行）
Confidence: 50%（没人提过，纯猜测）
Effort: 1 人·月
→ RICE = (5000 × 0.25 × 0.5) / 1 = 625
需求 C：商品搜索从 MySQL 迁移到 Elasticsearch
Reach: 10000 用户/月
Impact: 2（搜索更快，转化会高）
Confidence: 60%（竞品都有，但没数据证明慢导致流失）
Effort: 2 人·月
→ RICE = (10000 × 2 × 0.6) / 2 = 6000
需求 D：订单列表增加"批量退款"功能
Reach: 50 个客服/月
Impact: 3（大促期间每天退款 300 单，目前一单一单退）
Confidence: 100%（客服主管明确提的需求，有录屏）
Effort: 0.3 人·月
→ RICE = (50 × 3 × 1.0) / 0.3 = 500
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
排序结果：C > A > D > B
你可能会说："但 C 和 A、D 是不同类型的需求啊，能直接比吗？"——能。RICE 不区分需求类型，它就是逼你把不同类型的需求放到同一个量化框架里比。
# 2.3 RICE 的陷阱与修正
陷阱 1：Reach 压倒一切。如果只看 Reach，toC 的小优化（100 万用户 × 0.25 Impact）会永远排在 toB 的大痛点（50 个运营 × 3 Impact）前面。
修正：限制 Reach 量级——用对数分级而不是线性值。比如：
- 1-100 人 → 1
- 101-1000 人 → 2
- 1001-10000 人 → 3
- 10000+ → 4
陷阱 2：Confidence 太高或太低。工程师对自己做的技术需求总是打 100%（"我确定这能提升性能"），但对产品需求被问到"用户真的需要吗"时只敢打 50%。
修正：Confidence 必须附带证据说明。100% → 有 A/B 测试数据；80% → 有用户访谈；50% → 有竞品参考。低于 50% 的需求默认不打分——说明你还不够了解，先去调研。
陷阱 3：Effort 被严重低估。工程师估算"2 天"往往只算了写代码的时间，没算联调、测试、上线、文档。
修正：永远用"人·周"而不是"人·天"，并且估算后乘以 1.5 倍作为缓冲。
# 三、ICE 评分法：RICE 的极简版
ICE 是 GrowthHackers 创始人 Sean Ellis 提出的——只有三个维度，适合快速初筛：
ICE 得分 = (Impact × Confidence × Ease) / 3
影响力 信心度 实现容易度
2
# 3.1 什么时候用 ICE 而不是 RICE
| 场景 | 推荐 |
|---|---|
| 需求超过 20 个，需要快速初筛 | ICE——每个需求 30 秒打分 |
| 候选需求 5-10 个，要精细比较 | RICE——每个需求 3 分钟打分 |
| 有一个明确的用户量数据 | RICE——Reach 是你最硬的数据 |
| 需求都是内部工具或小范围使用 | ICE——Reach 意义不大 |
# 3.2 ICE 打分表格（快速版）
拿一支笔，一个表格，30 秒一个：
| 需求 | Impact(1-5) | Confidence(1-5) | Ease(1-5) | ICE得分 | 排序 |
|---|---|---|---|---|---|
| 批量导入改价 | 5 | 4 | 4 | 5×4×4÷3=26.7 | 1 |
| 暗黑模式 | 1 | 2 | 2 | 1×2×2÷3=1.3 | 5 |
| ES 迁移 | 4 | 3 | 2 | 4×3×2÷3=8.0 | 3 |
| 批量退款 | 5 | 5 | 5 | 5×5×5÷3=41.7 | —— |
你会发现一个有趣的事：批量退款 ICE 得分最高——但它可能根本不在你最初的候选列表里。这就是量化框架的价值：它暴露直觉的盲区。
# 3.3 Ease 的"工程师专用打分法"
Ease 是 ICE 里工程师最有话语权的维度。你的打分直接决定一个需求能不能做。
Ease = 5 → 已有轮子。对接现成 API / 开源库即可，1 天以内。
Ease = 4 → 改动小。只改前端或只改后端，不影响核心逻辑，2-3 天。
Ease = 3 → 常规开发。前后端都要改，但逻辑清晰，1 周。
Ease = 2 → 涉及多系统。跨服务调用、数据迁移、权限改造，2-3 周。
Ease = 1 → 伤筋动骨。改核心数据模型、改架构、影响已有功能，1 月以上。
2
3
4
5
工程师很容易把 Ease 打到 1——"这个要做很多事"——但产品经理听着就是"你不愿意做"。更好的说法："Ease 是 2，主要卡在权限改造这块——如果我们先不做细粒度权限，做一个'仅管理员可用'的版本，Ease 能到 4，3 天就能上。"
# 四、MoSCoW 法：不是打分，是分类
MoSCoW 是另一种思路——不给需求打分，而是把它们分到四个桶里：
M - Must have（必须有） ← 不上线这个版本就没意义
S - Should have（应该有） ← 重要但可以下个版本补
C - Could have（可以有） ← 锦上添花，有时间就做
W - Won't have（这次不做） ← 明确了不做——很重要！
2
3
4
# 4.1 四个桶的判断标准
| 分类 | 判断标准 | 技术债等价判断 |
|---|---|---|
| Must | "没有这个功能，用户完成不了核心任务" | "不修这个 bug，P99 延迟 > 5s" |
| Should | "有更好，没有也能用变通方案绕过去" | "代码重复 3 处，抽公共逻辑" |
| Could | "做了用户会开心，但不会因此留下或离开" | "把 for 循环改成 Stream API" |
| Won't | "这个版本明确不做——不要花时间想它" | "把整个模块用 Kotlin 重写" |
# 4.2 MoSCoW 的最大价值：明确"不做"
大多数团队做优先级，会讨论一堆"做什么"，但没人敢说"这个不做"。结果就是每个需求都在列表上，最后谁催得急就做谁——紧急度替代了优先级。
MoSCoW 强制你给每个需求一个标签，包括 Won't。这个标签的意义在于：这个版本不讨论它，不设计它，不要为它留扩展点。
❌ 常见错误：
"这个功能这个版本不做，但我先预留一个字段，以后好扩展。"
→ 你在为一个 Won't 的需求写代码。这违背了优先级排序的原则。
✅ 正确做法：
"这个功能明确 Won't。如果以后要做，到时候再加字段——加字段的成本远低于现在过度设计 + 维护无用代码的成本。"
2
3
4
5
6
# 4.3 配额原则
MoSCoW 没有硬性配额，但没有约束的分类等于没分类。推荐规则：
Must ≤ 60%（超了这个比例说明你没有在做取舍）
Should ≈ 20%
Could ≈ 10%
Won't ≥ 10%（如果 Won't 比例是 0，说明你在逃避说"不"）
2
3
4
如果一个迭代里 90% 的需求都是 Must——你得诚实地问一句：是这些真的都不可或缺，还是我们不敢承认"用户其实不需要这么多"？
# 4.4 MoSCoW + RICE 组合打法
单独用 MoSCoW，分类很主观——谁都把自己提的需求往 Must 里塞。组合用：
第一步：RICE/ICE 打分 → 得到一个量化排序
第二步：MoSCoW 分类 → 把前 N 个放 Must，中间放 Should，尾部放 Won't
第三步：检查配额 → Must 是否超过 60%？把最弱的 1-2 个挪到 Should
2
3
# 五、机会成本：你最稀缺的不是时间，是注意力
# 5.1 机会成本的直观理解
你手里有 10 个需求，资源只够做 3 个。
选了 A，放弃了 B-J。B-J 中 RICE 得分最高的那个（假设是 C，得分 800），
就是你选择 A 的机会成本。
如果 A 的得分只有 500，但你选了 A——
你不是在"做 A"，你是在"花 800 分的代价做一件 500 分的事"。
2
3
4
5
6
7
# 5.2 工程师最常犯的机会成本错误
错误 1：完美主义重构
"这个模块代码太乱了，我想重构一下，大概 2 周。"
→ 这 2 周的机会成本是什么？两周可以上线 2-3 个用户可见的功能。那些功能有没有数据支撑？
如果重构能让后续开发效率提升 30%，并且这个模块还在活跃迭代——做。 如果这个模块一年没改过了，而且未来一年也不会有大改动——做这件事的机会成本太高。
错误 2：过度预防性设计
"我先把架构设计得灵活一点，以后加功能快。"
→ 机会成本：你花了 3 天预留扩展点，但那些"以后可能要的功能"还在 Won't 里——可能永远不会做。这 3 天本来可以做一个用户现在就需要的功能。
原则：为已知需求设计，不为想象中的需求设计。
错误 3：被"紧急"劫持
客服群里有人反馈了一个 bug，你放下手里的迭代任务去修——花了半天。
→ 机会成本：你手里的迭代任务延迟半天。这个 bug 影响面多大？比你手里的迭代任务更大吗？如果不修这个 bug，今天会有多少用户受影响？
不是说紧急问题不该修——而是每一次切换都要意识到机会成本。 如果你一天切换 4 次上下文，实际有效产出可能不到 4 小时。
# 5.3 机会成本自查清单
每次决定"做什么"时，花 30 秒问自己：
□ 这件事如果不做，最坏的结果是什么？
□ 同样的时间，我能做的"第二选项"是什么？它的价值有多大？
□ 这个决定是可逆的还是不可逆的？（可逆的决定，快速决定；不可逆的，谨慎分析）
□ 一周后回头看，我还会觉得这个优先级是对的吗？
2
3
4
# 六、综合案例：一个迭代的完整排序过程
场景：电商后台，5 人团队，2 周迭代。候选需求：
| # | 需求 | 来源 |
|---|---|---|
| 1 | 批量导入改价 | 运营工单（25 条） |
| 2 | 订单列表加"批量退款" | 客服主管 |
| 3 | 搜索迁移 ES | 技术规划 |
| 4 | 优惠券使用数据看板 | 运营总监 |
| 5 | 后台暗黑模式 | 前端自己想的 |
| 6 | 商品详情页加载速度优化 | 性能监控数据 |
| 7 | 修复支付回调丢单 bug | 线上事故 |
# Step 1：RICE 量化
| 需求 | R | I | C | E | RICE |
|---|---|---|---|---|---|
| 批量改价 | 200 | 3 | 80% | 0.5 | 960 |
| 批量退款 | 50 | 3 | 100% | 0.3 | 500 |
| ES 迁移 | 10000 | 2 | 60% | 2 | 6000 |
| 数据看板 | 10(总监+团队) | 2 | 80% | 1 | 16 |
| 暗黑模式 | 5000 | 0.25 | 50% | 1 | 625 |
| 性能优化 | 10000 | 2 | 100% | 0.5 | 40000 |
| 支付 bug | 300/天 | 3 | 100% | 0.1 | 9000 |
# Step 2：综合判断
光看 RICE 得分：性能优化(40000) > 支付 bug(9000) > ES 迁移(6000) > 批量改价(960) > 暗黑模式(625) > 批量退款(500) > 数据看板(16)
但这里要结合 需求性质 做修正：
- 支付 bug（P0 事故）：不在 RICE 框架里竞争——它不需要"排序"，是"必要条件"。先修，Effort 才 0.1 人·月，半天搞定。
- 性能优化（最高分）：Confidence 100% 是因为有真实数据，值得做。但 0.5 人·月，一个人做一周即可。
- ES 迁移：6000 分很高，但 Effort 要 2 人·月——占掉你团队 40% 的产能。你真的确定搜索慢是用户流失主因吗？还是先加个 loading + 骨架屏（0.2 人·月），看数据再决定？
# Step 3：MoSCoW + 配额
Must：
1. 支付回调 bug Effort 0.1 → 半天，先修
2. 性能优化（loading+骨架屏） Effort 0.2 → 1人×1周
3. 批量改价 Effort 0.5 → 1人×2.5天
Should：
4. 搜索优化（先做前端体验，再做 ES） Effort 0.2 + 2（拆两期）
5. 批量退款 Effort 0.3 → 1人×1.5天
Could：
6. 暗黑模式 Effort 1 → 下迭代
Won't：
7. 数据看板 Effort 1 → 先确认总监要的数据能不能直接用 BI 工具拉
2
3
4
5
6
7
8
9
10
11
12
13
14
最终执行计划（5 人 × 10 天 = 共 50 人·天）：
- 支付 bug：0.5 人·天 → 第一天修完上线
- 性能优化：1 人 × 5 天 → 前端骨架屏 + 图片懒加载
- 批量改价：1 人 × 2.5 天 → 后端 Excel 解析 + 前端上传页
- 批量退款：1 人 × 1.5 天 → 后端批量接口 + 前端勾选
- 搜索前端优化：1 人 × 2 天 → 骨架屏 + 防抖 + 结果高亮
- 剩余 1 人处理技术债和修小 bug
总共约 11.5 人·天规划内工作 + 剩余缓冲。没有超负荷，每个需求都有明确的 WHY。
# 七、小结
优先级排序不是数学题，是在信息不完备的情况下做取舍。四种工具解决四个层面的问题：
| 工具 | 解决什么问题 | 适合什么时候用 |
|---|---|---|
| RICE | 量化比较，尤其是跨类型需求 | 候选需求 5-15 个，有用户量数据 |
| ICE | 快速初筛，筛掉明显不值的 | 候选需求 20+，快速粗筛 |
| MoSCoW | 分类约束，强制说"不" | 迭代规划，控制 Must 占比 |
| 机会成本 | 时刻提醒"不做 A 就能做 B" | 日常决策，避免完美主义和过度设计 |
三条行动建议：
- 别一个人打分——RICE/ICE 让产品经理和工程师各自打一遍，分歧点就是讨论价值的地方
- Must 不超过 60%——如果超过了，说明你没在取舍。回顾前一篇文章的 Kano 模型，看看哪些其实只是"线性型"甚至"无差异型"
- 每一个 P0/P1 需求，写出它对应的机会成本——"做这个意味着 [某个需求] 推迟 X 天。确定吗？"
