1 前言
面对需要评审，无论是发起人产品经理，还是参加人研发、测试都是有苦难言：
- 在会议上，产品间接被研发工程师怼计划不合理，技术无奈实现。
- 参加人员没有围绕评审会的指标去探讨而是衍生到其余问题，导致效率不高。
- 需要评审会议顺利完结，但在理论开发中却一直发现需要破绽，导致不能依照打算顺利执行。
怎么可能让需要评审更高效、保质呢？作为测试人员又如何在其中施展价值呢？依据本人的工作教训，下文介绍如何在需要评审中做到更标准，来缩小评审过程呈现的问题，以此进步需要评审效率、晋升需要评审会议品质，来营造一个比拟轻松的产研单干气氛。
2 什么是需要评审
通过将需要规约文档公布给利益相关者进行查看，发现需要规约中存在缺点（如谬误、不完整性、二义性等）的过程。简略点来说，就是在产品布局完之后，把团队人员汇集一起探讨并评审计划的会议。如计划通过，则按布局的计划，持续往下施行；如计划不通过，依据意见进行改善。
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