【推荐】产品经理必须掌握的10种优先级决策技术详解---技术3：莫斯科方法---MoSCoW Method

莫斯科方法是什么

莫斯科方法是由Oracle软件专家Dai Clegg开发的在确定时间框架内的一种属于敏捷项目管理的优先级排序方法。它来源于Dynamic Systems Development Method (DSDM)。

这种方法又被称为是莫斯科分析，莫斯科优先，莫斯科技术和莫斯科规则。

MoSCoW中的两个o并无实际意义，只是为了便于发音而加入的。

如何使用莫斯科方法

举个例子：

你现在是某互联网公司的产品经理，公司打算在一个月后推出一款新的APP，产品概念已经确定，现在你已经整理出了10个需求，分别是R1-R10。

接下来，我们就了解一下如何通过莫斯科方法完成这些需求的优先级评估。

第一步：确定目标和优先级因素

在使用莫斯科方法之前，企业必须确保项目中涉及的团队和其他涉众就项目目标和用于确定优先级的因素达成一致。

同时，还应制订解决分歧的计划。

第二步：确定资源分配比例

例如，20%的资源可以分配给可能拥有（也就是could-have）的需求，而40%的资源分配给必须拥有（也就是must-have）的需求，30%的资源分配给应该拥有（should-have）的需求。

第三步：需求分配

一旦需求被收集起来，并且在业务和涉众之间达成了协议，那么团队就可以开始将需求分配到以下四个类别，大家看下图：

莫斯科方法工具示意

如何确定划分不同类别的标准

大家一定有一个疑问，这些需求分类到不同的类别中的标准是什么？或者说优先级划分的依据是什么呢？

在说明之前呢，我们得先把握莫斯科方法中划分优先级的核心准则，这个准则就是：

优先级的划分是根据业务价值或缺少某项而对用户的影响来确定的。

我们继续。

第一类：M-H：Must-Have，必须有的

这类是指我们要成功完成产品所必需的所有选项，那具体该怎么确定呢？通常我们会参照以下四个要求：

• 如果没有这个选项，在目标期限之前完成产品是毫无意义的；
• 比方说你的APP中的注册，登录就属于这个要求；
• 如果没有这个选项，最终的产品将不合规或不合法；
• 比方说你的APP中对个人隐私的保护就属于这个要求；
• 如果没有这个选项，最终的产品将不安全；
• 比方说你的APP中对个人数据的保护就属于这个要求；
• 如果没有这个选项，最终的产品将无法交付有效的解决方案。
• 比方说你的APP必须符合应用商店的上架规范就属于这个要求。

归纳起来，就是决定产品基本属性、核心价值和标准要求的选项都属于M-H。

第二类：S-H：Should-Have，应该有的

这类是指对产品的完成很重要，但不是必需的选项，换句话说，如果最终产品中没有包含应有的选项，那么产品仍将发挥作用。

在实际操作中，我们经常会把“重要”的，但是如果缺失，也“不会给产品带来较大影响”的选项放在这一类中。

比方说，你的APP中提供的微信，微博这样的一站式登录就属于这类，毕竟没有这个，你自己提供的本站注册登录系统也是可以的。

第三类：C-H：Could-Have，可能有的

这类是指那些即使被排除在产品之外，影响也很小的选项。通常我们会参照两个要求来判断：

• 一个令人满意的选项，但是并不重要；
• 与忽略S-H选项相比，忽略这个选项对产品的影响更小。

比方说，你的APP用户可以绑定微信增加账户安全性（提示登录情况），但是就算没有，也不会从根本上影响安全。

关于第三类呢，我想多说几句，我们通常在思考一个产品的时候，总是习惯于首先想在这个产品中有哪些不同于竞品的要素，而这在莫斯科方法中，其实就意味着我们习惯于先考虑第三类，也就是可能有的，其实这也揭示了莫斯科方法的一个常见实务，如果使用莫斯科方法，第三类是首先考虑的，但第一类和第二类才是优先考虑的。

第四类：W-H：Will not Have，不会有的

这类是指那些所有被认为不符合项目时间框架内的选项。换句话说，就是某些选项即使重要，但是在既定的时间内无法完成，那么，这些选项也是属于第四类的。

之所以这样定义第四类，原因有三个：

1、有助于加强我们对其他三个类别选项的关注；

2、为最终产品中不包含的选项设定现实的期望；

3、有助于防止范围蔓延，避免出现产品选项在开发过程中增加超出预期的趋势。

关于莫斯科方法的四个分类，就讲这么多，我来做个总结，大家看下图：

莫斯科方法的常见应用场景

莫斯科方法通常用在需求级及以下，包括需求，特征，功能，但是业内有一种观点，认为这个方法被认为更适合内部项目，但不适合有大量客户的产品，因此，它在敏捷软件开发团队中非常流行。

事实上，这个方法就是在项目管理领域诞生的。

莫斯科方法的优势和不足

优势：

1、易于掌握和使用，因为它使用了简单的原则和人类习惯的语言；

2、在设置优先级的差异化级别上是有力的工具；

3、该方法可用于解决纠纷，并与利益相关者达成协议；

4、该分析可用于确保生产出最小可行产品(MVP)；

5、优先级分类依赖于团队的专业知识；

6、该方法既可用于现有项目，也可用于新项目。

不足：

1、对于第四类（不会有）的选项，以及它们是否被排除在发布或整个产品之外，存在不确定性；

2、在同一类别中，没有办法对需求进行优先级排序；

3、没有真正的理由来解释为什么一个要求是必须拥有的，而另一个是应该拥有的；

4、如果一个组织的决策过程排除了集体领导，那么优先排序可能会变得主观和低效；

5、由于缺乏所有涉众的上下文，不准确的优先级是可能的。当团队成员在上下文中有不同程度的参与时，他们在根据实际重要性对任务/特性进行分类时会遇到问题。

莫斯科方法的底层逻辑

如果时间和资源一定，那么，更多的时间和资源应该分配到必须有（must-have）的需求上。