一、什么是MoSCoW模型？

MoSCoW模型是在项目管理、软件开发中使用的一种排序优先级的方法，以便开发人员、产品经历、客户对每个需求交付的重要性达成共识。

MoSCoW是一个首字母缩略词，代表：

M（Must have）：必须有。这些是产品成功的关键任务功能，通常是MVP（最小可行产品）的功能，例如微信的聊天、添加好友的功能。

S（Should have）: 应该有。这些功能很重要，但不是必需的。虽然’应该有’的要求与’必须有’一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。

C（Could have）：可以有。这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。

W（Won’t have）： 不会有。 最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。 “不会有”会被要求删除，或重新考虑。

总的来说，MoSCow模型为我们提供了一种思考方式，围绕实际产出交付物确定优先级，引导我们重新思考迭代中的需求。

二、为什么要使用MoSCoW模型？

1、优先级管理：MoSCoW模型帮助团队明确需求的优先级，确保最重要的需求得到满足。通过将需求分类为"Must"（必须有）、"Should"（应该有）、"Could"（可以有）和"Won't"（不会有）四个级别，团队可以更好地理解和管理需求的重要性。

2、风险管理：将需求按照优先级分类可以帮助团队在项目实施过程中更好地管理风险。"Must"级别的需求通常是项目的核心功能，如果这些需求无法满足，项目可能会失败。通过优先处理这些关键需求，团队可以减少项目失败的风险。

3、交付价值：MoSCoW模型有助于团队在有限的时间和资源下，优先交付最有价值的功能。通过明确不同需求的优先级，团队可以确保在项目进行过程中首先交付最重要的功能，从而提供更大的价值给用户或客户。

4、沟通和共识：MoSCoW模型提供了一种简单且易于理解的方式来描述和沟通需求的优先级。通过使用这个模型，团队成员和利益相关者可以更容易地就需求的重要性达成共识，避免冲突和误解。

三、MoSCoW模型如何使用？

在 Why Companies Need to do a Better Job of Prioritizing Features这篇文章中，作者介绍了三种方法：

1、按知识价值排序

对于有风险的项目，这非常有用。风险是未知的。降低风险，最好减少未知，并用知识来减少未知。下面几个信号有助于你理解：是时候停止考虑这些功能了，要开始考虑降低风险了。

团队说，“我们不知道这是否可行…”

产品负责人说，“我不知道客户对这个怎么反应”

架构师说，“我不确定这个平台是否支持这个功能”

业务分析师说，“我还没有弄清楚那部分的需求”

测试人员说，“我怎么测呢？”

对于如上的每一个例子，都是缺乏知识的清晰信号，从而妨碍了相关人员有信心地往前走。

2、按增收排序

举一个付款方式的例子：“用户体验模型显示，有15%的人点击Paypal按钮走付款流程。购物车放弃率也是15%。而实现Paypal作为支付方式，将会大量地降低我们的购物车放弃率，并导致收入会增加10%-15%”。很清晰不是吗？如何计算这个功能潜在的增加收入？

创建一个可比的标准，衡量当前的收入差距。量化潜在的收入增加（百分比，或者用美元）对比增加收入（超过一年）和创建该功能的成本。对于所有增加收入相关的功能，按照递减的增收排序

3、按成本节省排序

“旧平台每笔交易需要10秒，而新平台每笔交易需要7秒。把功能挪到新的平台上，每笔交易会节省30%的时间，而且每个月我们会做超过100万笔的交易。” 很清晰不是吗？但是，现实生活中的大多数情况会更复杂混乱。

任何间接节省时间的功能，都会降低成本，例如自动化手动任务。调查你的客户手动执行该任务的时间花费，并用这个人的“成本/小时”来算出成本节省的数字。砍掉一些功能有时可以节省成本，例如公司推出仅有核心功能的“轻量化”版本软件。

创建开放的API，允许开发人员创建功能可以节省成本。这是因为功能开发的任务转移到了开发社区中，这意味着个体的开发人员会承担资金提供并支持这个插件。

四、最后小结

MoSCoW模型虽然看上去简单，但内涵丰富。“需求”可以算是各角色矛盾的核心了，想想那些年产品经理和研发人员打过的嘴仗、项目交付前曾拼过的命……千言万语汇成一句话：需求管理不规范，项目交付两行泪！快去试试用MoSCoW来进行需求管理吧！