浅谈如何更好的进行需求评审

1 前言

面对需求评审，无论是发起人产品经理，还是参与人研发、测试都是有苦难言：

1. 在会议上，产品直接被研发工程师怼方案不合理，技术无法实现。
2. 参与人员没有围绕评审会的目标去讨论而是衍生到其他问题，导致效率不高。
3. 需求评审会议顺利结束，但在实际开发中却不断发现需求漏洞，导致不能按照计划顺利执行。

怎样能够让需求评审更高效、保质呢？作为测试人员又如何在其中发挥价值呢？根据自己的工作经验，下文介绍如何在需求评审中做到更规范，来减少评审过程出现的问题，以此提高需求评审效率、提升需求评审会议质量，来营造一个比较轻松的产研合作氛围。

2 什么是需求评审

通过将需求规约文档发布给利益相关者进行检查，发现需求规约中存在缺陷（如错误、不完整性、二义性等）的过程。简单点来说，就是在产品规划完之后，把团队人员聚集一起讨论并评审方案的会议。如方案通过，则按规划的方案，继续往下实施；如方案不通过，根据意见进行改善。

2.1 需求评审的参与人员

每个公司的团队结构不一致，但通常包括：产品经理、开发工程师（前端、后端）、测试工程师、设计（UI、UE）、需求提出方。

2.2 为什么要做需求评审

产品眼中的需求，交互眼中的需求，视觉眼中的需求，开发眼中的需求，测试眼中的需求大相径庭,需要让团队中每位人员对需求有统一的了解，通过需求评审来拉齐大家的认知。主要作用是：

1. 有助于团队中每个角色了解用户需求，理解产品需求的由来，考虑需求合理性及用户体验感。
2. 对需求文档进行评审，尽早发现需求中的问题，减少后期修改缺陷的成本。
3. 使开发团队中每个角色对需求的理解保持一致，减少了后期的沟通成本。
4. 沟通需求细节，确认需求是否可以实现以及实现方式，有利于测试人员对功能实现逻辑的理解，完善测试用例。
5. 确认交付内容和预期时间。

3 如何进行需求评审

做好一场需求评审，大致分为三个阶段：评审前、评审中、评审后。

3.1 评审前

3.1.1 做好产品基本功

角色：产品经理

1. 和业务方认真推演产品要解决的问题，深挖业务述求，相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。
2. 充分准备需求原型和PRD，反复推敲产品方案，确保所有的功能点都能实现闭环，正常和异常场景都要考虑。任何一个遗漏的场景，都可能成为评审会上的“雷点”，产品们需要提前扫雷。
3. 提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法，技术的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来，驱动技术前置。
4. 提前将完整的原型和PRD发给相关人员，以便他们提前阅读相关文档，深刻理解需求，有疑问的点提前标注出来，方便在开会的过程中积极地去参与这个会议，抛出疑问点。

3.1.2 技术人员提前介入

角色：研发、测试，建议提前2天

1. 团队制定好规范，利用各自碎片化时间，提前介入进来理解需求。前期了解过程中除了关注功能要求，还需要关注数据类型、接口定义、性能要求、安全性等，这个根据具体业务进行评估，例如高并发场景，频繁请求的场景等。同时还需要考虑一些隐性需求。
2. 技术负责人可以前置到需求沟通和设计阶段，给产品经理提供必要的技术支持，协助评估产品方案的可行性。

3.1.3 提前进行会议邀请

角色：产品经理，建议提前1天

给出会议时间、地点、预计需要时间。一方面，这样可以让参与人员得知你对整个需求评审会议内容的掌控；另一方面，参与人员能根据时间安排手头上的其他任务，以致于节奏不被打乱。

3.2 评审中

3.2.1 节奏把控

角色：产品经理

产品是会议主持人，那么自然就担当着会议节奏把控和主持的角色。当角色众多时，其实是比较容易出现讨论内容溢出的问题，大家一聊开就上头了，结果导致会议开了足足几个小时都还没有产生定论。需求评审中产品要做的第一件事就是把控整个会议的节奏，既要及时把聊得起兴的大家拉回评审中，还要尽量按照参会人的精力去做好节奏的规划，让整场会议高效而轻松。

3.2.2 情绪管理和争论处理

角色：全员

很多产品都惧怕需求评审，感觉研发、测试在找茬，有针对自己的感觉。这个时候最重要的一点，首先，做好自己的情绪管理，有问题抛出是好事，说明大家都听了并且在思考。其次，换位思考，尝试先根据对方表达的看法去梳理他的思路，然后用自己的理解复述一遍，看对方是否认可你的理解。接下来，再根据你的理解去进行判断并阐述自己的观点，看是否能够得到对方的认可。最后，如果实在在会上没法沟通，那就告知大家：自己会先记录下待讨论的问题，会后再进行讨论，后续的议程继续。“下来再讨论”真的是一句解决会上冲突的万能金句。

3.2.3 关注讲解方法和策略

角色：产品经理

不要上来就讲方案，大家一定会懵圈，个人总结下来，可以按照以下的步骤推进：

1. 需求背景：传达本次需求的背景，为什么有这样的需求，解决了什么问题。
2. 需求价值：为什么要做本次需求，做完后会给产品带来哪些价值（例如：提高用户留存、提高转化率或者是提升用户体验等)。
3. 需求概述：需求提出方想实现什么，描述该产品方案如何解决业务述求。
4. 方案详解：详细的进行产品方案讲解，让与会人员都充分的了解产品方案，判断是否会牵一发而动全身。建议分模块讲解，一个模块讲解完后，可以稍微停顿一会，询问大家是否有疑问，并进行答疑（如果是一个比较复杂的问题，讲解的时间比较长，可以考虑会议后单独和相关的人员进行沟通）；会议中如果出现一些自己未考虑到的点，一定要记录下来，会后进行完善。

3.2.4 刻意关注、沉浸式参与到评审中

角色：研发、测试

需求评审的时候不要在会议上面玩手机或者干其他事情，因为如果需求理解不深刻，后面相关的工作就很难开展。需求中产品设计不合理、很难理解、逻辑有问题、以及可能影响原功能的地方，对于这些点我们要抛出疑问进行澄清，从而推动产品进行修改，最終达成一致。
需求评审会上，前端、后端和测试分别都关注什么？

后端：

• 关注方案可行性的评估，重点在需求逻辑可行性、技术难度、工作量和改动成本上
• 关注需求逻辑的覆盖度，帮助产品经理做好逻辑的查漏补缺
• 关注研发过程中的实现风险

前端：

• 关注需求场景及业务合理性
• 关注页面样式交互，为产品经理提出一些更合理的样式交互建议
• 关注技术方案和成本评估，尤其关注新页面中交互与已有统一标准组件的评估

测试：

• 关注需求的逻辑性及合理性
• 关注需求描述的准确程度、是否排除二义性等
• 关注整个迭代的质量风险及进度，保证交付的稳定性

3.3 评审后

3.3.1 评审会议纪要

角色：产品

会议结束之后，确实可以长舒一口气，开始准备下一阶段的工作了，但注意：会后还是需要做好

会议纪要、会议同步和后续问题的跟进。会议纪要主要分为三个部分：

1. 待讨论：指会上的遗留问题
2. 待完善：指会上确认要改的问题，后续要完善在文档中
3. 已确认：指会上讨论得出要做/不做的结论的点

3.3.2 待办项跟进

角色：产品+相关人员

1. 整理会议中记录的问题，在原型和PRD中进行调整和补充，有需要的话，可以拉上相关的人员针对这些问题，进行二次评审。
2. 好的产品一定得有项目管理能力，在整个开发过程中，一定要定期跟进开发进度，避免需求延期或者需求缺失。
3. 另外，开发过程中，如果涉及到需求的调整.一定要在原型和 PRD中标记修改记录，并且及时通知相关的人员，确保理解一致

4 总结

如何高效、保质、愉悦的进行需求评审，各角色专业能力是基础，但更需要大家相互配合，互相尊重，通力合作才能打造更好的产品。

作者：京东物流 王敏

来源：京东云开发者社区 自猿其说Tech