如何进行需求评审?

【小百摘要】需求评审是产品经理综合能力的体现。

作为产品经理,一般都经历过需求评审,或者是自己主持的需求评审,或者是参加别人的需求评审。大部分需求评审会陷入两种极端情况,一种是产品经理在上面对着产品需求文档照本宣科,下面与会人员无动于衷;另一种是产品经理刚讲几个需求,大家已开始了激烈的讨论,都在证明自己是对的,会议被无限延长,效果甚微。所以说需求评审体现了产品经理的综合能力,如果完成的好,后续实施会比较顺利,也会提高自己在团队中的影响力,如果完成的不好,会对后面的产品开发增加巨大的沟通成本。

一、什么是需求评审?

需求评审通常是由产品经理主持,通过讲解产品需求文档,让相关人员了解具体需求,并提出疑问,进行沟通的过程。统一大家对产品需求的理解,为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看,需求评审是一个非常重要的环节,它串起了前期的需求收集、需求分析和后期的需求实施和产品落地。

二、为什么要进行需求评审?

1、明确产品需求,达成统一认知。对于明确产品需求,主要面对的是需求提出方,即相关的业务人员或者用户代表。讲清楚自己对于用户需求的理解是什么,是否深入分析了用户需求背后的真正动机。例如用户想要一个钻孔机,背后真正的动机是想要墙上的一个钻孔,还是想挂一副画,或者是想要一个温馨的环境。然后与需求方沟通,阐述自己的分析过程,确定自己的理解是否正确,并与其达成一致。因为对动机的理解不同,解决方案也会不同。当动机达成一致后,接下来介绍相关的解决方案,也就是他们将得到什么样的按钮,进行如何的操作,会看到什么样的数据或分析等。然后进行沟通,这些解决方案是否实现了其目的,是否带来了工作效率的提升。

2、沟通需求细节,优化实现方式。对于需求细节的沟通,主要面对的是需求实现方,即相关的设计或开发人员。在这个环节主要是讲清楚“为什么做”和“做什么”,首先交代需求的相关背景和设计原因,让实现方从源头就清楚自己要做的功能为什么是这种形式,其次详细描述需求的实现方式的相关细节,让实现方知道自己接下来做的东西是什么,特性是什么,具有什么样的流程,如何操作等。最后针对相关细节进行沟通和讨论,实现方会站在他们的角度,对实现方式提出自己的疑问或建议,一般情况下,他们提出的相关问题,会弥补产品经理前期没有想到的地方,从而让实现方式更加合理。

3、体现专业能力,获得团队支持。需求评审,体现了产品经理的综合能力。而这种综合能力,不仅体现在需求评审会议的主持和沟通上,更重要的是在需求评审前,对需求的收集、分析和实现,也就是把用户需求转化为产品需求的过程,需求评审只是对这个过程完成度的体现和考验。所以,长期深入的思考和足够专业的能力是开好需求评审会议的前提。作为产品经理,要认真对待需求评审,清楚自己的核心工作在什么地方,通过什么方式能进行更好的呈现,如何沟通能让需求更准确的传达,把它当成一次考验和锻炼自己的机会。只有自己足够专业,才能得到团队的支持,有了团队的支持,才会更加自信,在良性循环中,使产品不断的迭代和完善。

三、如何进行需求评审?

1、提前准备。凡是预则立,不预则废。只要你认为比较重要的事情,想获得比较好的结果,前期的认真准备都必不可少。对于需求评审会议的准备工作,主要有三个方面。第一,资料方面,一定要详细,齐全,至少包括产品需求文档和会议议程,形式越正式,大家对会议的重视度也越高。第二,人员方面,要考虑清楚都需要谁来参加评审,是一次性把相关内容都评审完,还是分批次小范围评审,然后提前把资料发送给相关人员。第三,沟通方面,分析相关人员的关注点在什么地方,需要对方在哪些方面给出建议,最好提前逐个进行沟通,让对方在会议之前就对相关内容有所了解,这样在评审的时候会更有针对性,效率也更高。

2、足够具体。在讲解具体产品需求时,不要陷入自己的逻辑不能自拔,而是要把参与会议的人员当成小白用户,站在对方的角度,尽量讲的详细具体,主要有三个方面。第一,形式多样。产品需求文档,不要只有Word版本,Word一般作为相关人员的后期查看使用,在需求评审时,最好使用PPT、流程图或Axure形式,也可以多种形式交叉使用,避免枯燥。如果有可以实际操作和带交互的原型更好,面对具体的软件,更容易调动大家的积极性。第二,背景清晰。一定要把产品设计的背景信息以及需求分析的来龙去脉讲清楚,让大家“知其然”的同时也“知其所以然”,对需求的理解越深入和全面,越有利于需求的落地和实现。第三,代入场景。不要直接讲产品的功能,尽量把功能代入用户的实际使用场景,通过故事来串联操作。例如苹果在发布MacBook Air笔记本电脑时,直接从档案袋中把电脑拿了出来,惊艳全场。这种方式就比直接讲电脑的尺寸参数要形象的多。

3、长期跟踪。不要指望一次评审和几次沟通就能让大家全面理解产品需求,会议结束后,还需要进行以下三方面的工作。第一,形成文档。会议结束后要及时形成会议纪要,对于会议中没有确定的争议点,产品经理要给出解决方案,并结合已形成的决议和后续相关工作等,尽快编写出详细的文档,并在后续过程中不断更新和完善。第二,沟通确认。把文档以邮件的形式发送给大家后,找相关人员进行沟通,确认双方理解一致,并敲定相关功能的设计开发时间点。第三,长期跟踪。需求评审只是开始,开启了产品具体实施和开发的另个一环节,在此过程中,产品经理要不断找相关人员确认需求细节,推进功能开发。

总结

需求评审是产品设计开发的一个重要环节,贯穿了产品需求和产品实施的全过程,对于产品最终是否能按时落地起到关键的作用。所以,在需求评审前,要提前准备;需求评审中,要足够具体;需求评审后,要长期跟踪。虽然整个过程体现了产品经理的综合能力,但一定不要为了证明自己的能力而无法听取反对意见,带着情绪产生争执。争吵本身并不可怕,可怕的是为了捍卫自己,赢得辩论而争吵。需求评审是一次挑战,产品经理要把每次挑战都当成学习的机会,让自己不断成长,做出更好的产品。


专栏作者

作者:时间之树 ,微信公众号: 产品经理的思维方式

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表