如何分析与筛选需求呢?

很多产品经理去面试的时候,可能都碰到过这么一个问题:
在过去的产品工作中,你是如何评估需求的?哪些需求该做?哪些需求不该做?评估的标准又是什么?
有些产品经理可能会说依靠自己的产品直觉,拍脑门进行决定;或者是老板决定后,产品经理来执行。这两种方式有其一定的道理和适用场景,不过都并不适合产品新人,一是因为产品新人对市场情况、用户需求的不了解,并不能有很好的产品直觉;二是如果每次直接都是老板拍板。久而久之,你也就成了执行的机器,而丧失了独立思考的能力。

作为产品新人,我们可以借用其它靠谱的分析理论来进行需求的分析和筛选工作。

1、筛掉不合理的需求
哪些是不合理的需求?比如当前技术不可能实现的或者是明显意义不大的,投入产出比比较低的,无匹配的产品使用场景的,明显不合理的需求等,都可以归类为不合理的需求。

2、再来看如何做需求分析
把明显不合理的需求排除后,我们就需要把剩下的需求一个一个进行分析了。
首先要了解需求的三个分类:用户讲述的、用户实际想要的、用户的潜在需求,这是三件不同的事情,却又有着千丝万缕的联系。我们需要通过用户描述的需求,找到用户实际需求,发掘潜在需求.

举个例子:
一天晚上,小明和妈妈走在回家的路上,突然小明感到饿了,闹着妈妈说:“妈妈,妈妈,我要吃肯德基,我要吃鸡腿。”但是附近没有kfc之类的西式快餐店铺,妈妈有点犯愁,怎么办呢?但又不能饿着小明,妈妈突然想起来早上路过面包店买的面包还在包里,便拿出面包给小明充饥,小明一看还有面包,于是很高兴地开始吃了起来。

我们按照需求的三个分类来分析一下这个问题:
用户描述:想吃鸡腿
用户实际想要的:饿了,只要有好吃的都行
用户的潜在需求:饮料?水果?

3+1思考法分析用户需求

这个故事相对来说比较简单,但是也比较具有代表性。孩子不是很能表达自己的需求,但是妈妈很了解自己的孩子,所以能找到孩子的实际需求,在我们的工作场景中,我们也要多花些时间了解我们的用户,同时可以参考借鉴一下阿里巴巴前CEO卫哲的“3+1思考法”去分析用户需求:

1、需求从哪里来,目标用户是谁?到底是我们想做,还是客户想要,亦或是老板想要,给谁解决问题;
2、有多少人有这样的需求?这个需求紧迫吗?有多少人有这样的需求意味着市场的容量,紧迫程度意味着解决需求的价值;
3、用户的痛点是什么?使用场景是什么?(用产品之前/后)解决了什么问题,不解决会存在什么问题,用户问题的使用场景我们是不是真的找到了;
+1 、怎么验证需求是否解决与解决效果?解决之后在网站数据上会有什么表现?是网站数据提升了,还是用户反馈效果比较好。

不知道大家有没有一个感受,就是虽然产品在不断的更新迭代,但是需求还是会源源不断的增加,感觉怎么也不会减少。这时候就需要用需求池这个工具,来管理这些源源不断的需求了。

需求池是什么?

需求池≠需求管理,却是需求管理过程中很重要的一部分
需求容器直白的来说,需求池就是个需求容器,不同来源的各种需求都可以经过简单评审后记录进需求容器,进来之后的需求进行再次的评审,最终决定这个需求的去留。经过再次评审后留下来的需求,可作为下个版本发布的内容或下几个版本迭代的内容,目的是确保在做版本规划时有足够的需求来源,而不仅仅的靠自己盲目的规划。

需求池管理有两个原则:有进有出、宽进严出。

常见的需求池工具
Excel:个人很好,很方便,团队不方便
在线文档:石墨文档
Teambition:团队很方便,不如Excel直观,必须要求团队也一起用

需求池有哪些要素?

编号
编号就是需求列表的顺序号,主要是作为当前需求的唯一性标识。

优先级
需求池中的需求优先级可以用重要和紧急两个维度初步进行确定哪个需求的优先级更高。通过需求评审后的需求,优先级更应该按照1、2、3、4的顺序进行排列。

功能模块
根据现有的产品模块进行分类,初步判定此需求属于哪个功能模块的类别,若是新增业务功能,则此项可以待定不填写。

需求类型
需求类型主要是记录此类需求属于哪一个类别的,前期需要定义好需求类型有哪些?主要需求类型有:新增功能、功能改进、体验提升、BUG修复。

需求详情
如果是比较简单、不复杂的小需求,直接描述要解决什么问题。如果不是小需求,则不仅需要描述要解决什么问题,还要把为什么要解决问题的原因一并记录下来。(解决问题的原因,多数情况下需要产品负责人刨根问底的去问,去了解实际上用户的需求到底是什么和想解决怎样的用户需求)

需求来源
直白的理解就是此需求从哪里来,是谁提了这个需求。

需求添加时间
此需求添加到需求池的时间,而不是需求提出人初次提出的时间。

状态
状态:排期、暂缓、搁置、待讨论、已解决。排期的需求基本上下一步就是进行版本规划了,定哪个版本上线、版本什么时候发布; 暂缓代表着需求已经明确,但没有确定什么时间,具体的版本;搁置说明需求意义不大,很长一段时间内不会考虑解决;待讨论意味着需求未明确;

备注
备注其他任何信息,如:需求期望完成时间、被拒绝原因、暂缓原因、意向解决方案。

如何对一个需求做价值判断

如何对一个需求做价值判断,我认为,任何功能(解决方案)是没有价值的,功能背后满足的那个需求(问题)才是有价值的,但功能决定了成本,所以,选择用什么功能来满足需求也很重要。

最终,我们要看的是 性价比 = 价值/成本,凭此推出我们应该先满足哪些需求。

对需求的价值判断,还是基于两点:这个需求满足的是否是1. 核心用户的2. 刚性需求。

是否核心用户,细分了看,什么样的用户(群体)算?前提是这些人是目标用户。
人数,无疑是最重要的指标,以至于我们经常说“不要为了少数用户的需求去干扰大多数用户的正常使用”,其实这句话并不准确,修正的说法应该是“不要为了次要用户的需求去干扰核心用户的正常使用”。这是因为,我们还要看单用户价值,典型的,面向高端用户的发烧、专业产品,就是要鄙视、屏蔽大众需求以突显逼格的,所以,必须死贵死贵的。也许可以用“人数 * 单用户价值”得到第1点的简单结论。

再看是否刚性需求,常规的我能想到这么几点。
有无替代方案,如果没有,那恭喜,你解决了一个尚无解决方案的需求,必须算得上创新了,但这种机会可遇不可求,因为人类努力了这么多年,几乎“任何一个值得解决的问题,都已经有解决方案了”。但没关系,我们还是可以做的,“先抄后超”是很多团队的座右铭。这时候,需要考虑的是,相比替代方案,你提供了什么额外价值?额外价值大,显然是加分项。

思考题:对于汽油汽车已经满足的日常代步需求,Tesla提供了什么额外的价值?

发生频率(可以结合何时何地的场景来思考),频繁发生的需求,加分,一次性的需求减分。
持续时间,或者叫做这个需求的有效期,长则加分,反之减分。很多需求的有效期,其实只有活动那几天,所以,产品经理们是很不想做一个临时活动需求的,能挡则挡,挡不了也会思考,如何把这个活动需求做成一个通用模块,可以反复使用。

当然,凡事皆有例外,当一个有效期只有24小时、一年一次的需求碰到其他因素无比加分的时候,也很有价值,没错,我在说双11。

所以,以上因素,要综合考虑,但,还不够。

每个产品都应该添加一些自己的指标,即自己独特的加分项。这应该是在做产品的过程中,与你的团队一起渐渐形成的共识。比如“惊喜感”,往往是一些情感化的解决方案,能引起用户的心理共鸣;再如,大家都经常碰到的——“大老板”强烈要求做……也可以是。

客户满意度模型KANO

考虑完了需求的重要性问题,我们接下来考虑需求的紧迫性问题。
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。根据不同类型的质量特性与顾客满意度之间的关系,狩野教授将产品服务的质量特性分为五类:

  • 基本(必备)型需求——Must-beQuality/ Basic Quality
  • 期望(意愿)型需求——One-dimensional Quality/ Performance Quality
  • 兴奋(魅力)型需求—Attractive Quality/ Excitement Quality
  • 无差异型需求——Indifferent Quality/Neutral Quality
  • 反向(逆向)型需求——Reverse Quality

兴奋型需求
超出预期:用户也不知道的;例如:你第一次使用iPhone,谷歌、百度地图的时候。针对这类需求,它会成为你产品的亮点以及差异化的点,能极大的提高用户的满意度,但是同时也要付出大量的研发成本。

期望型需求
期望的:用户能够清晰知道的
这类需求与用户的期望契合度极高,该类需求实现程度越高,用户的满意度也越高。例如:汽车的行驶里程越远,用户的满意度越高;手机的储存容量越多,用户的满意度越高。针对这类需求,功能每提高一点,用户的满意度就可以提高,要集中投入。

基本型需求
必须具备的:及时不说也应该做到的;
这类功能需求属于用户的基本需求,这类功能做得再怎么好,用户的满意度也不会提升。但是,如果这有这个功能,产品又无法使用。例如:汽车需要有刹车;手机必须可以打电话。针对这类需求,当达到一定程度,你不需要再过多的投入。

KANO模型的基本思想:通过用户调研,测量每个用户对于每个需求功能点进行评价,然后进行无差异化的满意系数计算,得到一个优先级排序。KANO模型优点是量化明确,从用户角度出发,相对合理。不足之处在于,依赖用户调研样本,及调研过程中各种可能的差异。因此,实际工作中,这些用研结果仅作为一个需求优先级参考,与实际产品数据结合来运用。

KANO模型

通常情况而言,基本型需求的重要性最高,且也最紧迫,所以基本型需求的优先级默认是最高的。但是由于公司其它部门,如运营、市场、销售等部门业务需求的迫切需要,会同时研发一部分期望需求(重要不紧急)和兴奋型需求(紧急不重要)。

上面讲的是原始模型,现在改下说法,三条曲线从“功能”的角度去理解。

最下面一条曲线叫“基础(功能)”,没有的时候,用户对产品无法接受,有了,也不会夸奖你,用户会觉得这是理所应当的。所以,必须做,也叫“must have”,不管成本有多高都得做。在功能列表里,这种功能就不用参与pk了,比如手里的打电话、发短信,当然,也许多年以后不是了。

最上面的曲线叫“亮点(功能)”,没有的时候,用户也想不到,有了以后,用户会赞不绝口,wow,惊喜。比如手机的指纹识别,解决了安全(更多更复杂的密码、证书、外挂硬件等等)和方便这一对矛盾的需求。亮点功能的特性,使得我们在选择“做哪个”的时候有一个诀窍——挑选成本低的亮点功能去实现,比如苹果电脑的呼吸灯?不要费太大的功夫去做一个亮点——除非你在大公司的里的“研究中心、创新中心”。你认为的亮点到底能不能点亮用户,是要运气的,相比下面一种功能,它更像早期投资。

中间的叫“期望功能”,曲线比较平,也叫“nice to have”,这里体现出用户调研的局限性,如果我们简单的去问用户,只能获得“期望功能”,为什么,因为基础用户觉得你肯定有,不会提,而亮点根本想不到。那要让我们的产品更加丰满,怎么办?基础功能,我们说,要靠产品经理的领域知识来弥补,你是做手机的,就必须知道手机要能打电话;而亮点,就需要靠对用户需求、场景、人性的理解了,也就是我们经常所谓的“创造需求”,其实,你只是探究到了用户深层的需求,然后创造了一个解决方案。

基础功能只能消除不满,不能带来满意,亮点的重要性在于,有了,才有口碑传播的概念,没有亮点的产品,只会有人用,没有口碑。一个功能的类别,随着时间会变,一般从亮点到期望到基本,比如手机的彩屏、和旋铃声,在十几年前还是亮点,今天已经没人再提。所谓饱暖思淫欲,由俭入奢易……这也是人类创新进步的源泉。

需求转化

产品团队的一项日常工作就是采集的各种需求,并整理转化为产品功能,通常转化之前我们用Xmind较自由的表达,转化之后就成了需求池里的功能列表。采集到这个需求的产品经理,自己可以先“确定属性”,即这个需求是属于产品的哪个模块?是基本、扩展、增值功能?是功能、性能、用户体验方面的?等等,属性的维度大家可以按照产品的不同自由定义,原则是为了便于需求的管理。

这样我们得到的功能列表,就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发,拿出来大家一起过一遍,这是最关键的。我们的经验,商业价值由单个PD确定风险很大,所以这个步骤是团队集体讨论,再叫上有必要的干系人,比如销售、服务。对于商业价值可以从多个维度描述,并加权平均得到综合的商业价值,详细描述可参见单向需求卡片,但绝大多数情况下,我们发现只用一个值的高中低,或者5、4、3、2、1分来衡量就足够了。具体讨论的时候,大家充分表达意见,最终往往是会场上级别最高的人综合以后说一个数字,这是现实,也是一种高效的办法,我想过投票、群体打分的方式,可是实施起来成本太高。

注意一点,讨论商业价值的会议上,会把所有状态为“待讨论”的功能点都过一遍,散会的时候,它们的状态一定要变化,或是进入“需求中”、或是被“拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的,而暂缓的需求是“有价值,但是现在不做”的,通常要表明重启的条件,比如“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

对于状态变为“需求中”的功能点,下一步就是初定工作量了,因为需求不明确,所以只是简单的评估,和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。我们通常经历的项目,三大类人力资源是“产品、开发、测试”,用团队里的瓶颈资源做评估基准,所以我们一般评估每个功能点的开发工程师工作量,因为在我们的团队里通常产品、测试资源相对可以调配,这个大家视自己团队的情况灵活应用。具体的评估,通常是类似技术经理的角色来做,评估者按照自己做需要多少时间,乘以一个系数确定,这个系数一般大于1。

继续,既然对于每个迭代周期,我们有多少时间、多少人是早就知道的,那么可用工作量是多少“人日”,也就知道了。有了每个功能点的商业价值和工作量,很自然的就能算出性价比,简单的说即“商业价值/开发工作量”,我们把功能列表按照性价比从大到小排序,再对应考察每行评估出来的开发工作量,从上到下依次纳入项目,我们的可用工作量能做多少个功能点,一目了然。

上面谈到的这些,也就是一步步确定某个项目能做多少需求的过程。

需求打包

最后,我们把这些要做的功能点合在一起,把“需求打包”,再往下就要做这个项目的BRD了。BRD通过,立项之后,再全程跟踪某个需求的进度,上述整个过程就是一步步确定某个需求的各种属性的过程。

这个过程完全是定量的,也就回答了“做多少”的问题。但,真实情况哪会这么简单明了,下面再说几个需要注意的地方。

第一,需求打包最好打类似的功能点,是否类似取决于需求的属性,“确定属性”这步做的事情起作用了,一般来说业务上有逻辑关系的需求才会包含一个项目里,否则就是一个纯粹修修补补的“小需求项目”了。

第二,需求依赖,功能点互相之间有依赖关系,那没办法,只能先做某些功能,应该在功能列表里注明;功能点与人力资源之间的依赖关系也会经常存在,在这里评估工作量的时候不会考虑“谁来做”的问题,但是在后续立项,组建团队的时候需要注意,当然长期来说,为了避免这类风险,提升与平衡团队成员的能力是王道。

第三,功能点的粒度大小问题,商业价值很高的功能,如果细分的话,我们也会发现其中有价值相对低的部分,所以功能点的粒度应该尽量细,前提是细化引起的管理成本上升在可接受的范围内。具体细到多少,也只能具体情况具体分析。

总结:

分析与筛选需求:3+1思考法分析用户需求
需求池是个需求容器,包含编号、优先级、功能模块、需求类型、需求详情、需求来源、需求添加时间、状态、备注
对需求的价值判断:这个需求满足的是否是1. 核心用户的2. 刚性需求。
客户满意度模型KANO:基本(必备)型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求
从“功能”的角度看KANO:基础功能、亮点功能、期望功能
需求转化:讨论功能列表并需求打包