这周新生大学全栈营线上班开始正式授课了。一开课，就学习到了很多有用的、好玩的概念。其中，拆解任务一章使用了：must have/ should have/ could have/ nice to have 模型。这个模型是从MoSCoW法则派生出来的。
MoSCoW 优先级排序法，是在项目管理、软件开发中使用的优先化技术。以便开发人员，产品经理，客户对每个需求交付的重要性达成共识。
总的来说，”这次不会有”在项目讨论阶段，就会被去除。所有要求看上去都很重要，但是如果交货时间紧，“”可以有”将第一批被删除，”应该有”紧随其后。
我们从互联网产品开发的角度来分析：
微信、支付宝、滴滴…这些成功的产品已经具备很多功能，但是最初它们是靠着简单的核心功能（Must have）功能打开了市场。比如微信的语音信息、朋友圈，支付宝免费转账、付款，滴滴的打车功能。后来，他们都添加了琳琅满目的功能，但我们最常用的，还是那些最初的功能， 正是最初的Must have 功能吸引了用户，满足了用户的痛点，培养了用户 。
而一些失败的产品，常常一开始便拥有很多功能，美其名曰“全面”，以全面来打入市场。最终却是“样样做，样样差”，开发、运营团队都苦不堪言—— 目标太多，时间紧，配置跟不上，团队的注意力也都分散了 。
开发一款互联网产品，从调研、产品规划、设计、开发、到测试，再到推向市场，周期长，变数多。通常开发产品时，先做出最小化可行产品（MVP），然后通过测试并收集用户的反馈，快速迭代，不断修正产品。这样做，才能最终适应市场的需求。
而为了降低风险，提高速度，应尽可能的缩短每一次的迭代。如何缩短每一次迭代？其实很简单，尽量每一次循环、迭代， 只验证少量的核心功能（Must have），整个过程就会快起来 ，如果在一开始，就想很多，做很多，一次迭代下来的时间，会拉长，拖慢速度，增大风险。
先列出所有的功能，然后按照一定的规则，分为四类：“必须有’, ’应该有‘，’可以有‘， ’这次不会有‘ 。
那么按照什么呀的规则排序呢？在《 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》 推荐的按成本节省排序的技巧：
如果一切任务都是高优先级,那么就意味着没有优先级。
以前读到一个日本程序员的段子：产品经理就是客户的家奴，程序员就是牲口，而且还是借来的别人家的牲口，使劲用。
如果每个项目中，我们都坚持按照MoSCoW方法排序，迭代开发，应该会幸福很多吧！