大一大学全站营
莫斯科优先级排序法是一种用于项目管理和软件开发的优先级技术。以便开发人员、产品经理和客户能够认识到每个需求交付的重要性。
一般来说，项目讨论阶段会去掉“这次不行”。所有的要求看起来都很重要，但是如果交付时间很紧，“你可以有”就会删除第一批，后面是“你应该有”。
我们从互联网产品开发的角度分析:
微信，支付宝，滴滴...这些成功的产品已经具备了很多功能，但最初都是以简单的核心功能打开市场。比如微信语音消息，朋友圈，支付宝免费转账，支付，滴滴打车功能。后来都添加了琳琅满目的功能，但我们用的最多的还是原来的功能。吸引用户，满足用户痛点，培养用户，才是最初的必备功能。
而一些失败的产品往往从一开始就有很多功能，美其名曰“全面”全面进入市场。最终是“什么都做了，什么都差”，开发和运营团队苦不堪言——目标太多，时间紧，配置跟不上，团队的注意力也很分散。
开发一款互联网产品，从调研、产品规划、设计、开发，到测试，再到上市，周期很长，变数很多。通常在开发产品时，先做出最小可行产品(MVP)，然后通过测试和收集用户反馈对产品进行修改。只有这样，才能最终满足市场的需求。
为了降低风险和提高速度，我们应该尽可能地缩短每次迭代。如何缩短每次迭代？其实很简单。尽量在每个周期和迭代中只验证少量的核心功能，整个过程会变得更快。如果一开始想的多，做的多，那么一次迭代的时间就拉长了，速度就慢了，风险就大了。
先把所有的功能列出来，然后按照一定的规则分成四类:“必须有”、“应该有”、“可以有”、“这次没有”。
那么排序的规则是什么呢？在《为什么公司需要更好地对特性进行优先排序》一文中，作者介绍了三种方法:
这对于有风险的项目非常有用。风险未知。降低风险，最好是减少未知，用知识减少未知。以下信号将帮助你理解:是时候停止考虑这些功能，开始考虑降低风险了。
团队说，“我们不知道这是否可行……”
产品负责人表示，“不知道客户对此会有什么反应。”
架构师说:“我不确定这个平台是否支持这个特性。”
业务分析师说，“我还没搞清楚那部分需求。”
测试人员说:“我怎么测？”
对于上面的每一个例子，都是知识匮乏的明显信号，阻碍了相关人员满怀信心的前行。
举一个支付方式的例子:“用户体验模型显示，15%的人点击Paypal按钮完成支付过程。购物车放弃率也是15%。Paypal作为支付方式的实现将大大降低我们购物车的废弃率，并带来10%-15%的收入增长”。非常清楚，不是吗？如何计算该功能的潜在收益增长？
创建一个可比较的标准来衡量当前的收入差距。
量化潜在收入增长(百分比或美元)
将收入的增加(一年以上)与创建此功能的成本进行比较。
对于所有与增加收入相关的函数，都按收入递减排序。
“老平台每笔交易需要10秒，而新平台每笔交易需要7秒。把功能搬到新的平台上，每笔交易会节省30%的时间，我们每个月会做超过654.38+0万笔交易。”非常清楚，不是吗？
但是，现实生活中的大多数情况会更加复杂和混乱。以下是《为什么公司需要更好地为节省成本而优化功能》一书推荐的技巧:
如果所有的任务都是高优先级的，就意味着没有优先级。
之前看过一个日本程序员的笑话:产品经理是客户的家奴，程序员是动物，也是从别人家借来的。用力使用它。
如果每个项目都坚持按照莫斯科方法排序迭代开发，应该会快乐很多！