比起重要紧急排序法,MoSCow优先级排序法更适用——项目开发篇

前言

这周新生大学全栈营线上班开始正式授课了。一开课,就学习到了很多有用的、好玩的概念。其中,拆解任务一章使用了:must have/ should have/ could have/ nice to have 模型。这个模型是从MoSCoW法则派生出来的。

什么是MoSCoW ?

MoSCoW 优先级排序法,是在项目管理、软件开发中使用的优先化技术。以便开发人员,产品经理,客户对每个需求交付的重要性达成共识。

Mo-S-Co-W,是四个优先级别的首字母的缩写,再加上O以使单词能够发音: 莫斯科。
比起重要紧急排序法,MoSCow优先级排序法更适用——项目开发篇_第1张图片
  • 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方法排序,迭代开发,应该会幸福很多吧!

你可能感兴趣的:(比起重要紧急排序法,MoSCow优先级排序法更适用——项目开发篇)