由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