MoSCoW 方法：把“必须有”从“最好有”里分出来

MoSCoW 方法把工作分进四个篮子：必须有、应该有、可以有，以及这次不要有。“必须有”是必要的，没有它计划就失败；“应该有”重要但不致命；“可以有”在时间允许时值得做；“不要有”则是有意把某样东西留到本轮之外的决定。当你有一个固定的截止日期、必须决定什么才真正装得进去时，这套方法最有用。

MoSCoW 从何而来

MoSCoW 由软件顾问戴·克莱格（Dai Clegg）在 1990 年代提出，并成为敏捷和 DSDM 项目交付的常用方法。大写字母代表四个类别；小写的 o 只是让这个缩写读得出来。它之所以流行，是因为它解决了每个团队都会面对的问题：一长串想做的东西，却没有足够的时间全做完。MoSCoW 不假装一切都是最高优先级，而是逼出一个明确、共享的决定，去确定什么才真正必要。

尽管它诞生于软件领域，这套方法对任何有截止日期和范围的事都管用：筹备一场活动、发布一款产品，甚至组织一次搬家。只要时间固定、想要的超过了能力所及，MoSCoW 就能帮上忙。

让 MoSCoW 区别于一张普通优先级清单的，是“时间盒”这个词。这些类别不是重要性的永久排名；它们描述的是什么装得进一个特定的周期。一个功能可以这个季度“不要有”、下个季度“必须有”，这毫无矛盾，因为问题始终是“鉴于我们实际拥有的时间，什么属于这一次发布？”这种框定，让争论扎根于现实，而非陷入“哪个点子客观上最好”的抽象辩论。

四个类别

• 必须有。没有商量余地。没有它，交付物无法运作、截止日期被错过，或某条法律或安全规则被违反。
• 应该有。重要，去掉会很痛，但有变通办法。它可以延后而不会毁掉计划。
• 可以有。值得做且纳入成本低，时间一紧时第一个被放弃。
• 不要有（这次）。明确排除在本周期范围之外。公开搁置，这样没人会以为它还会来。

最锋利的检验是针对“必须”这一类。问：“如果把它去掉会怎样？”如果诚实的答案是一个变通办法或一点小烦恼，那它就是“应该”，而非“必须”。大多数团队会发现，真正必要的东西，远比他们起初以为的要少得多。

60% 法则

最常见的 MoSCoW 错误，是把一切都标成“必须有”。那就背离了初衷：如果一切都必要，你又回到了一张没有优先级的扁平清单。一条被广泛使用的准则，是把“必须有”控制在约 60% 的可用工作量，其余由“应该有”和“可以有”构成。剩下的那 40% 不是填充料；它是吸纳每个真实项目都会遇到的缺陷、病假和意外的缓冲。当出了问题时，你放弃一个“可以有”，而非一个“必须有”，核心照样按时交付。

一个完整示例

设想你正要上线一个简单的预订网站，有一个硬性截止日期。功能清单可能这样分类。

现在决定已毫不含糊。如果时间吃紧，深色模式第一个走、折扣码第二个，而预订和确认邮件受到保护。同样重要的是，所有人都同意忠诚系统不做，于是上线时它缺席，也没人意外。

MoSCoW 与其他方法的比较

MoSCoW 回答的是“什么装得进这个固定的时间盒？”，而非“哪一个任务是下一个？”对一张个人每日清单来说，更轻的 ABCDE 方法 更快，因为它按后果给单个任务排序。当你需要按预期价值和工作量来比较整个项目、而非在一个截止日期内排序时，RICE 打分 会给你一个可据以排名的数字。而如果你真正的挣扎是真正重要和紧急的工作不断相撞，艾森豪威尔矩阵 会直接暴露那份张力。

让它在实践中奏效

MoSCoW 既是排序工具，也是对话工具。它真正的威力，出现在一个团队或利益相关方一起就类别达成一致时，因为这些标签记录的是一个共享的决定，而非某个人的意见。当客户后来问为什么他们最爱的功能被放弃了，你可以指向一个共同商定的标签，而不必把整个计划重新辩一遍。在每个周期开始时重看清单，并且只有当你同时把某样东西降级、以保持 60% 的平衡时，才愿意把一个“应该”提升为“必须”。优先级是一笔固定的预算：你无法在不从另一个篮子取走的情况下，往一个篮子里添加。

最后一个习惯让 MoSCoW 经久耐用：像上面的示例那样，在每个标签旁写一行理由。正是这些理由，让你在数周后仍能为计划辩护，也让你在情况改变时能快速重新排序。没有理由的标签只是一个意见；带理由的标签，则是一个你能站得住脚的决定。

不可能一切都是优先级。你一旦承认这一点、并说出这次你不会做什么，真正重要的工作，终于就有了被做完的空间。