如何做需求分析,方法论+实践举例!

     分类 [产品经理]
2023/11/14 14:19:05 浏览量  1815 喜欢  56
导读:第200篇原创,需求分析是有理论方法遵循的

如何做需求分析,方法论+实践举例!

本文目录

1 需求分析的认知

2 需求分析的步骤

3 需求分析的方法论&实践举例

4 有什么小技巧

5 总结一下

 

前几天有个粉丝聊天,问了一个关于数据类的需求分析方法,说他工作中遇到的,如何给一个供求关系的数据提需求的指标定义,我简单回答了下,比如要明确需求,要有指标维度,要有量度数据等。
同时,我也想了下,作为产品经理,需求分析是一个最基本的工作,但这个工作,其实蛮多人会遇到问题,尤其是一些比较复杂的需求,或者深层次的,没有接触过的领域,不知道该怎么去分析。
所以,我们今天讲下「产品经理方法论」系列的第二节,如何做需求分析,我们拆分几个方面,方法论和实践举例相结合,尽量让大家更好地理解。
如何做需求分析,方法论+实践举例!
01 需求分析的认知
如何做需求分析,方法论+实践举例!
我们首先讲下需求分析的认知,一些比较基本的内容
1)什么是需求分析?
需求分析就是你面对的那一些需求或者问题,通过自己的一些分析,得到这个需求或者问题最底层的逻辑,进而输出一些结果。
从产品经理的角度来看,需求分析是一个至关重要的工作环节,它涉及到对市场和用户需求的深入调研、理解、分析和提炼,以找出真正有价值的产品需求,为后续的产品设计、开发、测试等提供明确的方向和输入。
说白了,就是用户提出需求,你需要将其转化为系统语言,怎么转化,这个过程就是需求分析。
2)需求分析的原则有哪些?
我挺喜欢的一句话,透过现象看本质,我觉得这个对于需求分析是真的很形象的概括。需求分析其实就是这个,你的用户对于需求的理解是片面的,或者说表面,你需要做的就是根据他的需求,去分析出背后隐藏的逻辑。
我们再细讲一下几个原则。
  • 以用户为中心:要以你的用户为中心,这是最核心的,所有的需求分析都要这样,因为你的用户才是你产品的使用者,对于你的产品才有最真实的话语权,你的产品要实现的目的也是服务于用户。
  • 实事求是:要客观、准确,不能过度解读,也不能太过于主观,是什么就是什么。
  • 要有整体思维:做需求分析不能只看这一个需求,要结合关联内容,有整体思维,很多需求是牵一发而动全身的,所以要多考虑下。
  • 符合市场趋势:尤其是商业化项目,需求是需要符合市场趋势,遵循市场规律的,你不能逆趋势而行,那就是无用需求。
  • 技术可实现性一定要考虑技术可实现性,在上一篇方法论我们聊过,需求不应该是天马行空的,要基于技术能实现,这个是很基本的。
  • 考虑成本:任何涉及到钱的都是大事,我们分析需求,是虑成本的,不能用户给你提个需求,我们得花很多资源和时间去实现,但是价值又很低,这个就很不划算。
  • 尊重用户:如果是定制化需求,用户付费的,那就是另外一个思维,尽量去满足用户,谁会跟钱过不去。

3)需求分析的内容有哪些?
我们可以去分析的内容:
  • 用户需求:这个是说得最多的,就是你的用户反馈的需求,可能是公司的,可能是外界收集的,比如说做用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度出发的需求。

  • 产品需求:定义为产品需求,就是产品本身存在的需求,由IT团队,或者公司层面战略规划主动发起的,这个反映了组织机构对系统、产品高层次的目标要求。

  • 功能需求:其实前面两个也算是功能需求,这个就是系统必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作,比如说权限管理,系统设置等。

  • 非功能需求:比如性能、响应时间、可靠性、容错性、扩展性等,这个属于功能之外的需求。

  • 界面需求:这个就是比较细的内容了,界面的设计,色彩搭配,布局等,或者说用户视觉需求。

  • 数据需求:比如说数据获取,数据存储,数据分析等,尤其是在AI时代,数据需求会变得更多,更加复杂,同时也会更加智能化。
02 需求分析的步骤
如何做需求分析,方法论+实践举例!
我们讲下比较通用的步骤

如何做需求分析,方法论+实践举例!

1)收集需求

首先第一步就是要去收集需求,需求的来源可能是用户,可能是IT团队,不管怎样,先拿到需求。
2)转化需求语言
拿到需求后,就要先将需求转化为系统语言,就是我们按照系统的逻辑去对应的,比如用户的需求想要一个展示销售数据的界面,那你就要想到系统,哪个系统,哪些数据,怎样分析,得到怎样的结果,怎样展示结果等。
3)判断需求真伪
转化为我们熟悉的语言后,就要看看这个需求的“真伪”,这个指的是需求是不是要做的,比如这个需求做了会影响整个系统逻辑,比如不切实际等等,这些都是伪需求。
或者说用户实际想要的内容并不是他说的,这个本质的需求也做不了,这都是要判断的。
4)需求归类
如果这个需求判断可以,能接收,那就要正式往下走了。
先将需求归类,是新增菜单,优化菜单,还是一些bug处理,用户体验提升等,不同的归类会产生不同的影响,对应的难度、工时那些都不一样。
5)价值评估
价值评估是个很重要的环节了,不管是内部需求,还是商业化项目,既然要接,一定是有价值的,要不然投入那么资源和时间处理,就是浪费。
价值可以按下面几个评估:
  • 实际产生收益
  • 功能使用频次
  • 数据重要性
  • 是否影响流程、工作
  • 降本增效情况
  • 需求紧急程度
  • 市场趋势
  • ...

6)难度评估
这个要结合其他岗位,尤其是技术实现难度,多跟技术去聊下,你看起来很简单的,在技术实现上可能会很复杂。
7)工时评估
或者叫成本评估,工时要综合评估,产品、设计、前后端技术、测试等,都要加上,一般几个岗位的工时比例,产品:设计:前后端技术:测试 = 1:1:(2~3):1,也就是技术的工时应该是其他的2~3倍,当然,也要看具体需求。
8)输出优先级
根据前面的价值和成本评估,我们可以生成一个四象限,可以看到左上角的应该优先级最高,就是