产品经理在推动产品设计落地的流程中，大多会经历需求评审这一环节，通过需求评审，产品经理可以尽快完善需求，同时加深其他成员对需求的理解。那么，产品经理要如何才能做好一场需求评审？过程中有哪些注意事项？本篇文章里，作者便进行了经验总结，一起来看一下。
需求评审是每个产品人在产品设计环节都经历过的重要环节。产品经理需要通过需求评审使团队成员对需求理解达成共识，并且在这个过程中发现需求不合理的点，从而完善需求。通过评审后的需求才开始真正的推动落地，产品经理也才可以阶段性的松一口气。
需求评审做的好，评审各方皆大欢喜，产品经理迈着自信的步伐走出会议室开始指点江山。做不好，评审各方怨声载道，产品经理唉声叹气的坐在位置上看着别人离开的背影开始陷入深深的自我怀疑。更有甚者感慨着“此处不懂爷自有懂爷处”打开了招聘软件。
所以需求评审还是需要我们好好准备，认真对待打赢一场场需求评审会，通过每一次的需求评审会完善产品，并且在这个过程中提高产品经理做产品的信心。
自古以来就有“兵马未动，粮草先行”的重要战略指导。我们也一样，需求评审的战争在需求评审会之前就已经开始了。要在评审会前准备好从充足的粮草，也就是需求评审会需要用到的各种资料。
从需求提出的背景、所属业务的现状、目前暴露的问题和期望得到的结果四个方面准备介绍内容。
除自己描述的内容外，争取根据业务属性准备一些与需求背景、场景相关的图片/视频材料，用户反馈，行业文章，政策性文件等材料辅助各方人员能够更容易理解需求内容。
提供产品经理进行需求设计时的产出物，如流程图、脑图、原型、需求文档等。一般流程图、脑图、原型是会经常被翻阅和评审的，因为图的形式更易理解和传播。
而需求文档则可以根据所属团队的工作习惯来判断此时提供的需求文档的颗粒度甚至是否提供。比如我所经历的团队，有的需要在评审前准备好详细的需求文档，否则研发同事就认为产品经理的工作还没完成，不愿意此时参加评审会。
也有的不需要准备需求文档，评审时仅根据原型来确定大部分的功能，具体的细节功能会后再通过详细的需求文档提供给研发同事即可。
有条件的话也可以提供产品经理在思考需求设计过程中的思路历程，将自己的思考过程和历史设计版本介绍给大家，引导大家跟着自己的思路了解到自己当前的设计理念。
针对需求和设计中的重难点部分，可以突出进行专门的介绍，有利于各方快速找到并了解和理解重难点内容。
一些情况下我们在评审时并不是已经具备十分完善的方案了，可能是已经完成了百分之九十的内容，还有百分之十的内容是仍有疑问的或者多个方案等原因需要多方一起讨论解决的。
这部分内容可以提前梳理清晰，可以让各评审方一目了然的了解到你在需求设计中的疑惑和需要大家解决的主要问题。
这份资料就不是给大家准备的了，而是给自己准备的。我们在需求评审前，作为需求的设计者，应该是最了解这个需求设计的人。关于这个设计有哪些点可能是会被别人关注而可能会被询问的，我们应该有一定的预判，从而提前做好合适的答复。
避免在评审会时的公众场合出现产品经理被问倒、答非所问、答案出错等尴尬的情况，这些情况的发生对我们产品经理在团队中的影响力和信誉度是有高度负面影响的。
准备好相关资料后，先别着急拉着大家一起开会评审。可以争取在正式的评审会前就将关键评审方逐个击破。
也就是在正式的评审会前可以与各个评审方分开沟通，争取在会前就发现和解答各方的疑惑，发现和完善需求设计的方案，并达成相同的共识。
毕竟一场需求评审会涉及的部门、岗位较多，每个人因为角色不同所关心的部分和期望的效果都有所差异。
如果全部寄希望于在一场数小时的公共会议上能够与各方达成一致，有一定困难。且不可控因素与负面效果的情况发生几率也较大，会议的效率与质量就无法得到保证。
如果能在会前就可以解决各方大部分问题，会上与各方再次进行确认即可。这样需求评审会的过程就处于可控的状态，有利于我们得到想要的结果。
我在工作中遇到过有的同事在会前没有和自己的领导确定方案，导致会议刚开始，方案还没讲完，就被自己的领导否掉了。可想而知这样的场景有多尴尬，其他参会人员都会觉得你们内部意见都还没有统一、方案不成熟，不具备评审条件，评审会也算是直接被结束了。
还有的同事和没有和研发同事沟通，在会议中与研发变成了讨论模式，讨论方案实现方式和各处细节的处理，结果是所有人员陪着开了一天会，都还没有拿到确定的结果。
更有甚者需求评审会变成了战斗模式，产品和研发僵持不下，相互输出不符合社会主义价值观的话语，会议被迫终止。
如果需求评审会发生了这些情况，评审各方一定会怀疑我们作为产品经理的综合工作能力。产品经理是应该作为产品的意见领袖核心形象存在，而不是一个让大家觉得只会浪费大家时间的角色。
所以需求评审并不是把功夫都只花在需求评审会上，在一定程度上来讲，需求评审的大部分工作在需求评审会之前就已经基本完成。
会前工作做的好，到了需求评审会时压力就会小很多了。不过虽然在会前已经和各方基本达成共识，但需求评审会时还是不要掉以轻心，仍要全力以赴。
在多方参与的情况下可以挖掘到让方案更加完善的点，同时让各方收获良好的会议经历，最终实现在公共会议上通过需求评审的目的。
在会议开始时，先描述需求背景，将自己准备的需求介绍资料娓娓道来，让大家进入到你的故事场景中。接着展现你的设计方案，带着大家一起理解你的需求设计。之后指出重难点部分，并着重展开介绍。
需求评审会的前半部分基本作为产品经理个人show time，是作为B端产品经理的我们为数不多的可以个人演讲的机会，这种场合一定要把握好机会驰骋疆场。
即锻炼自己的演讲能力，也提升自己在团队中的影响力，争取用一场生动的演讲让大家为梦想窒息！
方案的介绍完成后，打开需要讨论的清单，各方就可以针对方案设计中关注的部分展开讨论，对仍有疑惑的地方展开问答。
而你应该已经推演过可能的问题与答案，可以做到胸有成竹、游刃有余的主持讨论、回答问题。
由于关键方在会前已经和你就方案设计进行过讨论并且达成共识，所以这里主要注意在会上额外发现的需求可完善点和各方需要其他方协调和依赖的工作。
如果出现了关键性的问题仍然要认真对待，会上积极协调和解决。而出现的无关紧要的问题则可以保持尊重的态度礼貌的告诉各位”：我后会考虑把这里补充完善，这里不占用大家时间讨论。”
或者为了让对方不纠结于这些无关紧要的地方也可以直接让步将部分优先级低的设计按照对方的要求调整。
而如果已经做好了上述工作仍然出现了无法达成共识的重要问题，可以综合各方提出的情况和自己的分析找到关键决策者做定夺，借助关键决策者的力量定下方案调整，避免会议和方案陷入僵局导致工作无法推进。
各方对于需求的方案设计没有较大异议的情况下，通常就可以结束会议也代表着需求评审会通过了。但是这并意味需求评审会的工作到这里完全结束了，会后还要持续跟进下列事项。
1）方案的调整完善。根据会前会中与各方讨论的情况，将判断需要调整的内容进行完善。
2）可能的再次小范围评审。内容调整后，与涉及的相关方可以进行小范围的再次评审，告知方案调整内容。
3）确定人员与排期。最终关键评审方都知晓和确认最终方案后，与相关方如UI、UX、研发、测试等部门、确定具体负责人员与日期安排。
4）会议纪要广而告之。完成了上述内容之后，还要记得留下书面痕迹与证据。可以将需求评审会的会议内容与会后安排的情况通过会议纪要的文档形式用邮件、微信等方式广而告知所有评审方，避免发生问题出现责任推诿、耍赖的情况发生！
我们能切实地感受到，一场好的需求评审除了对产品的设计有莫大的益处，对我们产品经理的自信的提升也有很重要的影响。
很多产品通过需求评审获得一次次的正反馈便更加坚定了做产品的信念，也有一些产品不能收获到正反馈而渐渐丧失信心。所以需求评审是真正值得我们精力去认真对待的一件事情。
尤其是B端产品面对的是更加专业的业务背景，需求评审时产品经理需要Hold住全场，获得大家的认可。让大家知道你是懂业务懂产品有实力的选手，在这行人人都是产品经理没那么简单！
专栏作家
小游，人人都是产品经理专栏作家。工作在医疗领域的产品经理，持续关注医疗信息化、数字医疗、互联网医疗行业。打怪升级中，期望能够通过自己的力量为世界创造美好。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。