对于软件开发团队而言,软件开发的全过程是:做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署;其中,“做什么”对应的是需求分析过程,“怎么做”对应于软件架构设计过程,“做”对应于开发过程,“成果检验”对应于测试,部署由运维团队执行后,如果达到用户的要求,则软件上线后进入软件的运行生命周期。
而在实际的软件项目开发中,“做什么”,“怎么做”和“做”是紧密结合在一起的,“做”,“成果检验”和“交付部署”通常也会是一个持续交付过程,“成果检验”的内容会受到“做什么”的影响,开展“做什么”阶段的时候,也要考虑到如何部署和交付。所以软件开发的全过程,都是紧密结合在一起的,如果刻意划分为独立的几个阶段,忽视其作为一个整理的综合影响,每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题,从而影响整体开发效率。
今天,我们首先来谈一下软件项目中,需求究竟该怎么分析?
正确的需求分析决定了我们产品的方向,需求分析搞错了,做再多都是浪费。只有方向对了你才能走出迷途,方向错了,你只能迷失!基于此,我们的需求分析可分为两个阶段,第一个阶段是收集需求,第二个阶段是处理需求。
收集需求
需求的来源有很多,需求的处理方式也不尽相同。有效的收集需求,将收集到的需求去伪存真,是产品设计环节中最重要的一环,如同大厦的地基,地基不坚实,大楼是盖不起来的。而且我们在收集到需求时,要第一时间与用户交流沟通,尽量走到用户中去了解他们的想法,深入了解目标用户在真实环境下的感受,尽可能地挖掘用户的原始需求,充分了解用户真实场景,才能真正更好地服务用户,打造出他所想要的产品。
1、还原场景
如果只是单独看用户提出的需求,你很难分析到用户的真实需求,就像有些英语单词一样,你必须放到那个语境下面去了解,才能找到用户背后真实目的。
我们可以从以下场景进行分析:
基于什么环境:地铁/办公室/室内/公共场合/走路/夜晚/户外…深入情景周围的细节中去。
基于什么用户:具备什么特征,比如身份、收入、区域…
![](/qrcode.jpg)
基于什么行为:行为或操作流程,比如购物流程、操作习惯、行为认知…
场景分析也就是需要考虑具体什么环境(时间、地点、情境)什么类型用户的什么动机,想达到什么目标,以及人与人的关系。如实地分析记录下来,如果偏差或缺乏信息,之后的分析就会有所偏差。
2、多问几个为什么
用户需求的传递过程中总是存在着无法完全理解吸收的问题,导致所收集的需求不一定就是用户的真实需求,这时你需要做的是找到需求的提出人,多问几个为什么。这个需求提出人可能是用户,也可能是运营,也可能是技术,你多问几个为什么的时候,也就能发觉用户背后的需求。
3、数据分析
数据是客观反映产品的重要指数,也是收集需求的重要来源,前期收集的数据需要是可靠、客观的,而且数据是零散的,在进行数据分析前一定要有明确的中心,划定一个界限,收集同一个框架内的数,同时单独的数据是死的,有对比的数据才有意义。为了避免主观意识的影响,同一份数据可参考其他人员的分析结果。
4、多和别人沟通/头脑风暴
一个人的力量是有限的,当我们吃不准的这个用户需求的时候,可以把这个需求拿出来和用户讨论一下,进行头脑风暴一下,人多力量大么,当我们吃不准一个需求的时候,大家都认为的那个结果就是需求分析的结果。
处理需求
处理需求的阶段,也是产品经理将需求进行筛选,梳理业务流程,设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求,其中还是有很多需求是“伪需求”,甚至是不合理的,我们第一步就需要将这些需求进行“清洗”,择优去重、去伪存真。
2.设置优先级
一般来说,从需求类型来看,基本型需求>期望型需求>兴奋型需求;
从需求来源来看,战略性需求(用户提出)>功能性需求(核心功能)>业务性需求(拉活、存留)>体验性需求(提升用户体验)。需求优先级判断最常用的是用四象限法则去评定优先级,另外可以使用RICE评定方法,KANO模型等。
3.竞品分析
由于在这个阶段,产品经理不仅要定义目标用户、产品使用场景,还要确定核心功能,产品流程等等,因此通过竞品(如果有)来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求,与自己的需求进行对比;将自己的需求代入竞品中,看流程是否符合逻辑;与竞品进行对比,分析需求的异同。
4.需求评审
在这个阶段之前,作为产品经理对于产品应该有了一个完整的模型,但仅仅是理论上的模型,确保UI、UE、前端开发、后台开发、测试参与,从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。
需求分析是基于用户沟通、背景认知、人性理解,层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准,越有机会在后续产品设计给出合理的方案。