职场工具箱之 MoSCoW：为什么你永远在做"都很重要"的事？

简短大纲

1. 先问一个扎心的问题：你是在排优先级，还是在当"需求海绵"？

周三下午两点，需求评审会。

产品经理打开一份 20 页的 PRD，里面列了 14 个需求。你心里已经在默算工时了——按现有人力，这个迭代最多做 6 个。

然后，表演开始了。

产品经理说："用户登录流程优化，这个是 P0，必须做。"

你点头。

运营同学说："活动页面改版也很重要，下周就要上线推广了。"

你点头。

老板路过，探头进来："对了，那个数据看板我上周提的，客户下周来参观，一定要有。"

你继续点头。

安全团队发来一封邮件："OAuth 鉴权那个漏洞修复，优先级最高。"

你还在点头。

会开完了。你看着自己的笔记本，上面写了 14 个需求，每一个后面都标着"重要""紧急""必须做"。

你心里清楚：14 个全做，等于 14 个全延期。

但你不敢说"不做"。因为每个需求背后都站着一个人，每个人都有自己的理由，每个理由听起来都很充分。

于是你做了一个最安全也最致命的决定：全接了，平均分配精力。

两周后，Sprint Review。

登录优化做了 60%，活动页面做了 40%，数据看板搭了个空壳，OAuth 修复还在 Code Review。没有一个完整交付。

老板问："怎么一个都没做完？"

你想说："因为你们每个人都说自己的最重要。"但你没说出口。

小白提示：PRD = Product Requirements Document，产品需求文档。Sprint = 敏捷开发中的一个迭代周期，通常 1-2 周。Sprint Review = 迭代结束时的成果展示会。

这个场景你熟不熟？我太熟了。我经历过不下十次。

后来我发现，问题不在于你不够努力，也不在于团队人手不够。问题在于：你从来没有真正排过优先级。

你以为你排了——你给每个需求标了 P0、P1、P2。但当 14 个需求里有 9 个是 P0 的时候，P0 就不再是优先级，它只是一个装饰品。

有没有一种方法，能在会上用 30 分钟把"都很重要"变成"先做哪个、后做哪个、这次不做哪个"？

有。它叫 MoSCoW。

2. What：MoSCoW 到底是什么？

一句话定义

MoSCoW 是一种需求优先级排序方法，由软件开发专家 Dai Clegg 在 1994 年为 Oracle UK 工作时首次提出，后来被广泛应用于 DSDM（Dynamic Systems Development Method，动态系统开发方法）框架中。

它把所有需求分成四个桶：

注意那个 "this time"。Won't 不是"永远不做"，是"这次不做"。这个区分非常关键——它让说"不"变得没那么刺耳。你不是在否定对方的需求，你是在说"这次资源不够，下次再排"。

小白提示：MoSCoW 这个名字里的小写 o 没有实际含义，纯粹是为了让缩写读起来像"莫斯科"（Moscow），好记。所以你看到有人写 MoSCoW，有人写 MOSCOW，都是同一个东西。

每个级别的判断标准——怎么分桶？

光看定义你可能觉得"这不就是换了个名字的 P0/P1/P2 吗？"不一样。MoSCoW 的核心区别在于：它逼你回答一个具体的问题，而不是凭感觉打标签。

Must have 的判断问题：如果没有这个功能，产品还能不能上线？

• 如果答案是"不能"——Must。
• 如果答案是"能上线，但体验差一点"——那不是 Must，是 Should。

举个例子：你在做一个电商 App。

• 用户能下单付款 → Must。没有这个，App 就是个商品展示页，不是电商。
• 订单列表支持按时间筛选 → Should。没有筛选功能，用户翻一翻也能找到订单，只是麻烦一点。
• 订单页面支持暗黑模式 → Could。好看，但不影响任何核心流程。
• 支持 AR 试穿 → Won't (this time)。很酷，但这个版本没资源做，放到 Q3 再说。

Should have 的判断问题：没有它，用户能不能用变通方案完成任务？

如果能——Should。如果不能——回去重新想想，它可能是 Must。

Could have 的判断问题：如果这个迭代时间不够，砍掉它，谁会真的受影响？

如果答案是"没人会注意到"——Could。

Won't have 的判断问题：我们是否愿意公开说"这次不做"？

如果你不敢公开说，说明你心里知道它可能是 Should 甚至 Must。Won't 的前提是团队达成共识：这个需求有价值，但不在这次的范围内。

MoSCoW vs P0/P1/P2：到底有什么不同？

你可能在想：我们团队已经在用 P0/P1/P2 了，MoSCoW 有什么新鲜的？

区别在这张表里：

一句话总结：P0/P1/P2 是温度计，告诉你"有多热"；MoSCoW 是分拣机，告诉你"先装哪个箱子"。

3. Why：为什么"都很重要"= 什么都不重要？

3.1 资源有限性——你的团队不是自助餐

这个道理谁都懂，但在需求评审会上，所有人都会选择性失忆。

每个需求方都觉得自己的需求"只需要两天"。但你把 14 个"只需要两天"加起来，就是 28 个人天。你的团队只有 4 个开发，一个迭代 10 个工作日，满打满算 40 个人天——还没算联调、测试、Code Review、线上部署和各种会议。

实际可用产能？大概 25 个人天。

28 > 25。数学不会骗人。

但在会上，没有人会主动说"那我的需求往后排吧"。因为每个人都在为自己的 KPI 负责，每个人都有自己的 deadline，每个人都觉得"别人的需求可以等，我的不行"。

这不是人品问题，是激励结构问题。

所以你需要一个机制，把"谁嗓门大谁赢"变成"按标准分桶"。MoSCoW 就是这个机制。

3.2 决策疲劳——你的大脑也有 CPU 限制

心理学家 Roy Baumeister 的研究表明：人每天能做出的高质量决策是有限的。每做一个决策，你的"决策电量"就少一格。当电量耗尽，你要么做出糟糕的决策，要么干脆不做决策——也就是"全接了"。

打个程序员能懂的比方：你的大脑就像一个单线程的 CPU。每个需求都是一个 task。当 task queue 里塞了 14 个 task，而且每个 task 的 priority 都是 HIGH，调度器就崩了——它不知道先执行哪个，于是开始 round-robin（轮询），每个 task 都分一点时间片，结果每个 task 都在 context switch（上下文切换）中浪费了大量开销，没有一个能跑完。

MoSCoW 的作用就是给你的调度器装一个优先级队列：Must 先跑，Should 排队，Could 看情况，Won't 直接 drop。

3.3 "都很重要"是一种逃避

说句不好听的：当你说"都很重要"的时候，你其实是在逃避一个不舒服的决定。

因为排优先级意味着你要告诉某些人："你的需求这次不做。"这会让人不高兴。你不想当那个"坏人"。

但你不当"坏人"的代价是什么？是所有人都不高兴——因为什么都没做完。

Greg McKeown 在《Essentialism》（精要主义）里说过一句话："If you don't prioritize your life, someone else will."（如果你不给自己的事排优先级，别人会替你排。）

放到职场里：如果你不给需求排优先级，每个需求方都会替你排——而他们排出来的结果永远是"我的最重要"。

4. How：怎么在会上用 MoSCoW？

4.1 MoSCoW 分桶的实操步骤

别急着上场景，先说流程。我把它压缩成五步，30 分钟能跑完：

第一步：列出所有需求（5 分钟）

把这个迭代/版本所有候选需求列在白板或共享文档上。不讨论优先级，先确保"桌上的牌"是全的。

第二步：算清产能（2 分钟）

团队这个迭代有多少可用人天？扣掉会议、请假、技术债维护之后的净产能是多少？把这个数字写在白板最上面。所有人都看得到。

第三步：逐条过 Must 判断问题（10 分钟）

对每个需求问一句："如果没有这个，产品能不能上线/这个迭代的目标能不能达成？"

• 能 → 不是 Must，先放一边
• 不能 → Must

注意：Must 的总工时不能超过产能的 60%。超了就要砍——要么把某个 Must 降级为 Should，要么把某个 Must 拆小。

第四步：分 Should / Could / Won't（10 分钟）

剩下的需求，用两个问题快速分桶：

• "有没有变通方案？" → 有 = Should，没有 = 回去重新评估是不是 Must
• "砍掉它谁会受影响？" → 没人 = Could，有人但可以接受 = Should
• "这次明确不做？" → Won't

第五步：确认并公示（3 分钟）

把分桶结果写进会议纪要，发给所有相关人。特别是 Won't 的部分——一定要写清楚"为什么这次不做"和"预计什么时候重新评估"。

4.2 三个实战场景改写

场景一：需求评审会——14 个需求，只能做 6 个

❌ 无效版

产品经理："这 14 个需求都是这个版本要做的。"

开发 lead："时间不够啊。"

产品经理："那你们加加班？"

开发 lead："……行吧。"

（两周后：14 个需求做了 6 个半成品，0 个完整交付。）

✅ MoSCoW 版

开发 lead："这个迭代净产能 25 人天。我们先过一遍 Must——哪些需求如果不做，这个版本就不能发布？"

（逐条过完，筛出 5 个 Must，合计 16 人天。）

开发 lead："Must 占了 16 天，还剩 9 天。现在看 Should——哪些很重要但有变通方案？"

（筛出 3 个 Should，合计 8 人天。选了 2 个，6 人天。）

开发 lead："还剩 3 天的 buffer。Could 里有没有工时小于 3 天的？"

产品经理："暗黑模式适配，预估 2 天。"

开发 lead："行，放进来。剩下的 6 个需求标 Won't this time，我在会议纪要里写清楚原因，下个迭代重新评估。"

产品经理："活动页面改版真的不能做吗？运营那边催得很急。"

开发 lead："活动页面预估 5 天，放进来 Must 就超了。两个选择：要么砍掉一个现有的 Must，要么活动页面用现有模板先顶一版，下个迭代再做定制版。"

产品经理："……那先用模板顶吧。"

结果：5 个 Must + 2 个 Should + 1 个 Could = 8 个需求，24 人天，留 1 天 buffer。两周后全部完整交付。

场景二：Sprint 规划会——技术债 vs 新功能

❌ 无效版

开发 A："数据库连接池那个问题不修，迟早要炸。"

产品经理："但客户等着新功能呢，先做功能吧。"

开发 A："那出了线上事故谁负责？"

产品经理："……那你们自己安排吧。"

（结果：技术债没修，新功能也因为性能问题上线后回滚了。）

✅ MoSCoW 版

开发 lead 拉出一张表：

开发 lead："连接池是 Must，因为它直接影响新功能能不能稳定运行。用户画像是 Should，我们先给客户一个变通方案。大家有异议吗？"

产品经理："用户画像客户催了三次了……"

开发 lead："我理解。但如果连接池不修，用户画像上线第一天就会因为超时被投诉。先修地基，再盖楼。"

产品经理："好吧，那变通方案我去跟客户沟通。"

场景三：砍需求沟通——怎么跟需求方说"你的需求这次不做"

❌ 无效版

你："你那个需求这次排不进去。"

需求方："为什么？我上个月就提了！"

你："资源不够。"

需求方："那什么时候能做？"

你："不确定。"

需求方（去找你老板投诉了）。

✅ MoSCoW 版

你："你提的报表导出功能，我们评估后放在了 Won't this time。原因是这样的——"

你拉出 MoSCoW 分桶表：

"这个迭代的 Must 有 5 个，占了 60% 的产能。Should 有 3 个，占了 24%。你的报表导出预估 4 天，如果放进来，就要把一个 Must 挤掉。目前的 Must 里有安全漏洞修复和核心支付流程，这两个砍不了。"

"我的建议是：这次先用现有的数据看板手动导出 CSV 作为变通方案，下个迭代我把报表导出放进 Should，优先排。你看这样行吗？"

需求方："那下个迭代一定能做吗？"

你："我不能 100% 保证，但我会在下次需求评审时把它作为 Should 提出来，并且提前跟你对齐优先级。如果下个迭代还是排不进去，我会提前告诉你，不会让你等到最后才知道。"

需求方："行，那先用 CSV 顶着。"

为什么有效？ 因为你做了三件事：

1. 给了理由——不是"资源不够"这种废话，而是具体的产能数字和分桶逻辑
2. 给了变通方案——不是"不做"，而是"先这样顶着"
3. 给了承诺——不是"不确定"，而是"下次评审优先提，提前沟通"

4.3 一张对比表：无效排优先级 vs MoSCoW 排优先级

4.4 技术人常踩的坑

坑一：把技术债全放 Won't

这是最常见的坑。产品经理天然倾向于把新功能标 Must，把技术债标 Won't。如果你不争取，技术债永远排不上。

修复方法：用业务语言翻译技术债。

不要说："连接池需要优化。"

要说："如果不优化连接池，新功能上线后高峰期 100% 会超时，用户会看到 502 错误页面，客服电话会被打爆。"

当技术债的后果被翻译成业务影响，它就有资格竞争 Must。

坑二：不敢说 Won't

很多人觉得说 Won't 就是在得罪人。所以他们把所有东西都塞进 Could——"可以有嘛，看情况嘛"。

结果就是 Could 变成了一个垃圾桶，里面堆了 30 个需求，谁也不知道哪个会做哪个不会做。需求方一直抱着希望等，等到最后发现没做，比一开始就说 Won't 更生气。

修复方法：Won't 是一种尊重。 明确告诉对方"这次不做"，比含糊其辞地说"看情况"要诚实得多。加上"this time"和重新评估时间，对方反而更容易接受。

坑三：Must 膨胀——所有人都说自己的是 Must

如果你让每个需求方自己标优先级，14 个需求里会有 12 个 Must。这不是 MoSCoW，这是 MoSCoW 的反面。

修复方法：用 60% 产能上限做硬约束。

"这个迭代净产能 25 人天，Must 最多 15 天。现在 Must 已经排了 18 天了，超了 3 天。哪个 Must 可以降级为 Should？或者哪个 Must 可以拆小，只做核心部分？"

当你把数字摆出来，讨论就会从"我的更重要"变成"怎么在 15 天里塞下最关键的东西"。

坑四：分完桶就完事了，不跟踪

MoSCoW 不是一次性的仪式。迭代过程中，情况会变——新的紧急需求插进来，某个 Must 的工时被低估了，某个外部依赖延迟了。

修复方法：每周站会花 2 分钟扫一眼 MoSCoW 表。 Must 还是 Must 吗？有没有新的信息让某个 Should 升级为 Must？有没有某个 Must 可以降级？保持分桶的动态更新。

坑五：把 MoSCoW 当成开发团队内部的事

MoSCoW 的威力在于它是一个跨角色的沟通工具。如果只有开发团队自己在用，产品经理和业务方不知道分桶逻辑，他们还是会觉得"你们怎么又砍我的需求"。

修复方法：让需求方参与分桶过程。 最好是在需求评审会上当场分桶，让所有人看到产能数字、看到判断标准、看到每个需求是怎么被分到哪个桶里的。参与了过程的人，更容易接受结果。

5. MoSCoW 的适用边界——它不是万能的

说了这么多好话，也得说说 MoSCoW 的局限性。

局限一：它不解决"Must 之间怎么排序"的问题

MoSCoW 告诉你"这 5 个是 Must"，但如果你只能做 3 个 Must，先做哪个？MoSCoW 本身不回答这个问题。你需要配合其他工具——比如 RICE 评分（下一篇会讲）或者 WSJF（Weighted Shortest Job First）。

局限二：它依赖"诚实的工时估算"

如果你的团队估工时一向不准（谁的团队准过？），那 60% 产能上限也是个虚数。MoSCoW 能帮你分桶，但不能帮你估工时。估工时是另一门手艺。

局限三：它需要有人敢拍板

MoSCoW 提供了分桶的框架，但最终"这个到底是 Must 还是 Should"需要有人做决定。如果你的团队里没有人愿意承担这个决定的责任，MoSCoW 也会变成又一场无休止的讨论。

这时候你可能需要回顾一下这个系列之前讲过的 DACI——先搞清楚谁是 Decider（决策者），再用 MoSCoW 分桶。

6. MoSCoW 与其他优先级工具的关系

MoSCoW 不是孤立存在的。它和这个系列里的其他工具可以组合使用：

总结

一句话：MoSCoW 不是让你做更多的事，而是让你做对的事。

当所有人都说"很重要"的时候，你需要的不是更多的人手，而是一个分桶机制。Must / Should / Could / Won't——四个桶，一张表，30 分钟，把"都很重要"变成"先做哪个"。

记住三个关键数字：

• 60%：Must 不超过产能的 60%
• 0：Won't 不是零价值，是"这次不做"
• 1：每个 Won't 都要有一个重新评估的时间点

行动清单

• [ ] 下次需求评审前，先算清团队净产能（扣掉会议、请假、技术债维护）
• [ ] 在白板上画四列：Must / Should / Could / Won't，当场分桶
• [ ] Must 总工时不超过产能的 60%，超了就砍或拆
• [ ] 每个 Won't 写清楚：为什么不做 + 变通方案 + 重新评估时间
• [ ] 把分桶结果写进会议纪要，发给所有相关人
• [ ] 每周站会花 2 分钟扫一眼 MoSCoW 表，保持动态更新
• [ ] 技术债也参与分桶——用业务语言翻译技术影响

思维导图

@startmindmap
<style>
mindmapDiagram {
  node { BackgroundColor #FAFAFA }
  :depth(0) { BackgroundColor #FFD700 }
  :depth(1) { BackgroundColor #E3F2FD }
  :depth(2) { BackgroundColor #F5F5F5 }
}
</style>
* MoSCoW\n把"都很重要"变成"先做哪个"
** 扎心现实
*** 14 个需求都标 P0
*** 全接了 = 全延期
*** "都很重要" = 什么都不重要
** What: 四个桶
*** Must have (~60%)
**** 没有它就不能上线
**** 硬约束：不超过产能 60%
*** Should have (~20%)
**** 很重要但有变通方案
**** 时间够就做
*** Could have (~20%)
**** 锦上添花
**** 砍掉没人注意到
*** Won't have (this time)
**** 明确说"不"
**** 附带重新评估时间
** Why: 为什么要分桶
*** 资源有限性
**** 28 人天 vs 25 人天产能
*** 决策疲劳
**** 大脑 = 单线程 CPU
**** 全 HIGH = 调度器崩溃
*** "都重要"是逃避决策
** How: 怎么用
*** 五步流程（30 分钟）
**** 列需求 → 算产能 → 过 Must
**** → 分 Should/Could/Won't → 公示
*** 三个场景
**** 需求评审：14 选 8
**** Sprint 规划：技术债 vs 新功能
**** 砍需求沟通：Won't + 理由 + 变通
*** 常见坑
**** 技术债全放 Won't
**** 不敢说 Won't
**** Must 膨胀
**** 分完不跟踪
**** 不让需求方参与
** 组合使用
*** 艾森豪威尔矩阵：分桶前过滤
*** DACI：谁来拍板
*** RICE：Must 内部排序
*** OKR：目标对齐
*** DoD：定义"做完"
@endmindmap

系列回顾

1. 4D 总结法
2. 黄金圈法则
3. TNB 表达模型
4. FAB 提案法
5. STAR 面试法
6. 同理心三方法
7. 5W1H + 8C1D
8. 艾森豪威尔矩阵
9. PDCA 循环
10. SMART 原则
11. 领导力
12. 逻辑树
13. 解决问题五步法
14. 5 个 Why
15. 沟通四要素 CARE
16. 金字塔原理
17. 三点法
18. DACI
19. 四线复盘法
20. RAPID
21. 5S 问题处理法
22. SWOT 自我定位
23. AARRR 漏斗
24. 第一性原理
25. RACI
26. 非暴力沟通
27. SCAMPER
28. MVP 思维
29. ABC 情绪理论
30. AI Agent 学职场英语
31. 向上管理
32. OODA 循环
33. OKR
34. MoSCoW 优先级（本篇）
35. RICE / ICE 评分
36. 里程碑计划
37. 验收标准 DoD
38. 范围管理

扩展阅读

• MoSCoW method — Wikipedia — MoSCoW 的起源和定义
• DSDM Agile Project Framework — MoSCoW 最早被系统化应用的敏捷框架
• 《Essentialism: The Disciplined Pursuit of Less》— Greg McKeown — 精要主义，理解"少即是多"的底层逻辑
• 《Software Requirements》— Karl Wiegers — 需求工程经典，详细讲解了优先级排序方法
• Prioritization Techniques — ProductPlan — MoSCoW 在产品管理中的实操指南

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。