面对需求评审，无论是发起人产品经理，还是参与人研发、测试都是有苦难言：
在会议上，产品直接被研发工程师怼方案不合理，技术无法实现。参与人员没有围绕评审会的目标去讨论而是衍生到其他问题，导致效率不高。需求评审会议顺利结束，但在实际开发中却不断发现需求漏洞，导致不能按照计划顺利执行。怎样能够让需求评审更高效、保质呢？作为测试人员又如何在其中发挥价值呢？根据自己的工作经验，下文介绍如何在需求评审中做到更规范，来减少评审过程出现的问题，以此提高需求评审效率、提升需求评审会议质量，来营造一个比较轻松的产研合作氛围。
(资料图片仅供参考)
通过将需求规约文档发布给利益相关者进行检查，发现需求规约中存在缺陷（如错误、不完整性、二义性等）的过程。简单点来说，就是在产品规划完之后，把团队人员聚集一起讨论并评审方案的会议。如方案通过，则按规划的方案，继续往下实施；如方案不通过，根据意见进行改善。
2.1 需求评审的参与人员每个公司的团队结构不一致，但通常包括：产品经理、开发工程师（前端、后端）、测试工程师、设计（UI、UE）、需求提出方。
2.2 为什么要做需求评审产品眼中的需求，交互眼中的需求，视觉眼中的需求，开发眼中的需求，测试眼中的需求大相径庭,需要让团队中每位人员对需求有统一的了解，通过需求评审来拉齐大家的认知。主要作用是：
有助于团队中每个角色了解用户需求，理解产品需求的由来，考虑需求合理性及用户体验感。对需求文档进行评审，尽早发现需求中的问题，减少后期修改缺陷的成本。使开发团队中每个角色对需求的理解保持一致，减少了后期的沟通成本。沟通需求细节，确认需求是否可以实现以及实现方式，有利于测试人员对功能实现逻辑的理解，完善测试用例。确认交付内容和预期时间。3 如何进行需求评审做好一场需求评审，大致分为三个阶段：评审前、评审中、评审后。
3.1 评审前3.1.1 做好产品基本功角色：产品经理
和业务方认真推演产品要解决的问题，深挖业务述求，相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。充分准备需求原型和PRD，反复推敲产品方案，确保所有的功能点都能实现闭环，正常和异常场景都要考虑。任何一个遗漏的场景，都可能成为评审会上的“雷点”，产品们需要提前扫雷。提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法，技术的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来，驱动技术前置。提前将完整的原型和PRD发给相关人员，以便他们提前阅读相关文档，深刻理解需求，有疑问的点提前标注出来，方便在开会的过程中积极地去参与这个会议，抛出疑问点。3.1.2 技术人员提前介入角色：研发、测试，建议提前2天
团队制定好规范，利用各自碎片化时间，提前介入进来理解需求。前期了解过程中除了关注功能要求，还需要关注数据类型、接口定义、性能要求、安全性等，这个根据具体业务进行评估，例如高并发场景，频繁请求的场景等。同时还需要考虑一些隐性需求。技术负责人可以前置到需求沟通和设计阶段，给产品经理提供必要的技术支持，协助评估产品方案的可行性。3.1.3 提前进行会议邀请角色：产品经理，建议提前1天
给出会议时间、地点、预计需要时间。一方面，这样可以让参与人员得知你对整个需求评审会议内容的掌控；另一方面，参与人员能根据时间安排手头上的其他任务，以致于节奏不被打乱。
3.2 评审中3.2.1 节奏把控角色：产品经理
产品是会议主持人，那么自然就担当着会议节奏把控和主持的角色。当角色众多时，其实是比较容易出现讨论内容溢出的问题，大家一聊开就上头了，结果导致会议开了足足几个小时都还没有产生定论。需求评审中产品要做的第一件事就是把控整个会议的节奏，既要及时把聊得起兴的大家拉回评审中，还要尽量按照参会人的精力去做好节奏的规划，让整场会议高效而轻松。
3.2.2 情绪管理和争论处理角色：全员
很多产品都惧怕需求评审，感觉研发、测试在找茬，有针对自己的感觉。这个时候最重要的一点，首先，做好自己的情绪管理，有问题抛出是好事，说明大家都听了并且在思考。其次，换位思考，尝试先根据对方表达的看法去梳理他的思路，然后用自己的理解复述一遍，看对方是否认可你的理解。接下来，再根据你的理解去进行判断并阐述自己的观点，看是否能够得到对方的认可。最后，如果实在在会上没法沟通，那就告知大家：自己会先记录下待讨论的问题，会后再进行讨论，后续的议程继续。“下来再讨论”真的是一句解决会上冲突的万能金句。
3.2.3 关注讲解方法和策略角色：产品经理
不要上来就讲方案，大家一定会懵圈，个人总结下来，可以按照以下的步骤推进：
需求背景：传达本次需求的背景，为什么有这样的需求，解决了什么问题。需求价值：为什么要做本次需求，做完后会给产品带来哪些价值（例如：提高用户留存、提高转化率或者是提升用户体验等)。需求概述：需求提出方想实现什么，描述该产品方案如何解决业务述求。方案详解：详细的进行产品方案讲解，让与会人员都充分的了解产品方案，判断是否会牵一发而动全身。建议分模块讲解，一个模块讲解完后，可以稍微停顿一会，询问大家是否有疑问，并进行答疑（如果是一个比较复杂的问题，讲解的时间比较长，可以考虑会议后单独和相关的人员进行沟通）；会议中如果出现一些自己未考虑到的点，一定要记录下来，会后进行完善。3.2.4 刻意关注、沉浸式参与到评审中角色：研发、测试
需求评审的时候不要在会议上面玩手机或者干其他事情，因为如果需求理解不深刻，后面相关的工作就很难开展。需求中产品设计不合理、很难理解、逻辑有问题、以及可能影响原功能的地方，对于这些点我们要抛出疑问进行澄清，从而推动产品进行修改，最終达成一致。需求评审会上，前端、后端和测试分别都关注什么？
后端：
关注方案可行性的评估，重点在需求逻辑可行性、技术难度、工作量和改动成本上关注需求逻辑的覆盖度，帮助产品经理做好逻辑的查漏补缺关注研发过程中的实现风险前端：
关注需求场景及业务合理性关注页面样式交互，为产品经理提出一些更合理的样式交互建议关注技术方案和成本评估，尤其关注新页面中交互与已有统一标准组件的评估测试：
关注需求的逻辑性及合理性关注需求描述的准确程度、是否排除二义性等关注整个迭代的质量风险及进度，保证交付的稳定性3.3 评审后3.3.1 评审会议纪要角色：产品
会议结束之后，确实可以长舒一口气，开始准备下一阶段的工作了，但注意：会后还是需要做好
会议纪要、会议同步和后续问题的跟进。会议纪要主要分为三个部分：
待讨论：指会上的遗留问题待完善：指会上确认要改的问题，后续要完善在文档中已确认：指会上讨论得出要做/不做的结论的点3.3.2 待办项跟进角色：产品+相关人员
整理会议中记录的问题，在原型和PRD中进行调整和补充，有需要的话，可以拉上相关的人员针对这些问题，进行二次评审。好的产品一定得有项目管理能力，在整个开发过程中，一定要定期跟进开发进度，避免需求延期或者需求缺失。另外，开发过程中，如果涉及到需求的调整.一定要在原型和 PRD中标记修改记录，并且及时通知相关的人员，确保理解一致4 总结如何高效、保质、愉悦的进行需求评审，各角色专业能力是基础，但更需要大家相互配合，互相尊重，通力合作才能打造更好的产品。
作者：京东物流 王敏
来源：京东云开发者社区 自猿其说Tech
