需求太多处理不过来？MoSCoW 模型帮你

一、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】直接付款流程。如果 Paypal 作为支付方式，将会大量地降低购物车放弃率，从而收入会增加 10%-15%。”

那如何计算这个功能潜在的增加收入？

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

3、按成本节省排序

“旧平台每笔交易需要 10 秒，而新平台每笔交易需要 7 秒。把功能挪到新的平台上，每笔交易会节省 30%的时间，而且每个月我们会做超过 100 万笔的交易。”

现实生活中的大多数情况会更复杂混乱。节省时间的功能都有助于降低成本，例如自动化手动任务。调查你的客户在手动执行该任务时所花费的时间，并使用该人的“成本/小时”来计算成本节省的具体数值。有时，通过削减一些功能，可以实现成本的节约，例如推出仅包含核心功能的“轻量化”版本软件。

创建一个开放的 API，允许开发人员创建能够节省成本的功能。通过将功能开发任务转移到开发社区中，个人开发者将负责提供资金并支持这个插件。

图片

四、最后小结

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