建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

kaverjody

发帖: 12粉丝: 10

级别 : 版主

发消息 + 关注

发表于2019年09月10日 11:15:10 2749 5
直达本楼层的链接
楼主
显示全部楼层
【DevCloud · 敏捷智库】如何进行需求优先级管理?

封面.png


需求优先级管理四步走

需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到如下几件事情:

  1. 确定优先级模型:优先级看起来像是一个简单直接的值,但实际上它是一个基于多种因素进行综合判断之后得出的一个值,这些因素和判断原则,就是我们所说的优先级模型;

  2. 排定需求优先级顺序:将需求代入优先级模型进行计算,得出每个需求的优先级顺序;

  3. 调整需求优先级顺序;

  4. 改进优先级模型:如果经常发生需要调整需求优先级顺序的情况,那么最好是对这些情况进行一定的复盘分析,如有必要,修正或改进当前的优先级模型,让它可以适应实际情况,以避免调整优先级顺序的情况反复发生;另外就是需求可能已经交付或发布上线,但是该功能的实际用量或价值不吻合预期,则需要反思我们对这些需求的分析和判断,究竟是分析判断有误还是优先级模型有误,并进行相应的调整;

一,确定优先级模型

成本收益分析就是最简单的一种优先级模型,重要/紧急的四象限也是一种优先级模型,Kano模型也是一种优先级模型,它们都可以帮助我们去确定需求的优先级顺序。模型可以简单也可以复杂,根据企业实际需要来确定即可。

务必切记优先级模型不应追求完美,以避免模型过于复杂,导致优先级管理的管理开销过高,喧宾夺主,反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要,就应该首选使用较简单的模型。企业可以从简单开始,逐渐完善,不需要也不应该在一开始就追求过于复杂的模型。

  • 简单可以体现在考虑的要素更少,比如成本收益分析只考虑两个要素,就比考虑更多要素的模型简单;

  • 简单还可以体现在要素的取值范围更窄或精度要求更低,比如预计利润只要求评估高//低,就比要求以万元为单位评估预计利润更简单;

    优先级模型确定后,可以进行存档管理,注意该模型宜供所有人或相关人员查阅学习,比如录入到DevCloudWiki知识管理系统就是一个很好的做法,如下图:

    1.png

二,排定需求优先级顺序

比如成本收益分析,可以是把预期市场收入作为收益值,把预期研发投入作为成本值,计算差值,或计算ROI均可。假设需求A预计收益为10万元,研发投入按人天折算预计3万元,那么预计利润就是7万元,预计ROI 233%;需求B预计收益为5万元,研发投入折算预计4万元,那么预计利润1万元,预计ROI 25%。那么需求A的优先级顺序就要比需求B更靠前。这种相差悬殊的情况往往不难判断,我们假设还有需求C预计利润也是7万元、预计ROI50%,以及需求D是预计利润1万元、预计ROI500%。那么ABCD这四个需求的具体顺序怎么排定呢?

如果真的出现这种情况,那就更复杂一些了,需要考虑引入权重,然后计算出一个综合值,这个值按照某种规则(例如从大到小)排列出来就是最终的优先级顺序,比如:


预计收入(万元)

预计成本(万元)

预计利润(万元)

利润权重

利润加权值

ROI%

ROI权重

ROI加权值

综合值

优先级顺序

需求A

10

3

7

0.1

0.7

233%

1

2.33

3.03

2

需求B

5

4

1

0.1

0.1

25%

1

0.25

0.35

4

需求C

21

14

7

0.1

0.7

50%

1

0.5

1.2

3

需求D

2

1

1

0.1

0.1

500%

1

5.0

5.1

1

 

根据上述表格中所得出的结果,我们就应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序,在DevCloud中,可以使用工作项的优先级顺序字段来实现,该字段取值范围1-100,如下图所示。

2.png

三,调整需求优先级顺序

调整顺序本身非常简单,只要在DevCloud中重新设定该需求的优先级顺序字段的值就可以。但重要的是,需要将优先级顺序调整这件事情记录下来,包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来,同样,建议记录在Wiki知识管理系统中。用于后续的复盘回顾中作为参考信息,比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。

3.png

四,改进优先级模型

市场在变化,用户在变化,产品在变化,优先级模型自然也必须跟随着发生变化。我们可以定期或不定期的安排对需求优先级模型进行复盘分析,找出可以改进或优化的点,并跟进落实。可以是定期开展,例如每个月进行一次复盘,把这个月所涉及的需求都拿出来审视,或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可;也可以是不定期,以问题驱动的方式,比如某天进行了大量需求优先级的调整,那么当天或第二天就可以临时召集一次复盘会议,分析为什么会发生这种情况。

复盘要有好的效果,就必须尽可能的复原问题发生当时的情况,所以前面提到的Wiki记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况,充分探讨。

复盘过程中,我们要定位出正确的根因,是模型本身设计有问题(例如要素和尺度),还是取值、加权有问题(比如某类需求的预计收入就是非常难估算),还是过程管理的问题(比如过早进行估算,因为缺乏必要信息,导致估算得出的优先级顺序不准确),并进行针对性地改进。

参考附录

相关文章

相关书籍

  • 杰拉尔德·温伯格:《成为技术领导者》

  • 邱昭良:《复盘+:把经验转化为能力》

敏捷

举报
分享

分享文章到朋友圈

分享文章到微博

努力变好

发帖: 0粉丝: 1

级别 : 注册会员

发消息 + 关注

发表于2020年06月22日 22:50:39
直达本楼层的链接
沙发
显示全部楼层

需求优先级管理四步走

1.确定优先级模型:优先级看起来像是一个简单直接的值,但实际上它是一个基于多种因素进行综合判断之后得出的一个值,这些因素和判断原则,就是我们所说的优先级模型;

2.排定需求优先级顺序:将需求代入优先级模型进行计算,得出每个需求的优先级顺序;

3.调整需求优先级顺序;

4.改进优先级模型:如果经常发生需要调整需求优先级顺序的情况,那么最好是对这些情况进行一定的复盘分析,如有必要,修正或改进当前的优先级模型,让它可以适应实际情况,以避免调整优先级顺序的情况反复发生;另外就是需求可能已经交付或发布上线,但是该功能的实际用量或价值不吻合预期,则需要反思我们对这些需求的分析和判断,究竟是分析判断有误还是优先级模型有误,并进行相应的调整;


点赞 评论 引用 举报

hw69058831

发帖: 1粉丝: 0

级别 : 注册会员

发消息 + 关注

发表于2020年07月11日 19:03:50
直达本楼层的链接
板凳
显示全部楼层

1.需求优先级存在的意义

Hozin说过:如果不考虑成本,用【梯子嫁接梯子】的方式也可以实现登月(成本极高)。

无论巨型公司还是小微公司,都会存在需求优先级,因为研发资源总是有限的,研发成本永远需要控制。

合理利用开发资源,实现【好钢用在刀刃上】,追求ROI最大化,是每个公司的追求。


2.需求体系是如何建立的

产品一旦启动,负责人(CEO、产品总监、产品经理)会事先牵头,产品、研发、运营、市场团队协商一致,拟定一个产品优先级;这种时序叫RoadMap(产品线路图),如果不发生意外,产品设计和研发团队会按照这个线路走下去。


3.需求优先级总是意外变更

然并卵,几乎没有任何RoadMap能严格执行下去,或许刚刚制定,马上就发生变化。


引起变化的原因很多,说几个常见的:

A.领导(CEO、投资人)的一句话,于是就变了。领导一定站的比你高,望的比你远,这个没错;

B.竞争对手逼着你改变,后续产品计划可能被竞品抢先上线,于是就变了;

C.市场资源、运营资源发生变化,本来公司打算做个蛋炒饭,但运营找到了做鱼汤的方法,结果产品目标就要从盘子换成盆;

D.研发成本突变,本以为简单的关键技术,实践后发现难度太高,需求必须进行妥协;

E.试错验证,原计划的产品价值根本不存在,商业模式走不通,需要进行颠覆调整;


4.产品人员是【需求过滤器】

产品狗,真的会咬人。实战中,每天会有大量反馈和各种【需求】扔到面前,通常产品人员会做这么几件事儿:


A .过滤那些伪需求

a1)有些用户天天喊饿,喂越饱他越饿,因为他是糖尿病,食物是伪需求,真需求是胰岛素;

a2)绝对不为1%的用户实现100%的功能,不是普遍的需求,不提供解决方案;

a3)有些需求通过运营手段能够解决,并不需要变更产品功能;

a4)一些需求的确能见到【蝇头小利】,但会损失未来更巨大的核心利益


B .扔进需求池,搞清楚成本与风险

b1)一些看上去简单的需求,可能涉及到巨大的开发量,比如核心算法改变,引起数据统计系统的偏差;

b2)功能可逆,数据不可逆;某些需求一旦上线就无法回滚,比如积分体系,要搞清楚风险;

b3)需求的变更,可能与正在开发提测的需求是相互矛盾的,废弃进行中的开发,代价几何;

b4)有些需求需要新开产品线,不仅仅是一个简单的研发问题,评估需求本身的成本就非常高;


C .了解并确认研发资源

c1)有几个研发小组?正在开发什么?即将完成的有哪些?提测的有哪些?

c2)目前正在提测的需求有多少bug是没有关闭的?何时能上线?

c3)新的需求需要开发多久,能争取到资源么?(越大的公司,争取资源越难)

c4)开发人员是否近期有离职异动,新需求能否争取到靠谱的开发人员?(别笑,这真是个大问题)


D.需求封闭机制

为了避免需求变化,很多研发团队是有需求封闭机制的,塞进去新需求很难,要分批次的等待。

------------以上,看完产品人员如何过滤需求,明白狗存在的意义。


5.对于创业型公司,通常Hozin对正在进行中的需求有如下排序:


A.最高优先级00:威胁到线上产品正常使用的
阻断式的bug,闪退,系统崩溃,明显的低级错误,存在安全隐患,泄露用户隐私
B.高优先级01:当前转化相关,开发代价较小
只需要简单调整就可能带来巨大转化提升
C.高优先级02:营收转化较好,开发代价较大
当前转化率较高,能带来营业收入,再提升转化需要付出巨大成本
D.中优先级03:数据统计类需求
使用现状反馈,对转化趋势判断的相关统计功能,帮助公司合理决策
E.中优先级04:运营效率需求
提升内部工作效率的各类后台产品功能,帮助公司节约运营成本
F.中优先级05:新产品线(新转化)的前置需求
比如打算新增一个视频播客的功能,无论如何是要先把后台数据搭建起来的,总有一些通用功能需要先搭建
G.低优先级06:新产品线(新转化)的试错
A/B测试类的产品功能,虽然开发量不多,但需要周密筹划,在需求阶段仔细推敲
H .低优先级07:所谓战略型需求

可能带来巨大营收,但运营没有准备好,市场也缺乏教育


I  .低优先级08:没有转化参照物的需求

当前转化率一般,并且即便提升转化率,也不能马上带来营收


此优先级方法不一定适合所有公司,不一定适合所有人,仅作参考。


点赞 评论 引用 举报

努力变好

发帖: 0粉丝: 1

级别 : 注册会员

发消息 + 关注

发表于2020年07月12日 14:58:01
直达本楼层的链接
地板
显示全部楼层

点赞 评论 引用 举报

yhl

发帖: 3粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年07月25日 22:24:18
直达本楼层的链接
5#
显示全部楼层
如何进行需求优先级管理?


1.看影响面

采用四象限看用户量和发生频率

优先解决大量用户的高频问题,基础体验

最乎解决少量用户的低频问题,超好体验


2.看开发难度和效果

采用四象限看开发难度和效果

优先见效快且开发难度不大的,这就是迭代

最后做很费劲而且见效慢的,这可能是未来的机会


3.看产品价值

这里的价值分为用户价值、商业价值、公司价值三个方面,在判断每一种价值时,考虑”满足了有什么好处,不满足有什么损失“,以此来做出综合判断。

①用户价值,就是这个需求实现了,能够影响多少用户,能够让多少用户更多实用产品。如果有数据指标,如果做了,数据能提升10%。而如果不做,数据导致一定比例的数据减少,长此以往必定流失用户。

②商业价值,对于有商业变现的产品来说,就是这个需求实现了,能带来多少收入。或者如果不做,会损失多少。比如对于内容产品来说,比如站酷网的增加广告新形态需求,基本有单子就一定会做。而对于商业化产品,通常就是那些能刺激用户的各种促销手段。

③公司价值,这里主要指对公司战略目标的影响,通常是产品目标,基本可以量化,比如日活翻番,如果某个需求实现能进一步实现目标,他的重要性和紧急性相对较高。

通常产品价值综合以上评估,通常以公司价值为主,兼顾考虑用户价值和商业价值。


4.看你对目标群体的熟悉程度

你是否深入了解用户使用场景?你对用户群体的理解是否足够了解?如果不熟悉,应该立马想办法去熟悉它。了解清楚以后做决策时更为理性而非拍脑袋。


基本了解以上4个依据以后,通常需先考虑产品价值,然后根据影响面和开发成本来考虑需求的优先级。

点赞 评论 引用 举报

Lhosv

发帖: 1粉丝: 1

级别 : 中级会员

发消息 + 关注

发表于2020年08月09日 23:31:30
直达本楼层的链接
6#
显示全部楼层

感谢分享

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册