由MoSCoW方法引发的对需求优先级排序的思考
一、什么是MoSCoW方法？
1、MoSCoW是一种优先级排序放法，是在项目管理、软件开发中使用的优先化技术。以便开发人员，产品经理，客户对每个需求交付的重要性达成共识。
看图很容易就理解这四个字母的含义，同时需求排序也理应是如此，按照M -》S -》C -》W （甚至W都不会出现在迭代需求板【Sprint BackLog】上）
二、为什么要用MoSCoW方法？
或者这个问题也可以换成：为什么要做需求优先级排序？
1、避免样样做，样样差
从互联网产品开发的角度来分析，微信、支付宝、滴滴…这些成功的产品已经具备很多功能，但是最初它们是靠着简单的核心功能（Must have）功能打开了市场。比如微信的语音信息、朋友圈，支付宝免费转账、付款，滴滴的打车功能。后来，他们都添加了琳琅满目的功能，但我们最常用的，还是那些最初的功能，正是最初的Must have功能吸引了用户，满足了用户的痛点，培养了用户。而一些失败的产品，开发、运营团队都苦不堪言，目标太多，时间紧，配置跟不上，团队的注意力也都分散了。
2、应对快速迭代，满足变化
而为了降低风险，提高速度，应尽可能的缩短每一次的迭代。如何缩短每一次迭代？其实很简单，尽量每一次循环、迭代，只验证少量的核心功能（Must have），整个过程就会快起来，如果在一开始，就想很多，做很多，一次迭代下来的时间，会拉长，拖慢速度，增大风险。
三、如何使用MoSCoW的理念给任务排序？
按知识价值排序
对于有风险的项目，这非常有用。风险是未知的。降低风险，最好减少未知，并用知识来减少未知。下面几个信号有助于你理解：是时候停止考虑这些功能了，要开始考虑降低风险了。
团队说，“我们不知道这是否可行…”
产品负责人说，“我不知道客户对这个怎么反应”
架构师说，“我不确定这个平台是否支持这个功能”
业务分析师说，“我还没有弄清楚那部分的需求”
测试人员说，“我怎么测呢？”
对于如上的每一个例子，都是缺乏知识的清晰信号，从而妨碍了相关人员有信心地往前走。
按增收排序
举一个付款方式的例子：“用户体验模型显示，有15%的人点击Paypal按钮走付款流程。购物车放弃率也是15%。而实现Paypal作为支付方式，将会大量地降低我们的购物车放弃率，并导致收入会增加10%-15%”。很清晰不是吗？如何计算这个功能潜在的增加收入？
创建一个可比的标准，衡量当前的收入差距。
量化潜在的收入增加（百分比，或者用美元）
对比增加收入（超过一年）和创建该功能的成本。
对于所有增加收入相关的功能，按照递减的增收排序
按成本节省排序
“旧平台每笔交易需要10秒，而新平台每笔交易需要7秒。把功能挪到新的平台上，每笔交易会节省30%的时间，而且每个月我们会做超过100万笔的交易。” 很清晰不是吗？
但是，现实生活中的大多数情况会更复杂混乱。下面是《Why Companies Need to do a Better Job of Prioritizing Features》推荐的按成本节省排序的技巧：
-
任何间接节省时间的功能，都会降低成本，例如自动化手动任务。调查你的客户手动执行该任务的时间花费，并用这个人的“成本/小时”来算出成本节省的数字。
-
砍掉一些功能有时可以节省成本。举一个例子，公司推出仅有核心功能的“轻量化”版本软件。更少的功能 = 更少的维护成本。
-
创建开放的API，允许开发人员创建功能可以节省成本。这是因为功能开发的任务转移到了开发社区中，这意味着个体的开发人员会承担资金提供并支持这个插件。
1. Reach（接触数量）
为避免因自己的使用习惯造成的偏差，请估计每个项目在一定时间段内会影响多少用户。接触数量用每个时间段的用户数或事件数来衡量。这可能是「每季度客户数量」或「每月交易数量」。尽可能使用产品指标的实际测量结果，而不是随机去拍一个数。
2. Impact（影响程度）
要专注于那些能对你的目标产生可观影响的项目，预估这个项目对个人产生的影响。影响程度难以准确度量。因此，我设置了一些选项来衡量：3为「巨大影响」，2为「高」，1为「中」，0.5为「低」，最后0.25为「最低」。我们在计算最后RICE得分时会乘以这些数字来按比例放大/减小。
选择一个数字来预估影响程度看起来可能不太科学。但是别忘了它替代的是另一种估算方式：拍脑袋。
3. Confidence（信心指数）
有些主意非常激动人心但是并不明确，为了遏制住马上去实践它们热情，在评估时请把信心指数考虑进去。如果你认为一个项目可能会产生巨大的影响，但没有数据可以支撑，那么信心指数会让你更有掌控力。
信心指数是一个百分比，我设置了另一种选项来避免决策瘫痪。100％是「高信心度」，80％是「中等」，50％是「低」。比这更低的信心指数都可以认为是「登月计划」。对自己诚实一点：你的预估真的可靠吗，有多少论据支撑呢？
4. Effort（投入精力）
为了迅速行动并且事半功倍，请估算项目需要团队的所有成员（产品，设计和工程）的总时间。
投入精力的预估单位是「人/月」：一个团队成员可以在一个月内做的工作。这里有很多未知数，所以我用整数来预估（一个月以下的任何事情都用0.5来预估）。不像其他的积极因素，需要投入更多的精力是一件「坏事」，它会作为整体影响力的分母。
一旦你完成了这些因素的预估，把它们合并成一个单一的得分，这样你就能一目了然的比较不同项目的分数了。这是简单的公式：
一旦最初的评分完成，排序你的项目表单，并重新评估。有没有哪些项目的分数似乎太高或太低？如果是的话，重新考虑你的估算并做出调整，或者接受你的直觉可能是错误的。
在决定难以比较的项目想法时，RICE可以提供极大的帮助。它迫使你思考为什么一个项目的想法会产生影响力，并且诚实地估计为达到目标所需的努力。
四、结尾
不管用什么方法，需求的优先级评估是产品经理的基本能力，用户的耐心有限、研发的资源不足、商业的时间转瞬即逝，做人做事要事第一。
五、文献来源
http://www.woshipm.com/pd/1887717.html
