什么是需求评审

很多产品汪都经常会碰到这样的场景:

一个非常复杂的产品设计终于加班加点的完成了,你满心欢喜的召集程序猿们开产品讨论会,但是过程中却备受打击,经常会碰到如下问题,而你还回答不出来:

是否要搜索?模糊搜索还是精确搜索?
是否有翻页,每页显示多少条数据?
能不能输入小数点、负数、字母?
公式怎么算的?
各种状态如何定义?如何转换状态?
……

很郁闷的是上述问题,你在产品设计过程中,你根本没有考虑过这些问题,你一直在考虑如何来创建订单,应该让用户更简单的使用。而这些问题,你认为都是小问题,还需要我来考虑吗?

这个会议的效果可想而知。

程序猿们会认为这么长的时间了,你产品经理在想什么,这些都没有想明白,没干活啊!

产品汪们会非常委屈,觉得程序猿是有意刁难自己。要么觉得这些问题难道不是应该程序猿考虑的吗?要么觉得,这些问题复杂想不清楚。

最后会议草草收场,团队之间出现嫌隙。

当产品汪把上述问题的答案整理完之后,再次召集程序猿们开产品讨论会,发现貌似还是会有类似的问题。

以上就是一般产品经理评审的经典过程

什么是需求评审

需求到产品经理那儿之后,经过对需求的调研、分析之后,结合现状对需求进行处理,主要是解决做不做?做多少?什么时候做的问题;

那么,产品经理完成他前期工作之后,需要让大家周知整个需求的『来龙去脉』,通过评审让领导、产品、开发 、设计、运营等人员形成共识,并对多个需求进行打包,整理出一个版本所需要的需求点,对打包好的需求形成文档,提交由领导复核,确认后进入开发周期

需求评审的目的基本如下:

让团队所有人(相关成员)明确需求背景和目的
确认需求的规则及实现方案
确定整个项目的周期和内容
让相关人员了解自己所需负责的内容
确定需求上线时间规划

需求评审过程通常很激烈,通常会有很多类似问题逼问产品经理:

这样做很麻烦,开发难度很大
你考虑清楚了吗?真的要这样做吗?
这个流程太复杂了,能不能简单一些
你这根本没考虑到实际情况
还有一种情况你没考虑到

需求评审会,能极大锻炼产品经理的表达能力、沟通能力、逻辑能力、忍耐力

需求评审都有什么人参加?

同行 本项目产品、配合部门的产品 壮胆的
设计 UI设计师、UE设计 挑原型刺的
研发 客户端研发、前端研发、后端研发 挑流程刺的
测试 测试人员 什么刺都挑的
运营 运营推广、客服 先了解等上线再挑

前期准备

完成需求文档撰写:包括流程图、原型、标注等。然后反复多次推演,看是否有遗漏,尽量把能考虑到的问题都准备好。

同核心人员小范围沟通,确保没有大问题。这一招效果很好,提前沟通好,有大问题提前找出来并解决,避免在评审会期间出现大问题,甚至可能导致整个方案都无法执行。

提前同相关参与同学协调好评审时间。不要临时组织评审,不仅可能人无法到齐,大家手头有其他工作也会受到影响,心里也不爽。

提前将需求文档发给大家。让大家有时间提前了解基本信息,提高评审会效率。当然,提前发了可能也有人不会看,想办法引导一下呗

评审会期间

先讲需求背景:让大家知道为什么要,做了对用户和我们自身有什么价值。这样大家心里才明白参与到这个项目的价值,后面才有动力听下去。

讲功能模块:说明这个需求本身需要哪些功能来满足,其中这一期先做哪些,后续迭代的时候再做哪些。

讲业务流程:说明整个需求的业务流程和数据流转。

讲原型和交互:这一步终于可以拿出原型稿了,详细的说明页面布局、交互逻辑及规则等详细信息;

讲数据指标:沟通清楚需要哪些数据,在哪些地方埋点,数据如何可视化;

需要谁支持:有哪些人需要投入到这个需求的项目中,以及负责的内容是什么,上下游配合的人员是谁等;

预计上线时间:需求排期,可以让每个功能对应的负责人估时,确定测试时间及预计上线时间。

注意事项:

1、掌握叙事顺序:从大往小,从外到里,从远到近,从高到低,从粗到细。

点评:叙事先搭框架,立条件,然后,就顺理成章了,听的人也会有脉络感,而不是听的东拼西凑的感觉,便于建立统一框架下的统一认知。要给听着一种环环相扣、骨肉相连的紧密感,比如前台需要显示商家等级,后台需要对等级做配置,这就是一种骨肉相连的依存感,说起来也自然是:为了前台XXX,后台需要配套XXX。

错误:我们今天评审一个需求,先来看后台需要增加的模块。
正确:我们今天评审一个需求,它的设计背景、动机和场景是XXX,它由XXX部分组成,我们先来看XXX,它是核心,其余的模块对它起到支撑作用。

2、评审推演:在脑海中,或者私下演练,提前过滤低级错误,预防可能的问题

点评:靠两件事:前期充分准备+转移话题技巧。很多的产品经理,在评审会上,因为一个没确定的疑点被人“将军”,如果下过围棋,应该知道,这种运动耗费脑力之处在于计算和推演,做产品也一样,设计过程中遇到一个问题,刨根问底的找方案,评审时,如何回答就靠这了,同时要学会把问题缩小,不要回答了一个问题,引出更多不确定。这个时候,可以尝试变被动为主动,主动跟着答案引出一个更深度的问题,去反问存疑者,同时也把话题转移了回去,一旦他答不出,而你能自问自答,高下立判,评审就是一个步步为营,慢慢建立优势的过程,让大家变得更信服你,很重要!最后提下,何为预演?不是简单的想下答案,而是要提前准备好完整说辞,任何人回答问题时,语句是否有序,会直接带给人可靠和思路清晰的感觉!

3、审时度势:把控节奏、Hold全场

人生如戏,全靠演技!除非老戏骨,否则一般很多细微表情动作都能看出以上的一些点,什么叫把控全场节奏?顾名思义:别人的行为,按你安排的节奏触发,和做交互一样,他想思考全了提问时,你先打他一个措手不及!他对你点头,你就捧他,别人看到有人支持,也会更偏信你!要自己把控节奏,别被人先手!当然,这点不是教你去不听合理建议,也不是去规避问题,而是更好的激发问题和建议的同时,别把自己主持人的角色变的被动,这样会影响你阐述需求和设计的效果,观主希望你们能通过把控节奏,100%的把自己的设计说清楚,这样的前提下,有则改之无则加勉!

错误:自顾自的讲,全程自嗨,不顾听众反应,不看需求方眼色,不给存疑者提问
正确:阅读每个与会者的表情、动作,看看谁是支持你的观点的,谁分心了,谁有不认同和疑问,对支持的人,多问他是不是也这么想,对分心的点他名问问题,对不认同和疑问的埋坑给他跳,别让他按自己的节奏发难。

4、换位思考:将心比心,建立关联

用他们的视角去重新理解设计,并学会用他们的语言去阐述!让他们感觉你是懂他们的,是在为他们而设计!产品永远不是高高在上的上帝,而是行走于最底层的行者,用你的设计去帮助大家,并感动他们!

错误:我们做了个活动模板配置器,它能根据你的设置,生成适应各类场景的活动页面!
正确:对一群营销人员说:我们做了个灵活的设计,它就好比一个宣传包,里面有各种根据不同场景需求设计的活动DM,你们在推广时,根据需要取出不同的DM即可!

其实这点,一样对开发适用,评审会向前寻求需求方认可,向后寻求开发兄弟认可,把你的需求和设计,和业务场景以及目标做关联,让开发的兄弟们,清楚的知道他们的努力,为公司创造了什么价值,这样他们才会更认可你,也会更有动力。

总结:掌握以上几招,你的评审会更顺利,但是前提是思考和设计本身的全面和质量

评审会后

确认排期,追进度:固定周期组织大家开会同步进度,其他时间可私下追问进度。确保一切顺利进展,若有问题也能提前了解。
整理遗留问题,并尽快给出解决方案:评审会期间的问题及时解决,并将方案同步到相关的人员。
发出会议记录,每个问题都有行动计划
发出修改后的需求文档,并更新到内部系统中
若需求有调整,更新需求文档并发给大家,约下一次的评审的时间(如需要)

总结:

需求评审是结合现状对需求进行处理
需求评审人员:同行、设计、研发、测试、运营
前期准备:完成需求文档撰写、小范围沟通、协调好评审时间、提前将需求文档发给大家
评审会期间:需求背景、功能模块、业务流程、原型和交互、数据指标、人员支持、上线时间
注意事项:掌握叙事顺序、评审推演、审时度势、换位思考
评审会后:确认排期,追进度、整理遗留问题