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
