需求评审会是产品经理工作的重要产出，在很多公司甚至是作为了产品经理的绩效考核，它是判定产品经理基本功的标准之一。每次开需求评审会之前产品经理都会为此做细致的准备。下面就来讲讲假设是一次大功能的上线，该如何为这次的评审会做准备。如若是一次较小功能的上线，可在这框架中适当简化某些步骤和方法。
一、和人做好沟通（做正确的事）
沟通听起来是一件非常“玄幻的事”，但它非常的重要，重要的事情说三遍，尤其在面对大功能的上线时。对技术开发的沟通是为了寻求支持，如“我的想法是xxxx，你们做的话难度如何？工作量如何？”，和上级（大boss）的沟通是为了保证大方向的正确。
我将会前准备沟通的对象分为三类，技术开发、直属领导和大boss。下面我将具体阐述如何做好与他们的沟通，要点是什么。
相对应的分别是：与开发的沟通；与领导的沟通；与大boss的沟通；这三个流程的时间、地点都是共通的，就是要沟通好时间和地点就行，此处不做赘述。这三个流程最重要的是who、what、why和how。即不同的人，要准备的资料有所不同，讲述的重点也有所不同。
1、和技术开发的沟通
What：沟通什么？沟通的是你设计的功能对于开发来说，能否实现，能实现的话其难度和工作量如何。
Why：寻求支持。假设在会上进行评审，你才知道原来你的设计技术做不了，会后原型设计页面要大改，这样就很耽误时间，也会让大家很怀疑你的专业度。因此会前要和技术主动沟通就显得十分重要了。
Who：技术是一群很可爱的人，他们关注的是实现难度，如果发现你的实现难度十分大，他们就会自动提出一种实现难度小的方案，这个时候你就要多想想用户体验了，共同敲定一个比较好的方案。
How：
物品准备什么？视情况而定，一般来说小的功能点阐述好原因和做法即可，不需要准备什么特别的物品。
具体如何做？请注意言辞表达，可以采用需求原因+设计方案+询问难度三步走。
2、和领导的沟通
What：沟通什么？跟你的领导重要的是沟通好的是业务逻辑、产品逻辑，你的领导往往和你一样也是关注产品本身的人。
Why：目标一致+查漏补缺+向上沟通。目标一致包括你和他的想法达成统一，在你提出的想法和他有偏差时，请记住用业务需求场景说服他。查漏补缺是指你的产品逻辑肯定是有存在不足的地方，领导作为旁观者一定能发现一些问题，给到你建议。向上沟通是指这个过程，其实这个也是培养你向上沟通的能力，相对于大boss来说更考验你的沟通能力（因为大boss一般你木得话语权啊）。
Who：对于领导的沟通目的是自己的想法能得到其赞同，最好是其能同自己在这方面站统一战线，这样你在和大boss沟通的时候能更顺利。
How：
物品准备什么？最好是准备ppt+初步原型。产品规划讲的是宏观上的整个产品逻辑，目的是让整个团队有个共同的目标，原型是为了让听者更明白更直观，是辅助理解的东西。
具体如何做？不必像需求评审会那样仔细，主要沟通的是大方向和大概的流程，整体是两步走，产品规划+原型展示。讲产品规划具体的话可以按照总分总结构，先总体说一说我们要干哪些功能，接着一个一个细说，重点是为什么要做这个功能，逻辑是什么。原型的展示其实是间接地传达了前面所阐述产品规划的内容，不必纠结于什么数据的来源、规则等等，就是演示一个大概的流程。
做完之后怎么办？该修改修改，该完善完善。是时候该和大boss沟通的时候了。
3、和大boss的沟通
What：跟大boss重要的是沟通好的是你为什么要这么做。大boss关注的更多是客户，大boss是接触客户高层最多的人，他希望的是做出来的产品是现有的客户会用的，所以你讲述的重点应是业务方面，即你的产品功能的现有用户价值是什么。
Why：微调目标+查漏补缺+向上沟通。大boss其实是比产品经理接触客户更多的人，他每周时不时会进行一些商务会谈，相对于产品经理来说，他的客户需求信息其实是最新的，有时候产品经理由于接触不到那么高层，又或者是暂时没有那么多时间去与客户沟通，有时候客户需求信息会滞后。例如，可能你两个月前A大客户有提出的这个需求，但可能近期它又不想要了，我们应记住客户的需求是会不断变化的，不是什么需求都要纳入产品规划中的，关键是看客户是否反复提及。所以在和大boss沟通后，你的原来业务逻辑、产品目标肯定都会有些微调整。
Who：和大boss的沟通更多的是产品和商业的结合与碰撞。对于大boss的沟通往往你一个人是不能搞定的，很多时候会需要你的领导帮助你一起，和大boss进行沟通。大boss会站在商业的角度，你和领导提出的产品方案要有用户、商业价值。
How：
物品准备什么？最好是准备ppt+初步原型。ppt准备的是你和领导battle后的完善版本，原型是为了让听者更明白更直观，是辅助理解的东西。
具体如何做？不必细讲流程，主要沟通的是大方向，模块与模块之间的关联，整体是两步走，产品规划+原型展示。讲产品规划具体的话可以按照总分总结构，先总体说一说我们要干哪些功能，这些功能的客户/用户价值是什么，再讲一讲比较复杂、大的模块关系、流程，以及这些功能的未来规划走向。你对于产品未来的规划肯定是会有与老板有出入的地方，原因我在前面有提到过（信息差）。但不要因此就不说了，这其实是一个更好地了解宏观业务的过程，只要你的规划功能是有根据的，大胆提就好，哪怕是需求变了现在暂时不做这个功能了你把它撤下就好了。最后总结可以给一个产品任务的时间图，即几个月先做什么功能，第几个月开始做哪些功能。在这里原型的展示是传达你的想法，你的idea，而不是产品流程。
二、正确地做事
1、时间管理
分清任务的主次。分清任务的主次，才能进行正确的时间分配。分清主次的标准是重要度，请注意是重要度而不是紧急度。因为一般来说，在一次上线的版本中，肯定会有上头分下来的紧急任务，但这些紧急任务一般不会很复杂，处理难度不大，此种任务只需要兼顾就可以了。任务可以从不同方面进行拆解，从而来分清主次。如评审会之前的工作可以分为需求收集阶段、产品设计阶段，产品设计阶段是主；产品设计阶段又可以是“一堆图”和具体原型设计，具体原型设计是主；几个功能模块根据业务属性也有主次之分。对于主任务是要花费较多时间琢磨的。
识别每项任务的关键点。“关键点”对于产品经理的工作可以这样体现，一般是可以有多种实现方案、多种场景、多种状态的任务内容，一般就可以说是该项任务的关键点了。例如从某个app跳转至小程序，关键在于如何让这个跳转做的更顺滑，电商中的订单管理关键在于订单的状态。对于关键点是要多认真思考的。
做好时间的分配规划。28定律：即8成时间用在主任务上，8成时间用在每项任务的关键点上。对于初级产品经理来说，假设在产品设计阶段，4成时间用于画各种图，6成时间用来画原型，这样拉去评审肯定效果是不好的，你会发现你的原型还有很多漏洞，还有很多细节未考虑到的。
2、摆正心态
你的设计永远都不会完美。如果你觉得你自己的产品设计是完美的，那你就会在你的工作中产生非常大的挫败感。产品经理本身有未考虑到的问题，就算和技术开发、领导讨论过的解决方案也是会有漏洞的，所以自己的设计是不可能没有问题的，我们要保证的是拉去评审会的需求文档尽可能的少问题、都是些小问题。请记住：你的工作是与团队共同打造好的产品，你不是一个人单打独斗，请接收否定。
3、手画线框图
线框图尤其适合前台页面，前台页面设计的细节、状态展示较多、较复杂。线框图一是可以帮你抠细节，二是可以比较多种设计方案，三是先经过手画线框图再画原型图，会帮你节省很多涂涂改改时间。
三、需求文档
请见个人主页相关内容。
其实上面三点，和人的沟通是最难把握的，万事万物都是死的，唯有人心是变化多端的，做产品，就是研究用户的心理，就是和团队协作，共同打造优秀的产品。