需求评审指导方案：如何才能不被研发围攻？

2016-11-26 18:07:00

最近产品评审有同事被喷到桌子底下了，我也被喷到桌子底下了，所以在被教育后写了篇评审指导方案，希望对自己，对要做评审的同学能有帮助。

一、评什么？

产品评审产品评审，在做评审前一定要搞清楚要评什么，自己的心里要跟明镜儿似的，也能够几句话跟别人讲清楚，一般来说主要是下面几方面的问题，搞明白了基本就算清楚评什么了。

什么产品
背景是什么
为什么要做
什么时候做
怎么做的
哪些人来做
期望结果是什么

二、怎么评？

怎么评，说到底是评审主讲人准备给大家讲解些什么，一般产品评审包括PRD（产品需求文档）和DRD（交互设计文档）两大块，大部分时候DRD是融合在PRD中的，这些是基本准备，关键点看下文。

2.1 PRD文档

背景：产品背景、评审背景
用户构成：产品的用户是谁
产品架构：产品的构架、功能结构、信息结构
业务流程：包括任务流程、页面流程
具体case：每一个功能模块、功能点的case
其他产品需求：性能、数据监控、兼容性

2.2 DRD文档

状态
规则
反馈
跳转
动画

上面这是完善的评审素材资料，但是要具体情况具体对待，不是说每一个评审都需要如此的完善，而是要针对性的结合评审的产品模块或功能提取出适合本次评审的产品文档，要不评审没被喷死，写文档倒是写死了，世界上第一个死在PRD文档桌前的PM并不是一件光荣的事。

三、评审流程是怎样？

3.1 评审前

准备评什么

清楚的【熟悉】自己要评审的产品和功能，这里是熟悉！！不是清楚或了解，只有你真的了熟于心，才能给参审人员描绘出一个简单、合理、有价值、没有问题的产品功能，否则，进行评审完全是浪费大家时间。

人员提前邀请协商时间

一般来说每次产品评审都会涉及到领导、产品、开发（前端/Android/iOS、后端）、设计、测试、运营、客服这几类人，但也看具体情况。这里的协商时间首先要提前1到3天联系相干人员，尤其领导，看大家是否有出差或者其他会议的安排，协调好一致的时间区，通常尽量照顾领导与核心技术人员的时间安排。

会议室提前预约

提前两到三天预约会议室，提前对投影仪、电脑放映试用确认，桌椅数量、灯、笔、电插板等确认可用，以防万一。一般公司的会议室永远是稀缺资源，投影仪电脑更是频繁出现不可预料的问题。

3.2 评审中

讲解需要注意的地方

尽量站着讲，让你的气场出来，能够一眼扫清全场人员；

语言+手势+马克笔，特殊情况用特殊语言表达；

采用适当停顿、抑扬顿挫的声音和眼神来把控议场氛围；

较大争议不当堂辩论，留作私下交流；

电脑上清理掉私人的信息，如QQ、微信、桌面上其他杂项、浏览器上其他杂页，一方面保证你的“安全”，另一方面也减少影响参审人员的注意力。

开场白

欢迎大家云云开头；

本次我们评什么？

项目背景是什么？

我们为什么要做这个功能或迭代？

这版迭代解决了什么问题和需求？

我们产品的解决方案是什么？

基本就上面这些，主要一方面是对大家的尊重，同时让大家先缓一下脑子，有些人刚进来会议室还是懵的；另一方是也是需要通过一个简单的概括说明让大家先大致了解我们今天评审的内容，脑子里先有一个框架结构。

评审讲解思路

按照金字塔结构由总到分的方式讲解；

先过产品架构和信息结构，简要描述各功能模块，然后以流程图聊一下产品的业务流程；

对功能模块进行组织分类，提取公有模块，以举例其中之一典型讲解，不要过全部的功能；

将每个功能点重要的关键功能点领出来着重强调，或是功能流程、或是特殊限制、或是逻辑设计等；

最后对特殊的不同功能点做单独讲解，整体拒绝流水账；

开始讲解

按照上面的讲解思路下来基本没什么问题，快的话半个小时结束，内容多的话也最多两个小时结束。

如果评审内容过多，建议拆分开几次评审，如果想一次讲解完，提前给大家打好招呼，或是带电脑，或是带水或是提前上厕所等。另外中间需要再一个多小时左右中场休息，一方面你自己需要喝点水润润喉，另一方面大家可能也需要上厕所喝水之类的，别把大家憋死……

项目时间规划

提前跟领导主管以及项目各相关方主管沟通，以确定大概的时间周期。功能模块讲解完之后现场与大家沟通，确认设计、技术给出时间评估，有些可能当场就能给出来，有些可能你要求多久就是多久，有些可能需要回去详细看了文档才能给出时间周期，这个过程每个人每个公司情况不同，做好后续的跟踪以尽快完成完整的项目周期规划安排。

问题、建议询问收集，并结会

具体讲解结束，项目时间规格也基本结束，最后再询问一遍大家是否还有什么问题或建议，如果有立即解释，如果没有（一般情况下都没有……），最后简要总结一下今天的评审，主要是发现了哪些问题，后续我们产品怎么跟进，怎么和大家沟通协作。完了结束会议的时候说声谢谢大家（基本礼貌），希望合作愉快。

3.3 评审后

评审会议结论总结

评审的结束并没有意味着产品评审已经结束，反而应该在评审结束后是带着参审人员给出的建议和问题来重新审视产品设计，搞清楚明白他们为什么会有那样的疑惑，为什么会反对这种设计，为什么觉得那个功能不合理，为什么他们从技术、销售、客服、运营角度提出了大大小小的自己看法。

评审是一个产品设计的升级，从一个人的闷头设计走出到各种利益相关方，接受大家的质疑，协调各方需求，最终拿出一个合理的、有效的、满足大部分用户的产品设计来。

这是对一个产品人最大的要求，能够静得下心来，思考别人的建议和提问，总结产品设计的方方面面。

评审结果邮件通知各方人员

另外评审结束后还有一件重要的事要做，那就是整理评审会议记录，然后邮件发送boss，并抄送给各个与会参加评审的相关人员，一方面是让boss了解到评审都干了些啥，产品设计是怎样的，有哪些问题，后续的安排是怎样的等，另一方面是确保参加到会以及因为各种原因没来参会的人还能够在评审结束后有的回顾产品设计和评审会议，这一点对项目推进有比较大的帮助，因为评审会上都是在听，听完之后挑刺，评审结束后反而是大家都静下心来思考该如何实现这个产品设计，项目周期、人员配备等心里都有数。最后还有一点小套路，评审结束后邮件发送大家也是把评审人讲的话留下证据，方便后面产品推进。

后续问题跟进方案

有些问题不是能够立马解决的，但也不允许拖若干天，尽快解决，然后根据实际情况评估是否还需要再次评审或是只跟单独人员私下沟通。

因为评审后基本算是一个产品设计已经交付出去了，因此这时的功能或交互文档等变动都需要详细的修订记录，每一个更新后需要邮件通知每个相关人员，邮件中附带原型地址、更新的问题、更新时间等，邮件后最好能在QQ群或者微信群再吼一声，保证大家都能够及时了解产品更新。