如果我们站在另外一个角度看太阳，往往会看到他身边还有许多星星。。。。。。
很多产品经理谈到需求评审可能都闻风色变，因为总是被虐的不要不要的，就像荒野猎人里被熊虐的小李子；但是，依然有那么些产品经理对需求评审会情有独钟，难得有个机会和各路大侠比试切磋，享受这舌战群雄的快感。前方高能预警，文章稍长，建议产品新人耐心认真读完，高手求拍砖或自行闭目，阿门~
什么是需求评审？
需求评审是产品进入正式开发之前非常重要的一环，只有所有人都认为需求已经没有什么可挑剔了评审才能通过，所以需求评审也是一个“鸡蛋里挑骨头”的过程。产品经理在这场「辩论」过程中，需要不断有效的展示自己的观点，以便获得更多的认可，最终号召大家（乐意）一起往一个产品目标努力奋斗。
为什么要需求评审？
- 让与会者清晰的了解需求是什么，需求从哪里来，对现有业务有什么影响，预期收益是什么；
- 让技术及测试对产品方案有详细的了解，以便后续开发更高效，没有谁愿意在后续的编写测试用例及开发阶段再去反复沟通确认，毕竟那是非常低效的做法，当然，特殊情况除外；
- 让与会者清晰的知道自己在整个方案落地过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；
- 评估产品方案的技术难度及实现周期，一期实现，还是分期实现，投入产出比怎么样？毕竟互联网产品讲究小步快跑，快速验证迭代，怎么样权衡产品设计（用户体验），技术成本以及商业利益是产品经理主要工作之一。
和谁进行需求评审？
一面视需求大小来看，如果仅仅是一个迭代需求，比如增加一个广告投放类型，那么可能只要前端技术、广告系统技术、测试（前端测试+广告系统测试），三五人随便找个地儿快速就搞定了；如果是一个中大型需求，比如收银台改版，那么涉及到的与会者可能就比较多，然而除了技术、架构、测试以外，往往UE/UI经常被产品经理忽略，尽管UE/UI内部可能有自己的评审（视公司不同情况不一样，有些小公司是不存在设计评审），但技术评估环节往往会涉及到一些交互和设计的实现需要沟通确认；然而，往往这样的大型项目一次需求评审基本是搞不定的。
一面视公司项目流程来看，大公司和小公司项目流程有时差异比较大，大公司分工细，并行项目多，尽管涉及的干系人较多，但是可能仅仅来那么几个主要干系人；而小公司因为项目比较聚焦，讲究执行力，反而比较容易召集所有干系人参加。
不管哪种情况，产品经理务必保证核心负责人到场，个别干系人可私下再沟通；很多产品经理可能会认为召集评审会议主要是项目经理的工作，产品经理只需要参会把产品方案逻辑说清楚就可以，如果你也是那么认为，那后面的内容就不必继续往下看了，你倒不如省点时间多去解几个bug。
什么时间进行需求评审？
根据项目迭代周期来灵活调整，一般是在确定下个版本迭代需求list之后（当然，要保证需求已排期），开发正式开工之前，建议选择开发开工前3-5天，主要因为：
- 就算一次评审通过，会后也有些细节需要完善补充，沟通确认；
- 中间间隔太久，很可能等到开发的时候，很多技术实现细节会遗忘，因为并行项目较多，这是难免的事儿；
- 运气不好的话，有可能遇到开发及测试人员调整；
- 很可能需要进行二次甚至三次评审
- 对需求评审有了初步了解之后，把需求评审拆分为评审前、评审中、评审后三个阶段，这三个阶段产品经理究竟要做些什么。
评审前
1. 保证物料齐全
产品需求文案（PRD）
怎么样写PRD，请自行谷歌，如果需要显得专业一点，那么可以按照标准格式来，而阴阳建议是，产品经理只要能把逻辑表达清楚，细节描述清晰，技术及测试人员都能看的懂，那就够了，无需局限于到底是用word格式，还是PDF或者axure格式。
UE稿
按照普遍大公司的流程，产品经理在这个环节只需要把产品的逻辑描述清楚以及大致的想法和UE沟通清楚即可，接下来就交给UE；这样做也没有什么大问题，毕竟流程在那，但是这样做可能会有什么状况发生呢？
UE并不是时刻为某个产品经理待命的，很可能并行其他项目，也就是说，很可能UE排期赶不上需求评审；
产品经理有自己的想法，但仅仅停留在自己脑子里，与UE沟通清楚想法后，可能UE做出来的东西不是产品经理想要的，然后开始二轮三轮的返工，撕B大战一触即发，严重影响效率；
难道产品经理真的只局限于写文档吗？产品经理可是要能做的了市场、玩得起运营、与交互遨游、与设计创想的呀。
所以，产品经理应该养成好的习惯，特别是当产品经理还处于初期阶段的时候，自己画原型（请画高保真原型），自己写交互，一开始能写到什么程度是什么程度，但是请尽自己最大的努力做到最好，保持与交互之间的沟通；产品经理切勿把这些所有工作都推给交互，更不要等用户说产品的交互一坨屎的时候把责任撇的一干二净；不要给自己找借口说没有时间，时间就像胸部，挤挤一定会有的。
再试想另一个场景，当产品经理一手拿着线框图，一手拿着高保真原型（其他内容一致的情况下）去和老大聊需求过方案，请相信高保真原型方案肯定更加容易戳中对方G点并通过，同理，需求评审也一样。不信？你试试！
UI稿
需求评审时不一定要UI稿，因为很可能需求会变更调整，但是，心里应该要有大致的风格预期，因为产品想透露出什么样的气质只有产品经理最清楚，这也是前面提到要做高保真原型的好处之一，锻炼自己的配色能力；如果有条件，待UI稿输出后，可以召集执行技术一起再看下UI流程图（即把UI稿贴到交互流程图上，嗯，阴阳以前就是那么做的….）
2. 提前小范围沟通
普遍的产品经理都有一个奇怪的心里，即总是默默的准备产品方案，不愿意去和别人沟通交流，要么觉得丢人没自信，被人家挑战之后觉得很没面子，自尊心受打击，要么就是觉得自己很牛B，不需要别人帮助，自己做的就是最好的（好吧，这叫做闭门造车）。
当然，也不提倡凡事都找别人沟通，大聊特聊，每天沉醉于自己多么能侃；产品经理务必要有独立思考的能力，可以在适当的时候与技术沟通沟通方案可行性，聊聊实现难度，方案靠不靠谱，有没有什么历史原因以防踩坑；可以和交互聊聊怎么样才能让用户在使用产品的时候不用思考，不用等待，不用怀疑，找到最优交互路径；可以和设计师聊聊针对这个模块可能用什么色系会更好，针对不同的地区是不是对颜色有禁忌，聊聊最近流行什么等等；不懂没关系，抱着诚恳的心态去请教学习，不但可以增长知识，还可以搞好人际关系，又不要花钱，何乐而不为呢。
另外，不要抱着所有事情都堆积至需求评审去沟通解决，已确定的前置需求可提前向相关部门提出来，因为每个部门都可能并行很多项目，没有人会特意为了你的需求再去配合你的排期（你以为你是谁…找骂）；可以私下主动提前与干系人沟通方案，就方案多磨合几次，起码可以让后续参加需求评审的干系人有个印象，需求评审通过率也会大大提高。
3. 提前把方案发出来
在需求评审的前1-2天可以把产品内部确认好的方案以邮件的形式发出来（可与会议邀请一并发送），请与会者提前查看产品方案并做好问题备注，如果可以，请与会者提前将问题反馈下来，产品经理可提前补充完善，以便后续需求评审高效完成；至于怎么样使得与会者提前查看方案并反馈问题，一方面与流程制定有关系，一方面就要看产品经理的沟通功力了，不管是请吃饭递手纸再陪睡。
同样注意的是，很多产品经理习惯把没有经过产品内部确认的方案发出来（基本都会有产品内部需求评审，或者一对一确认方案“产品经理VS产品leader”），但是如果方案没通过的话产品经理在技术大大那的信任积分将直线下降，就算可通过，最好也先在产品内部先沟通确认，多打磨打磨产品细节。
4. 其他事项
召集与会者以及会议室预定；很多与会者可能没法前来参加需求评审（原因请自行补脑），那么产品经理务必保证核心人员到场，如果核心人员也无法前来，那么请核心人员指定一位backup；产品经理会认为召集会议以及会议室预定都是项目经理的事儿，但阴阳建议产品经理还是多多自己去安排，多的不说，起码可以多认识几个人，多刷几次脸，后续大家还要一起愉快的玩耍呢不是。
提前到达会议室；产品经理可以提前一刻钟左右去到会议室，检查检查演示设备是否支持及齐全，千万别等到会议开始后才发现这个没有那个没法用，白白耽误了评审时间。
一言以蔽之：产品经理不要让自己成为「这件事」的瓶颈。
评审中
经过一番折腾，终于到了激动人心的时刻——需求评审，准备好让口水沫子来的更猛烈些吧…..
1. 明确会议背景及目的
很多产品经理参加需求评审的时候不管不顾直接进入产品方案的演示，这样很可能会造成一小部分的与会者一头雾水，因为有些与会者很可能是原与会者的backup，既然是会议还是可以按照标准的流程来，起码会议的前几分钟可以热络一下气氛，以免大家都冷冰冰的坐在哪。
正式进入方案评审之前，可以先说明本次评审的背景是什么，需要完成哪些事儿，希望达成的目的是什么，评审会分几个环节，每个环节大致的时间需要多久等等，让与会者对评审会有一定的心理预期。其实这部分工作可提前在邀请邮件中就体现出来，待正式开始需求评审之前，稍微提一下即可，那样则可以把更多的时间预留给后面的环节。
2. 切勿立马进入方案细节
同上，很多产品经理在产品方案演示的环节直接就进入了方案细节，比如这个功能要怎么样实现，为什么要那样做，那个交互怎么样等等，试问，前戏都没做好，直接开干，对方会爽吗？产品经理在演示方案的时候可使用6W2H原则（具体请自行谷歌），在详细介绍产品方案的时候可遵循产品设计的五个层级分析法，即战略层、范围层、结构层、框架层、表现层（具体请自行谷歌）
3. 掌控节奏，切勿争（si）论（B）
产品经理正确的坚持自己的想法很重要，当然前提是“正确的”坚持，经常遇到技术问几个问题，产品经理不但不思考被提出来的问题，反而固持己见，争的面红耳赤，口口声声说“我觉得问题啊，用户一定会那样的，这样挺好啊”，此时产品经理在技术面前就是一傻B，信任直接受到10000点伤害；正确的姿势应该是产品经理把问题拆解，要么用严谨的逻辑或者数据说服技术，要么就是虚心向技术请教，站在对方的角度去思考这个问题，是不是自己没有想清楚，不要求及时回答，可以暂时回复对方“这个问题我的确没有考虑清楚，会后再去思考全面，如果有不懂的地方可能到时还需要请教你，待问题明确后也会同步信息给大家”。
争论不但无法解决任何问题，还浪费会议时间；人的有效集中精力时间大概在45分钟左右，所以需求评审会尽量控制在60分钟以内，当然很多时候都事与愿违，那么产品经理应该尽可能的把前期准备工作做好，不要指望所有事情都在评审会上解决，如果超过60分钟都解决不了的问题，那么请及时打住，因为在往后也不会有什么实质性的结论，可以考虑私下在小范围沟通，或者组织二轮评审；
预留FAQ环节，针对FAQ视产品经理掌控能力而论，可以讲到哪哪有问题立马提出来并回答，也可以是先完整介绍某个模块或者功能后，再请与会者统一提问并解答，以免中间被打断，导致效率打折。
4. 需要别人给予什么帮助或者反馈
回到前面所说的为什么要开需求评审，当然是要解决某些问题的，所以不要忘记需求评审的目的是什么，该出手时就出手，比如某个功能的实现成本、技术评审排期、指定负责人、UE/UI排期等等，当然这部分工作更多的可能是项目来安排，并且有些排期是没有办法及时给出答复的，但是产品经理作为产品的主导者必须知晓该部分信息，以便后续更高效率的协调资源。
5. 其他
关于需求评审会主持人
有些公司是项目来担当这个角色，有些公司是产品经理来诠释这个角色，如果不想需求评审会搞得像葬礼一样严肃，这个时候项目经理与产品经理更应该是相互配合的，一唱一和，不但可以更好的掌控会议节奏，还可以调节整个会议的氛围，千万不要局限于一定要谁谁谁来，没意义。
不管是谁来担当主持人，一定要掌握好会议节奏以及控制好讨论氛围，很多时候与会者提几个问题，聊着聊着就聊到别的地方去了，越聊越远，白白浪费时间，所以只要与本次会议无关的话题尽量避免，更不要展开讨论，必须及时打住拉回到主题上。
可以提前演练几遍
需求评审毋庸置疑是一件很锻炼人的事情，锻炼沟通能力、掌控力、演讲能力、表达叙事的能力等等，所以为了做到更好，学会用做产品的思路去准备需求评审会，产品经理有理由在会议之前先演练几遍，重复几次之后，会发现你的沟通能力及叙事能力将大幅度提升。
另外，在整个评审过程，请仔细倾听每位与会者的问题及反馈，做好备忘，能及时解决的，当下解决即可，不能及时回复的，会后再处理。在该环节末尾，产品经理可以把备忘好的问题整理并复述一遍，以免问题遗漏，起码在与会者看来，产品经理对每个人的反馈都是非常重视的。
评审后
很多产品经理认为评审后就没啥事儿了，只要把问题及解决方案补全即可，然而这往往不够。
- 整理遗留问题，找相关同学沟通解决
- 完善方案，更新产品文档，上传至jira/wiki
- 发送会议纪要（不要争论是项目来做还是产品来做），同步以上信息
- 后续工作计划，明确责任人及反馈排期
整个过程下来，貌似都是产品经理在嘿咻嘿咻的干活，谁说不是呢，启蒙老大曾经告诉阴阳“所有错都是产品经理的错”，谁说不是呢，但是反过来想，谁说不是产品经理收获最大呢。
最后，偷偷告诉你个小秘诀，想要需求评审会更高效，开会之前把凳子全部搬走藏好….（嘘，千万别说是我带坏你~）