前言:面对千变万化的需求,也许很难抽象出一套普适的方法论,不妨一起来看看需求分析过程中的那些常见套路,或许能有一些值得借鉴和思考。
当我们接到一个新需求点时,应遵循的需求分析步骤有哪些?首先,要根据需求设计功能,就要做到理解需求的来龙去脉。为此,需要搞清楚以下问题:
1、需求产生的原因当需求方向你阐述完某个需求后,向她询问:提这个需求的目的是什么?即为什么会产生这个需求?这个问题帮你完全理解需求,帮你辨别需求的真伪。
2、需求使用场景即搞清楚什么人在什么情况下会用到此功能。只有明白了这个,才知道如何更好地设计功能来满足需要。
在需求场景模拟的过程中,为了避免设计的功能因扩展性不足,通过不断的推导,在一开始,就应该做尽可能全面的考虑。通过需求方的场景,扩展思考,是否存在衍生的场景。思考的过程,也是帮助你抓住和理解需求本质的过程。
3. 辨别真假需求不要谁的需求都听,每个人都有自己的想法,也有自己的需求,没有哪个产品能满足所有用户,系统分析需求之前应该先搞清楚需求提出人身份,是目标用户吗?是产品重度使用者吗?是功能服务对象吗?不是说来源不可靠的需求就完全不做分析,但这一点也需要考虑在你的分析范畴内。
我们接到需求后,充分理解了需求后,跟团队伙伴一起花个时间讨论一下,听听他们的意见和建议对需求的考虑。通过此过程,基本上对需求点及实现方式达成一致,在后期正式开发时,会减小很多阻碍
4、 需求解决方案当我们弄清楚了用户需求后,就需要提供一个产品解决方案来解决用户的需求,在提供解决方案的时候,我们不能只考虑用户需求,还需要考虑战略的需求,老板的需求,产品运营的需求,业务人员的需求,竞争的需求,作为产品经理自己本身的价值观需求等,基于这些需求,我们来构建产品,在这个产品方案里面会有很多产品的功能,这个功能就是我们常说的产品需求。
5、 开启版本迭代,细化需求提交需求就是把产品需求完整清晰的告知给需要协作的小伙伴,让他们清楚的了解产品的需求, 一般通过以下三个交付物来告知:
- 产品流程图
产品流程图是说明产品 *** 作和相应过程的文档,一般有两类:
一类是业务流程图,基于业务逻辑来设计,一般包含主要流程和功能模块,用来说明产品的架构;
另一类是功能流程图,一般基于用户任务来设计,包含人物角色, *** 作过程的关键节点,状态,判断,结果等
- 产品原型
上面的流程图主要偏重于对产品后端和逻辑的描述,而产品原型的作用正好与流程图互补,偏重于对产品界面信息架构,跳转逻辑和交互功能的展示说明,通过产品原型,可以将抽象的产品具体化,让产品更容易被理解,产品原型一般由线框图构成,在业界大部分人使用axure来制作,有的公司有交互设计师,原型制作工作由交互设计师来承担,大部分互联网公司是没有交互设计师的,所以产品原型一般由产品经理来完成,一般长下面这样:
- 产品需求文档
产品需求文档,简称prd, 主要以文字形式来阐述产品的详细需求,与流程图,产品原型配合使用来说明产品需求,核心内容是对要实现的每个产品功能及里面用户角色、前置条件、后置条件、界面、流程,数据统计等内容的描述,主要面向研发人员,使用word来撰写和阅读。
以上这三种交付物是产品经理协作过程中比较常见的交付物,尤其是在大公司中这些是必备的。但这不是强制的标准,很多中小公司都没有产品文档这个部分,有的直接用产品原型标注文字说明来做文档,有的是用excell来写文档,所以具体的交付物根据自己所处公司的实际要求来看,这些交付物的目的是为了辅助沟通,不管什么样的交付物,只要能达到简单,快速,高效沟通的目的就可以。
6、评审需求在提交了产品需求后,需要组织研、运营、设计、测试等人员对产品需求评审,在评审过程中,对产品的目标、背景、问题、思路、解决方案等进行介绍,评审的目的一个是为了让产品更完善,更具有可行性,另一个目的,也是让所有参与实施的人员对产品需求认可,目标达成一致,只有被所有参与人员认可并评审通过的产品需求才能被开发,评审是产品工作中非常重要的环节,如果这部分工作做不好,开发过程中的摩擦和修改需求的概率非常大。
结语:需求分析是基于用户沟通、背景认知、人性理解,层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准,越有机会在后续产品设计给出合理的方案。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)