Posts Tagged ‘产品经理’

需求分析

September 21st, 2023

学习目标

  • 理解用户反馈的意义,并知道如何从不同渠道中收集用户反馈并识别关键信息
  • 借助思维导图工具的帮助,从用户-场景-解决方案的角度整理用户需求
  • 通过四象限和其他维度对需求进行优先级排序

本章任务

  • 需求分析及优先级排序

2.1 通过用户反馈解决问题

2.1.1 通过用户反馈关注什么?

自身产品的问题

竞品的问题

可能的机会点

2.1.2 通过哪些渠道来收集用户的反馈?

2.1.3 用户反馈不同渠道的处理策略

AppAnnie、应用雷达、ASO114、CQASO等

2.2 如何处理不同渠道的反馈

2.2.1 应用商店评论与用户反馈

监控应用商店监控什么?

低分差评:重点看1~3分

有效评价:重点看实际描述的评价

异常行为:比如水军刷榜、恶意评价

竞品变化:监控竞争对手的应用变化

2.2.2 微博贴吧与用户反馈

主流平台:微博、贴吧、知乎、雪球

依据产品类型的不同选择不同的用户群所在平台

  • 爱股票、雪球
  • 豆瓣、简书
  • 抖音、快手
  • 懂球帝、虎扑
  • 宝宝树、半米孕期

工具:关键字+收藏夹、微博企业版、百度、Google等

2.2.3 通过用户咨询、投诉发现问题

内容来源:客服后台、录音、意见建议、用户反馈、邮件等

2.2.4 通过用户点评发现问题

差评:为什么差评?原因、现象是什么?

描述:重点看有实际描述的评论

异常行为:比如是否有刷好评的行为?有没恶意评价行为

2.3 思维导图法整理需求

2.3.1 产品设计的核心三要素

  • 产品设计,就是不断解决用户在特定场景下的需求
  • 增加、减少功能并非关键,关键能不能解决用户的问题

 

当需求分析遇上思维导图

用户 场景 需求

2.3.2 思维导图的思考方式

  • 用户:当想到一个功能,先不要想怎么实现的,而是想谁会用
  • 场景:用户分别在什么情况下会用(感兴趣)?
  • 问题:用户分别在上述场景下,碰到什么问题(挑战)?
  • 方案:用户现在的解决方案是什么?

2.3.2.1 第一步:潜在用户有哪些

谁会对优惠码感兴趣?

思维导图,列出所有感兴趣的人

不用思考行不行,把能想到的穷举

2.3.2.2 第二步:列出用户发生(感兴趣)的场景

针对每一类用户“分别”往下分解

把“什么情况”描述清楚,最好简单描述一个故事

2.3.2.3 第三步:不同的用户分别碰到什么问题

  • 注意是“分别”,不要怕重复
  • 不同的群体、不同的场景,问题都是不同的
  • 区分“问题”和“中性词”,如时间、价格

2.3.2.4 第四步:现在的解决方案是什么

2.4 用户-场景-问题-现有解决方案

2.4.1 关于【用户-场景-问题-现有解决方案】四要素的意义

「用户-场景-问题-现有解决方案」这四要素,其实是一个比较友好的沟通和表达工具。

1、它能够快速的将你和其它在来自不同行业,有着不同表达习惯,目前正处在不同语境下的同学,快速拉入到同一个语境里。

2、它能帮你拆分清楚,用户遇到的真正的问题是啥,是在哪种场景下遇到的,以及遇到后目前的现有的解决方案是啥。

 

拿三节课内部,班班和技术同学报bug这件事举例:

有些同学在报bug时,是这样描述他们遇到的问题的:

“遇到问题:作业提交后系统不点亮”

 

如果你这样和刚来公司,正在专心写代码的研发新同学报bug,他应该会一脸懵逼

啥叫不点亮,不点亮有啥问题?正常情况应该是咋样的,这个同学是在哪遇到的这个问题?你到底在说什么?

 

但如果,你用「用户-场景-问题-现有解决方案」的方法进行问题描述的话,研发同学就一下子有画面感了,也知道你具体在问什么了。

 

“遇到问题:小三三同学认真做产品P1第2周作业的时候,提交完作业发现截图中左侧红框的小标记没有被点亮,正常情况应该是被点亮以表示鼓励的,但是他一直提交一直不亮一直提交一直不亮,对于学习的积极性造成了严重打击。小三三同学目前很崩溃,决定进行不写作业了。希望研发爸爸们帮忙看一下“

 

这样的描述过后,研发同学就会在帮你解决问题时,就会很清晰了。

2.4.2 关于用户

用户是一个群体中抽象出共同特征的集合,如:一线城市白领、大学老师、18岁的少女。他们在特定场景中,可能普遍遇到相同的问题、产生相似的需求。

在需求分析中,用户是分析的源头所在,我们需要理解产品的目标用户具体是谁,才可以更好的提出产品上的方案设计。

不过,用户分类也更多是依靠常识,或者自己在该行业持续的经验积累。所以目前在P1的课程作业中,暂时不要求大家掌握用户分类这件事。咱们能大体的概括用户是谁就足够了~

 

这里也介绍下常见的一些基础用户分类方法:用户分类有很多可以参考的维度,可以按照基础属性,比如年龄、性别、教育程度来进行分类;可以按照产品使用习惯,比如新老用户,付费/未付费用户进行分类;还可以从消费能力、兴趣爱好、社交关系等角度来分类用户。如果产品本身存在多种特定的用户角色(比如电商平台就有商家、消费者、平台运营方等至少三类角色),也可以考虑把这些不同的角色作为用户分类的依据之一。

 

尽管用户分类的维度五花八门,我们还是可以回归到用户分类的目的——是为了更有代表性的列举出场景和问题,以便于接下来进行需求优先级排序与产品的解决方案的思考——这也是用户分类的核心依据。

2.4.3 关于场景

场景:用户要使用一个互联网产品都有着其所附属的外在环境(比如时间空间)与内在心理状态(比如各种情绪),这些因素共同构成了产品的典型场景。

对于一个产品经理,「场景」是要经常挂在嘴边的词语。对任何产品的分析、用户问题的描述,都要是在一定场景下进行的。脱离场景的产品设计很可能没有办法解决真实场景下的用户问题。

我们一起来看看场景的例子:

场景的例子:

  • 暑假某日,下午3点,烈日高照,我和队友在操场上踢比赛
  • 期末时期,我在图书馆复习功课
  • 周末下午1点半,我和对象到附近万达广场逛街

很多时候,场景和问题容易混淆,我们接下来也看看问题与场景的区别是什么。

 

2.4.4 关于问题

问题是用户在特定场景下完成某个任务过程中出现的,有些人也直接将问题理解为用户需求或痛点。

「问题」的例子(句子中加粗的部分):

  • 暑假某日,下午3点,烈日高照,我和队友在操场上踢比赛,场上的队员们很快身体就接近脱水状态了,需要补水
  • 期末时期,我在图书馆复习功课,第5章的复习重点不知道是哪些
  • 周末下午1点半,我和对象到附近万达广场逛街,逛累了找不到合适的歇脚点

尽管以上的场景和问题拆得还不够细,但可以看出分析问题时,必须依托于场景。场景要能触发人的反应,才会产生需求/痛点。

  • 【生理】大夏天踢球-出水多渴了 -> 补水需求
  • 【心理】考前翻开书了-不知道如何下手复习 -> 备考指导需求
  • 【生理+心理】周末逛街-逛累了想聊天 -> 休憩&亲密需求

 

2.4.5 关于现有解决方案

这个概念很明确,就是他们面对问题做出了什么回应,不过需要注意的是,这个是用户现在这个时候所选择的解决方案,而并非未来产品可能提供的解决方案。此外,不知所措、无动于衷也是一种解决方案~

 

根据用户的现有解决方案,可以对比市场中是否已经有产品提供更优的解决方案了;若没有,对自己的产品来讲,很可能是个不错的机会。

2.4.6 与【用户-场景-需求】的联系

在没有相应产品功能的情况下,用户现有的解决方案可能并没有真正帮助用户解决问题,所以需要通过产品设计提供一个比用户现有解决方案更好的解决方案,来真正解决用户的问题。所谓产品满足了用户需求、产品解决了用户痛点,本质就是产品为用户提供了一个适当的解决方案。

 

当我们在以「用户-场景-问题-现有解决方案」的思考方式来分析需求时,目的是为了思考用户存在的问题有哪些没有得到解决,哪些问题的重要性更高,从而可以进一步思考目前的产品设计是否存在要解决的问题,以及未来如何通过产品设计提供更好的解决方案,帮助解决用户现存的问题;

 

而当我们用产品设计三要素「用户-场景-需求」来分析产品时,出发点是分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。

 

比如:

“小明在电商公司里担任产品助理,最近618,公司里的业务同学常常加班。但是他们公司又在郊区,上下班非常不方便。每当小明深夜加班到2点的时候,打开滴滴出行,想打快车回家时,就总是打不到“ 像这样的描述方式,就是 用户场景问题现有解决方案的运用~

 

而”小明同学最近常常在公司加班,备战公司618大促。每到深夜2点下班的时候就打不到车回家。这个时候小明同事给他推荐了嘀嗒出行这款产品,说用这个app在深夜打出租车的时候特别方便快捷。“

 

“嘀嗒出行满足了小明在深夜2点加班后,想打车回家的需求”这句话的描述,就是 用户场景需求的描述运用~

 

这两个描述方式,本质上表达的都是用户需求

不过,用户场景问题现有解决方案这种描述,可以更好帮助我们去思考清楚,当前产品还存在哪些问题,产品有没有办法提供给用户更好的解决方案。

而用户场景需求的描述,更多是用于分析产品目前的功能/解决方案是如何解决用户之前发生的问题的。

2.5 需求的优先级排序

四个维度

2.5.1 四象限看用户量与发生频率

  • 优先解决大用户量的高频问题,基础体验
  • 最后解决少量用户的低频问题,超好体验

某垂直电商平台

2.5.2 开发难度与见效快慢

  • 优先见效快且开发难度不大的,这就是迭代
  • 最后做很费劲而且见效慢的,这可能是未来的机会

2.5.3 产品价值

  • 迫切程度:用户是不是真的非常需要?还是空想的?
  • 付费意愿:用户是否会为了解决问题而付费?
  • ARPU:如果未来开发出来,用户会为之付多少钱?

2.5.4 你对目标群体的熟悉程度

  • 你是否深入了解用户使用场景?
  • 你对用户群体的理解是否足够里哦阿姐?

2.5.5 总结你的结论

用户:这个功能,第一批核心用户是谁?

场景:这个用户在什么场景下会使用?

问题:解决了这个用户最大的痛点是什么?

对比:和用户现在的解决方案相比,体验/效率提升有多大?

在不同的业务场景下,应该如何决定优先采用哪种排序维度呢?

需求的优先级并不存在标准答案,这里的四个维度是帮助你思考的框架。在不同的业务和产品中,优先级要考虑的因素可能差距也是巨大的。比如,对于银行系统的小伙伴来说,哪怕是一个影响面很小的安全漏洞,可能都必须要以第一优先级来响应。因此,结合自己产品的情况来组合成不同的排序四象限,是你在工作中可以思考的问题。

并且,这几个排序维度也是可以叠加使用的,比如先用用户量和发生频率筛选出第一象限,再用开发难度和见效快慢进一步缩小范围。

产品经理定义需求优先级的四种方法

September 14th, 2023

如何定义需求的优先级也是挺能看出产品经理的能力水平的,在上一节已经详细阐述了评估哪些需求该做,哪些需求不该做,对于已经决定要做的需求,这样的需求数量很多,是现在做,还是以后做,不可能在同一时间内全部研发完毕,总得有先有后,优先级高的需求优先研发,优先级低的需求延后研发,这样的话就涉及到需求优先级定义的标准了,在产品实践中,很多产品经理都是拍脑门决定先做哪些需求,后做哪些需求,要么就是老板拍脑门决定需求的优先级,那到底定义需求的优先级有没有原则和方法呢?

先来说说原则,在日常生活中,处理任务的优先级有四种情况:重要且紧急;重要不紧急;紧急不重要;不紧急不重要。这四种情况也是我们处理需求优先级的原则,即重要性+紧急性。把需求的重要性+紧急性统称为商业价值原则。基于这个商业价值原则,《神一样的产品经理》一书中主要阐述了需求优先级定义的四种方法。

1、新产品未上线

新产品未上线这种情况指的是产品从无到有的这个过程,这种情况因为没有相关的运营数据做支撑,所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的优先级定义方法,那么如何判断需求对用户的重要性呢?

一般情况而言,用户需求重要性:基本型需求>期望性需求>兴奋型需求。

使用需求的金字塔法则来表达,金字塔的最底层是基本型的需求,往上是期望型需求,最上面一层是兴奋型需求。基本型需求是必须有的需求,没有的话用户基本使用不了产品,如果金字塔最底层被砍掉的话,这个需求的金字塔就可能站立不稳而倒下,所以基本型需求的重要性最高,期望型的需求是用户期望能有的需求,用户希望越多越好,但是如果金字塔的第二层被砍掉的话,需求的金字塔不会受较大的影响,因为最底层的需求还在,用户还能继续使用产品,所以期望型需求重要性要低于基本型需求。兴奋型需求是超出用户预期的需求,有的话可以给产品加分,没有的话也无大碍,如果我们砍掉金字塔的最顶层,需求的金字塔更加不会受到影响,因为基本型需求和期望型需求都存在,用户还能继续使用产品,所以说兴奋型需求的重要性要低于期望型需求。其实我们从金字塔的建造过程来看,也是先建造最底层,然后是中间层,最后是最高层。

需要特别注意的是每个用户心里的基本型需求、期望型需求和兴奋型需求是不完全一样的,是千差万别的,比如说有的用户认为期望型需求是基本型需求,而有的用户认为兴奋型需求是基本型需求,这也随着时间在动态变化,甚至衰减,所以产品需求优先级的定义也要根据当时的实际情况来定。

是不是明确需求的重要性之后就可以判断需求的优先级了呢,这里面还需要加上一个因素,即紧迫性。基本型需求重要性最高,且也最紧迫,所以基本型需求的优先级默认是最高的。

一般情况下,肯定是先做基本型需求,在研发基本型需求的同时,有时候因为运营、营销、销售等业务需求的迫切需要,会同时研发一部分的期望型需求(重要不紧急)和兴奋型需求(紧急不重要),主要是制造产品的亮点和卖点,在市场上与竞争对手形成差异化或者品牌区隔,也有利于产品上线初期凭借期望型需求或兴奋型需求赢得用户良好的口碑。

案例:用户需求优先级排序

案例来源于腾讯公司内部的产品培训。1998年,QQ开始规划,1999年2月Beta1,1999年5月Beta2,1999年8月Beta3。

请排版本Beta1,只能实现3个特性:

  • 1、卡通头像
  • 2、不可窃听安全通讯
  • 3、聊天室
  • 4、很小的.exe文件
  • 5、皮肤skin
  • 6、速度超快0.5秒反映
  • 7、聊天记录管理器
  • 8、语音
  • 9、视频
  • 10、看谁在线上
  • 11、传文件
  • 12、QQ表情

这道题难倒了很多产品经理,很多产品经理考虑到当时的网络环境和背景,对这道题的答案有较大的分歧。在这里提供两种解答方法,一种是基于腾讯当时实际情况的解答(从当时角度出发,比较现实),一种是基于智能手机金字塔的解答(从现在角度出发,比较理想)。

(1)基于腾讯当时实际情况的解答

笔者跟腾讯公司最早的一批产品经理韩宇宙Punk,曾昭朗Paul和胡俊智Kinzeer曾经探讨过这个问题,给出了当时的答案是1,3,10。至于为什么选择1,3,10?从当时角度出发,理由阐述如下:

在当时情况下,早期的IM竞争对手有,有13家左右,各有一些特色,从单纯的功能上而言,QQ的功能并不突出。真正促使QQ让用户很HI的主要有两个地方:

第一个是卡通头像,让用户活了起来,它不算是啥功能,但是是用户情感需要很重要的出口。当时QQ的头像第一批用的是迪斯尼的,因为用户对这个经典头像熟悉,容易对号入座,有情感认知。当时都是70后嘛,这一代对迪斯尼,蓝精灵等比较熟悉。这些在当时选型时,都有考虑的。

QQ和其他IM不一样的地方,是有一个聊天室,而且是客户端形态的,所有的IM都要解决一个问题,就是用户从哪来。QQ聊天室解决了用户从哪来的问题,因为早期的用户习惯聊天室,对IM还不熟悉和习惯,更谈不上熟人关系。当时的环境和现在不一样,用户上了QQ后,用户的QQ上没有人,所以聊天室,是早期QQ用户聚集的地方,并因此互相加好友,从陌生变熟悉。其他IM的用户关系,一直是相对陌生的,而QQ的关系链是从聊天室的陌生,转化为比较熟悉,是有一定的社区关系的,然后再相互加一下QQ,很好的解决了用户QQ上没有任何好友的问题,有了好友,用户才会持续用QQ。最重要的需求在于怎么解决用户持续使用QQ,所有的功能先围着这个来转。QQ客户端的聊天室是客户端形态,因此聊天室的体验比当时Web 要好很多,功能强很大,而且还引入了社交化的体系,还有金字塔管理体系,让大量的用户每天都进入固定的聊天室相互熟悉,泡妞,有很强的成熟感,这批用户后来也成为QQ论坛的核心用户。聊天室为QQ用户贡献第一批好友,有点社区关系的好友。由于有这些好友,才有持续的动力上来和这些好友进行互动。

一开始,QQ安全性很低,随便都能偷QQ,用户都还不习惯用这个产品,做得再安全又怎么样,关于安全这东西,在早期的互联网用户上,不存在这个考虑。不要用现在的安全意识来评估当时的环境。性能的话,从技术的角度咯,当时的机器就那样,软件再怎么优化也是看不出来的。第一代的密码保护是02年底才有的,02年之前的QQ暴力破解就可以得到本地密码的,很弱。03年之前的密码保护也很弱,随便进后台就可以更改密保和密码。当时的IM还太技术化,但产业环境和用户习惯未到那个层面。比如说音频视频这东西,说真的,当时56K猫上网,支撑不了这个,大家都不用,并且网恋的风行,使文字聊天更有想像空间。

正如马化腾所说的:“exe小是结果,不是规划出来的,第一个版本想写成大也写不出。简而言之,10秒内找到人聊,且头像有趣是最朴素的需求,还有一个是好友保存在服务器端,换电脑也可以恢复。”

总的来说就是表情头像让用户很HI,毕竟要找人聊天,得知到谁在线上,而聊天室解决的是用户从零关系到弱关系再到强关系的问题,解决了第一批种子用户的问题。

从某种程度上来说,在当时环境下,卡通头像属于用户的兴奋型需求,聊天室属于用户的期望型需求,看谁在线上属于用户的基本型需求。

产品跟运营是不分家的,从这个案例可以看出,虽然是新产品未上线,但是已经开始有以运营为导向的元素出现,因为运营需求的迫切需要,研发一部分需求来制造产品的亮点和卖点,在市场上与竞争对手形成差异化或者品牌区隔。

在介绍KANO模型的时候也阐述过用户需求是一个随着时间在动态变化的过程,如果以现在的角度来选择最重要的三项特性,可能就不是1,3,10的答案了。

(2)基于智能手机金字塔的解答

使用金字塔的需求层次来解答这道题目,上面已经阐述过智能手机的需求金字塔,如何评定哪些需求是基本型需求,从现在的角度和环境出发,简单方法就是:砍掉这些需求,这个产品还能用么?

砍掉卡通头像,产品还能用,产品刚开始的时候使用普通头像也是可以的。砍掉QQ表情,产品还能用,不影响使用。没有聊天记录器,就不能使用QQ聊天了吗?显然是可以的,这也解释了MSN的聊天记录保存功能并不是默认帮用户勾选上的。很小的.exe文件,在这方面分歧比较大,很多人说当时是用猫拨号上网的,网速很慢,很多人认为很小的.exe文件是最重要三项中的一项,是这样么?答案不是,试想一下,一款网游好几个G,文件很大,网速虽然慢,但是用户就不去下载了吗?显然用户还是会去下载使用,再想一下,每一个新产品刚推出的时候,都是比较笨重粗糙的,比如以前最初的计算机庞大得可以占用整个办公室,携带非常不方便,回过头来再看看今天的电脑,小巧、轻薄了很多,所以说很小的.exe文件不是最重要的三项之一,可以理解为从用户体验角度来说,文件太大,用户获取的成本稍微有点高,但是用户体验的层次是有用、能用、可用、用的爽和品牌,文件虽然比较大,但是还能用,产品前提的条件是有用。聊天室是多人聊天,一对一聊天的需求还没有满足,就去满足多人聊天需求,显然也不合理。砍掉传文件的功能,产品照样能用,用户之间还可以发文字信息沟通。视频语音也是同理。这样分析下来,反映速度快、安全性和看谁在线上是最重要的三项,这跟智能手能的金字塔需求也是匹配的。如果反映速度太慢,基本上是用不了,用户在使用过程中会崩溃。如果1.0的版本很容易就被黑客攻击,导致瘫痪,照样也使用不了,再说了,QQ上都是自己的社交关系联系人,是比较隐私的,一旦被人盗用不堪设想(尤其是2011年12月震惊圈内的因黑客攻击导致知名互联网公司密码泄露的“密码门”事件,无疑给网站主敲响了网站安全的警钟,提高了安全需求的优先级。)。要想跟人沟通,首先要知道谁在线上,这是最基本的。

此外,在产品实践中,很多产品的成功具有时效性,有的产品在当时的环境虽然成功了,但是在现在的环境下复制这种曾经成功的模式,不一定见得会成功,所以通过QQ这个案例,至少可以得出三点结论:一是需求优先级的定义要基于当时的环境和实际情况;二是用户需求是一个动态变化过程,需要适时调整;三是产品与运营不分家,在确保满足基本型需求的同时,也要适当考虑满足用户期望型和兴奋型的需求。

2、免费型产品已经上线

免费型产品已经上线这种情况指的是全部免费型产品(全部功能免费)或者部分免费型产品(有些功能免费,有些功能收费)从有到优(调优)的这个过程,这个时候因为有了运营数据的支撑,通过运营数据,能聚类分析出用户的行为,甚至可以给用户画像。那么如何定义需求的优先级呢?这里还是采用需求的商业价值原则,即重要性+紧迫性原则。前面已经阐述过,用户有需求,产品利用相应的功能或内容来对应和满足需求,可以根据功能的使用率,使用次数和重要性,形成一个需求重要性的计算公式,根据计算的结果和紧迫性来定义需求的优先级。

现在互联网和移动互联网产品形态很多,比如Web、桌面客户端、第三方平台App、WAP、iPhone客户端、Android客户端、iPad客户端等等,用户对每一种终端产品的需求是不一样的,所以不能机械地认为用户对各种终端产品的基本型需求、期望型需求和兴奋型需求是一样的,这里要区分对待。对于要做跨终端产品的公司尤其要注意。比如,在使用Web 产品时,可以使用鼠标滚轮滚动页面阅读隐藏在下面的内容,能不翻页就尽量不翻页,因为用户比较习惯;而在iPad客户端产品上,从上而下滚动页面,需要使用手指自下而上滑动,用户使用起来有点别扭,很多App产品,尤其阅读型产品,改成了手指自右向左的横向滑动阅读未读的内容,用户使用起来比较自然。

用户需求重要性的判断标准:用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋型需求三类。

对于基本型需求,比如产品的性能、安全、浏览器兼容等方面,一旦出现问题,用户不能访问使用产品的情况,应该立马放下手头的工作,利用一切可利用的资源尽快解决这方面的问题,在有的公司称为“911bug”,属于最高级别的bug,优先级最高。比如说网站被黑了,或者使用起来非常慢,用户快崩溃了,这个时候应该想方设法尽快解决,试想一下,如果用户访问或使用不了你的产品,即使你的产品功能多么地强大,做得多么地好,用户也享受不到啊,这个时候如果还是投入资源做期望型需求和兴奋型需求,等辛辛苦苦做完了,用户也就流失掉了,这是一个常识。

对于期望型需求和兴奋型需求,可以通过运营数据,形成公式计算。

需求对应相应的产品功能,用户需求重要性=功能使用用户百分比(用户使用率)x功能使用次数百分比(功能或内容使用率)x类别重要性百分比(期望型需求、兴奋型需求),注意:最底层的基本型需求不在计算范围内,因为默认为最高级别。这个需求级别公式就是综合考虑有多少用户需要、用户经常需要还是偶尔需要、对用户重要还是不重要三个因素。

比如说有功能相对来说类别重要性虽然高一些,但是使用该功能的用户数和用户次数却比较少;有的功能相对来说类别重要性虽然低一些,但是使用该功能的用户数和用户次数却比较多,那么根据上述公式计算后得出的结果有可能是类别重要性比较低的功能整体重要性要高于类别重要性比较高的功能整体重要性。

关于计算公式举例:A功能属于期望型需求,在一定时期内,假设总的用户数有100人,其中有50人使用过A功能,那么A功能使用用户百分比就是50/100=50%,在这50人使用过程中,一共使用了10000次,那么使用次数百分比就是10000/50=200,类别重要性百分比,假定期望型需求是50%,那么A功能级别数值=50%×200×50%=50。

B功能属于兴奋型需求,在一定时期内,假设总的用户数有100人,其中有30人使用过B功能,那么B功能使用用户百分比就是30/100=30%,在这30人使用过程中,一共使用了90000次,那么使用次数百分比就是90000/30=3000,类别重要性百分比,假定兴奋型需求是25%,那么B功能级别数值=30%×3000×25%=225。

可以看出B功能级别数值225要大于A功能级别数值50,所欲B功能的整体重要性要高于A功能。

对用户来说,基本型、期望型与兴奋型需求并不是一成不变的,是一种动态的变化过程。并且运营数据也在不断地发生变化,需要及时作出相应的调整!

是不是明确需求的重要性之后就可以判断需求的优先级了呢,这里面还需要加上一个因素,即紧迫性。还是得按照先做重要且紧急得需求,后做重要不紧急的需求,再做紧急不重要的需求,最后做不紧急不重要的需求。

3、收费型产品

收费型产品指的是已经上线或者未上线收费型产品(全部功能收费)或者部分收费型产品(有些功能免费,有些功能收费)。在这特别说明一下,收费型产品的需求也主要是期望型需求和兴奋型需求,因为基本型需求的优先级默认是最高级别的(重要且紧急)。

一般情况而言,收费型产品是公司的收入来源,如无特殊情况,在同等条件下,一般收费型的功能优先级要高于免费型的功能优先级。那么收费型产品的优先级如何定义呢?定义的标准就是商业价值,即重要性+紧迫性,这里的重要性主要指的是经济收益(将战略上的收益也归结经济收益,包括有形的和无形的收益),经济收益高且紧急的功能需求先做,经济收益高且不紧急的功能需求后做,紧急且经济收益不高的功能需求再往后做,不紧急且经济收益不高的功能需求最后才做。

4、前置后置条件

前置后置条件指的是有时候必须先完成A功能,然后才能做B功能,从需求的优先级来看,A功能的需求优先级肯定要高于B功能的需求优先级。A功能的重要性和紧急性都要高于B功能。

总的来说,上述四种定义需求优先级的方法,在公司范围内,在特定的产品阶段,是可以搭配使用的。需求优先级定义的原则基本上是一样的,都是商业价值原则,即重要性+紧急性。

不管在哪一种方法下,基本型需求的优先级永远默认是最高级别的,至于期望型需求和兴奋型需求要根据具体的实际情况使用方法的一种或几种方法搭配使用,而不是再用拍脑门来决定需求的优先级。特别注意的是,上述的内容都是围绕需求的优先级来展开的,是从产品人员的角度来说,但是从研发人员的角度来说,毕竟受到各种人力、物力、财力的限制和影响,并不能完完全全按照产品人员确定的需求优先级来进行研发,基于产品人员确定的需求优先级,研发人员基于开发资源提出相应需求优先级的研发优先级。至于研发优先级如何定义,将在下一节管理需求中作详细阐述。

REF