在产品经理的日常工作中，需求评审是十分重要的环节之一，通过需求评审，产品经理可以提前规避风险和问题，减少可能的资源浪费。那么需求评审这件事儿，要怎么做才有可能做到更好呢？其中又有哪些维度是需要注意的？本文作者谈了谈自己的看法，一起来看一下。
上次笔者同大家聊了聊如何写出一篇优秀的PRD（【万字长文】PRD面面观，手把手带你写出优秀的PRD）。
写完PRD之后，最重要的当然就是组织评审啦。
根据实际情况，比如公司要求或心里没底，可在组织正式评审之前，发起需求内审。
进行需求内审的好处有很多。问题暴露越早，造成的影响和修正成本越小。此时只有产品经理投入了时间和精力，进行产品内审可以有效避免设计资源的浪费和需求评审时的争论。
提前约好大家的时间，发送会议邀请，概括评审主要内容并附上评审用到的PRD文档。
如果有拿不准或者可能有争议的点，可以在会邀中说明，让与会者预先有个准备。
大多数情况下，与会者是不会看你的会邀内容和PRD的，因此要提前找到关键的同事讨论，对主要问题达成一致。
比如对于某个产品功能是否能满足用户和商业需求，可以同产品负责人或业务方讨论；对于页面跳转、导航等设计的合理性，可以同UX设计师沟通；对于功能的可实现性，可以找相关的技术同事请教。
在评审前做好充足的准备，可以提高沟通效率、节约与会者的时间，避免因为重大问题返工导致重复召开内审会议。
在做内审时，最基本的要求是沟通表达能力，要做到吐字清晰，注意放慢语速（人在紧张是容易语速加快），陈述逻辑清晰，使用内部沟通语言（同写PRD时的要求）。
请一位熟悉文档的同事帮你记录会议纪要，包括：
评审过程中，要鼓励、引导参会者发言，充分收集各方的想法和建议。要尊重每个与会者的意见，即便可能是不成熟的。要善意的肯定对方的建议，表达自己的想法并和对方达成一致。
但是也要注意控制时间。一旦发生争论激烈或短时间难以有结果的点，要适时打断并跳过，避免陷入无休止的争论，浪费大家的时间。
在准备充分的情况下，不应该出现激烈争论的点。此时你要做好会后反思了：
会后务必要发送会议纪要，一方面是对与会者付出的尊重，大家提的意见我都收到了。另一方是二次确认，避免后续可能出现的扯皮。
根据会议纪要更新完PRD之后，也要记得再次发出来给大家确认。
如果需求比较简单或对自己的PRD比较有信心，可以提交UED设计需求。
在人力充足的公司，UX设计会由专业的交互设计师担任；而在人手不足的情况下，产品经理就要兼职交互设计了。
在目前各类交互设计规范比较成熟的情况下（例如iOS人机交互指南、Material Design、Ant Design等），交互设计做到合格还是比较容易的。
UX完成后就是UI设计。UI设计建议让专业的UI设计师担任，尤其是用户端界面。一个好的设计师对于用户体验具有举足轻重的作用。
给新手产品经理几个建议：
UX和UI完成之后一定要仔细验收，验收点包括：
对于界面设计风格，除非有十足的把握，否则尽量不要和设计师争论，因为容易被设计师视为质疑其的专业性或者觉得你啥也不懂。即便要争论，也要态度谦和、有理有据，切忌得理不饶人。
当设计稿都确认之后，就可以开始激动人心的需求评审了。需求评审主要思路和需求内审相同，后文主要描述需要额外注意的事项。
即便进行了设计内审，评审时也必须要完整的评审完，因为会议会有很多新的同事参加。
会议邀请要将PRD、UX和UI一并发送给与会者。
会议前记得拿着PRD、UX和UI和关键同事，比如技术骨干、业务方等沟通。一个顺利的会议都建立在会前充分沟通的基础上。需求评审会最主要的作用在于达成共识而非讨论。
同样要发挥自己的沟通技巧，让与会者能够听清、听进去，避免在开发过程中才暴露问题，导致产生延期风险和开发资源的浪费。
同样需要请一位同事做会议纪要，除了记关键的事情之外，还要记录时间和负责人。比如对于一个有争论的需求，那么需要指定负责确认需求的负责人和要在何时之前确认解决方案。
在具体评审流程时，也有一些技巧分享给大家。
准备充分的话，一般会有一些小修小改的问题。对于敏捷开发的团队（尤其是C端），会马上开始分配任务、评估故事点、进行迭代排期等。
这种做法对技术Leader、项目经理和开发团队的要求都很高。本人主要从事B端工作，没有经历过如此敏捷的团队。有需要的道友可以自行查阅资料。
会后的会议纪要也是必须要发送的，明确事、人、时间，以及完成项目排期的Deadline。
更新完相关的产品文档再次发送，就可以进入产品迭代了。
讲完需求评审的方法，笔者还想再详细解释其背后的原因。以帮助各位读者理解PRD评审的重要性。主要围绕几个关键点展开。
人在理解信息的时候，虽然发生在一瞬间，但其是有复杂的过程的。可以简单分为：
第1点即是通过PRD去传递信息，想要正确地传递信息，对PRD的质量有极高的要求。如何写好PRD可以参考我之前的文章。
第2点即是读者的专业知识、工作经验、对本项目的知识积累等。因此不同角色的人，看到PRD的关注点和理解也是不同的。
第3点即是结合逻辑推理，最终形成对当下产品需求的认知和结论。
形成完善的认知，得出完整的结论是需要思考时间的，到了评审会议上再临阵磨枪，往往难以达到预期的效果。
而让与会人员提前阅读PRD，哪怕只是囫囵吞枣的读一遍，那么思考的种子已经在潜意识中种下（人的绝大部分思考都是通过潜意识完成的，感兴趣自行检索相关资料），到了评审的时候会理解会更快、也会有更多更完善的思路。
少部分工作认真的同事会看你写的PRD。大部分同事都有自己的事情要忙，有的是本来想看，后来忘了；有的压根没有提前阅读的习惯。
根据“谁得利，谁负责”的原则，需要你主动的去达成该目标。
比如挑选在大家都不太忙的时候发送会议邀请。发送会邀后一段时间和评审会议前1小时，再次提醒与会者看PRD。对于关键人物（产品负责人、技术骨干等）则要提前约时间线下沟通，其他人则可以在平时交往时，有意无意的问问对新需求的看法等。
当然还有最重要的前提，把PRD写好了。本来阅读大段文字就很难，阅读一大段没有逻辑的文字，真是吃shi一般。
首先我们可以换位思考一下，在私下两个人争论的时候，是否愿意承认自己想法的错误？那么这个场景又放到一个全是熟悉的同事的会议上呢？
如果你都能够坦然承认错误，那么我对你表示恭喜。但是很多人在私下争论都是难以服软的，就不要说在公开的会议上了。
因此一旦在公开场合提出不同意见，就如覆水难收。他的意见对了，你会很尴尬；他的意见错了，他会很尴尬。因此针对事情的讨论往往会演变成捍卫个人脸面的争论。
再者说，很多观点是很难说清楚对错的，可能大家都是出于对产品的善意，提出了自己的见解，只不过相互不能理解罢了。同时，这种脸面之争很容易跑题，甚至互相进行人身攻击。
即便有一方真的吵赢了，且不论输的一方颜面尽失、形象受损，而且得出的结论真不一定是有益的，可能只是胜者更善于争论。往往双方都是输家。
因此一定要把更多功夫花在会前沟通上，避免评审会议陷入无休止的争吵。再次强调，评审会议最重要目的是为了确认。
设计本身是一个很主观的事务，没有明确的判断标准。因此设计师的工作不像开发，有个明确的设计文档作为目标。设计工作往往是边做边想，可能经历无数的推翻重建的。
“文无第一”，任何一个设计需求理论上都可以拉的非常长，能够不断发现新的思路和可以调整的地方。因此如果没有明确的时间截点，将会是一场项目灾难，可能设计师搜集材料、寻找灵感的时间就超过了你心中的成稿截止日期。
设计师尤其是UI设计师，往往身上带有艺术家的色彩。他们有自己的艺术追求和对专业的骄傲，思维发散，渴望自我思想的表达。
一个优秀的设计师需要这样的特质，否则按部就班的设（chao）计（xi）很难做出引爆市场的产品设计。
除了强调截止时间以外，你也帮助设计师更好的完成设计。
首先要搞清楚人的认知习惯。在人类几十万年的进化道路上，我们80%以上的信息都是通过视觉获得，且产生文字是最近几千年的事情。人类的整个认知系统其实对于文字的提取和理解效率其实远不如图片高。
其次，文字是对世界的描述，但是其表现力是有限的。我们在写PRD的时候就会感觉到，如果想把一个功能用文字描述出来就会很困难，且要使用大量的逻辑描述。如果通过原型图、流程图等可视化的手段，就会简单很多。
最后，文字的信息噪声往往是高于图片的。主要原因是对于相同的词汇，不同人的认知可能是不同的。比如很经典的一个关于程序员的笑话，“下班顺路买十个包子，如果看到卖西瓜的，买一个。”
其实在评审中，避免信息传达失真最好的方式是高保真原型，每个功能的细节都能动态展现的清清楚楚。但是其制作成本过高，且随着行业发展，交互规范、专业术语等能够极大改善信息失真的状况。
因此带标注的设计稿是我认为目前性价比最高的形式。
写会议纪是为了对大家在达成的共识进行书面确认，以作为后续执行的依据。这并非是对团队的不信任，目的也是为了信息的一致性。
口头传达是信息失真非常严重的手段，因此才会需要有PRD、UI、UX等各种产品设计文档，否则直接口头传达不是更方便。同样的，评审会议也需要清晰的将会议要点记录下来，保证大家的理解是一致的。
后续一旦发生问题，会议纪要是非常好的证据，可以对企图歪曲事实的同时进行实锤。
这样的同事有时候也并非故意，而是人的记忆会随着时间的推移而越来越模糊。同时人有强大的心理补偿机制，面对发生问题，往往会按照对自己有利的方面回忆甚至加工记忆。
更多的，会议纪要还有如下的作用：
关于如何做好需求评审的经验就分享到这里。祝愿每一位产品汪都能够写好PRD、做好需求评审，不要给程序猿们挖坑。这样团队更容易保持团结的氛围，团队成员之间也能保持良好的私人关系。
产品经理提前做一点、多做一点、做细一点，收益的不仅是团队，更大的受益者其实是自己。
本文是投票期间笔者发布的第7篇文章，今天也是最后的投票。
亲，请不要吝惜手中的票票，给笔者继续做产品经验分享的动力！
我在参加人人都是产品经理2022年度作者评选，希望喜欢我的文章的朋友都能来支持我一下~
点击下方链接进入我的个人参选页面，点击红心即可为我投票。
每人每天最多可投35票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦！
投票传送门：https://996.pm/YyDmr
专栏作家
一直产品汪，微信公众号：apmdogy，人人都是产品经理专栏作家。逻辑型产品经理，致力于将科学思维与产品经理方法论结合。关注人工智能、教育领域，擅长产品孵化、需求挖掘、项目管理、流程管理等产品技能。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。