前言
这周新生大学全栈营线上班开始正式授课了。一开课，就学习到了很多有用的、好玩的概念。其中，拆解任务一章使用了：must have/ should have/ could have/ nice to have 模型。这个模型是从MoSCoW法则派生出来的。
什么是MoSCoW ？
MoSCoW 优先级排序法，是在项目管理、软件开发中使用的优先化技术。以便开发人员，产品经理，客户对每个需求交付的重要性达成共识。
-
Must have：必须有。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能。比如微信的聊天信息、通讯录、朋友圈。
-
Should have: 应该有。这些功能很重要，但不是必需的。虽然’应该有’的要求与’必须有’一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。
-
Could have： 可以有。 这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。
-
Won’t have： 这次不会有。 最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。 “不会有”会被要求删除，或重新考虑。
总的来说，”这次不会有”在项目讨论阶段，就会被去除。所有要求看上去都很重要，但是如果交货时间紧，“”可以有”将第一批被删除，”应该有”紧随其后。
为什么要使用MoSCoW法则拆解任务？
我们从互联网产品开发的角度来分析：
样样做，样样差
微信、支付宝、滴滴…这些成功的产品已经具备很多功能，但是最初它们是靠着简单的核心功能（Must have）功能打开了市场。比如微信的语音信息、朋友圈，支付宝免费转账、付款，滴滴的打车功能。后来，他们都添加了琳琅满目的功能，但我们最常用的，还是那些最初的功能，正是最初的Must have 功能吸引了用户，满足了用户的痛点，培养了用户。
而一些失败的产品，常常一开始便拥有很多功能，美其名曰“全面”，以全面来打入市场。最终却是“样样做，样样差”，开发、运营团队都苦不堪言——目标太多，时间紧，配置跟不上，团队的注意力也都分散了。
快速迭代，满足变化
开发一款互联网产品，从调研、产品规划、设计、开发、到测试，再到推向市场，周期长，变数多。通常开发产品时，先做出最小化可行产品（MVP），然后通过测试并收集用户的反馈，快速迭代，不断修正产品。这样做，才能最终适应市场的需求。
而为了降低风险，提高速度，应尽可能的缩短每一次的迭代。如何缩短每一次迭代？其实很简单，尽量每一次循环、迭代，只验证少量的核心功能（Must have），整个过程就会快起来，如果在一开始，就想很多，做很多，一次迭代下来的时间，会拉长，拖慢速度，增大风险。
MoSCoW方法如何用？
先列出所有的功能，然后按照一定的规则，分为四类：“必须有’, ’应该有‘，’可以有‘， ’这次不会有‘ 。
那么按照什么呀的规则排序呢？在《Why Companies Need to do a Better Job of Prioritizing Features》这篇文章中，作者介绍了三种方法：
按知识价值排序
对于有风险的项目，这非常有用。风险是未知的。降低风险，最好减少未知，并用知识来减少未知。下面几个信号有助于你理解：是时候停止考虑这些功能了，要开始考虑降低风险了。
团队说，“我们不知道这是否可行…”
产品负责人说，“我不知道客户对这个怎么反应”
架构师说，“我不确定这个平台是否支持这个功能”
业务分析师说，“我还没有弄清楚那部分的需求”
测试人员说，“我怎么测呢？”
对于如上的每一个例子，都是缺乏知识的清晰信号，从而妨碍了相关人员有信心地往前走。
按增收排序
举一个付款方式的例子：“用户体验模型显示，有15%的人点击Paypal按钮走付款流程。购物车放弃率也是15%。而实现Paypal作为支付方式，将会大量地降低我们的购物车放弃率，并导致收入会增加10%-15%”。很清晰不是吗？如何计算这个功能潜在的增加收入？
创建一个可比的标准，衡量当前的收入差距。
量化潜在的收入增加（百分比，或者用美元）
对比增加收入（超过一年）和创建该功能的成本。
对于所有增加收入相关的功能，按照递减的增收排序
按成本节省排序
“旧平台每笔交易需要10秒，而新平台每笔交易需要7秒。把功能挪到新的平台上，每笔交易会节省30%的时间，而且每个月我们会做超过100万笔的交易。” 很清晰不是吗？
但是，现实生活中的大多数情况会更复杂混乱。下面是《Why Companies Need to do a Better Job of Prioritizing Features》推荐的按成本节省排序的技巧：
-
任何间接节省时间的功能，都会降低成本，例如自动化手动任务。调查你的客户手动执行该任务的时间花费，并用这个人的“成本/小时”来算出成本节省的数字。
-
砍掉一些功能有时可以节省成本。举一个例子，公司推出仅有核心功能的“轻量化”版本软件。更少的功能 = 更少的维护成本。
-
创建开放的API，允许开发人员创建功能可以节省成本。这是因为功能开发的任务转移到了开发社区中，这意味着个体的开发人员会承担资金提供并支持这个插件。
后记
如果一切任务都是高优先级,那么就意味着没有优先级。
以前读到一个日本程序员的段子：产品经理就是客户的家奴，程序员就是牲口，而且还是借来的别人家的牲口，使劲用。
如果每个项目中，我们都坚持按照MoSCoW方法排序，迭代开发，应该会幸福很多吧！
网友评论