浅谈如何更好的进行需求评审 | 京东物流技术团队

京东云开发者
• 阅读 209

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

点赞
收藏
评论区
推荐文章
Easter79 Easter79
2年前
svn集成ReviewBoard,让post
代码评审(CodeReview)不但可以提高质量,而且还是一个知识共享和指导的极好的手段。代码评审(CodeReview)一般有两种形式:precommitreview,postcommitreview。precommitreview是指代码提交到代码库前进行代码评审;postcommitreview是指代码提交到代码库
如何有效的进行用例评审
用例评审对于质量同学是再熟悉不过的一个重要环节,用例评审也是非常有效的保障测试质量的手段,但我们质量同学做了这么多次的评审,有没有去思考怎样去进一步提升用例评审的质量,使用例评审更加有效呢,这里呢抛砖引玉,总结一下我个人对用例评审的思考。
实践篇(三):如何有效评审软件架构图?
设计意图的传达是架构可视化关注的重要维度,在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图,这些图形化表述在设计意图传达效果层面表现不一,本文从图形化的视角为软件架构图的评审关注点提供了参考。
Wesley13 Wesley13
2年前
Ubuntu 18.04+Postgresql 10+Gerrit 2.15.19+nginx 1.14 安装配置指南
Ubuntu18.04Postgresql10Gerrit2.15.19nginx1.14安装配置指南要保证代码的高质量,那必须要进行同行评审代码检查,所有代码都必须经过Rev
Stella981 Stella981
2年前
ReviewBoard代码评审实践总结
代码评审代码评审(CodeReview),顾名思义是对代码进行评审,是软件工程的活动之一。通过代码评审可以保证代码质量,促进团队知识共享……好处多多。版本控制与代码评审软件工程的各个活动总是离不开工具的支持。代码评审工具首先必须和版本控制工具相结合的。现在主流的两种版本控制工具:SVN和GIT。GI
Wesley13 Wesley13
2年前
2020团队OKR更新
前言本来已经实施的OKR计划因为突如其来的疫情打乱了节奏,现在团队已经没人能够记得自己的OKR是什么了。目前国内疫情早就趋于平稳,是时候找回节奏了。在这里更新团队OKR强化自组织,持续优化和开放透明的团队文化第三四季度彻底执行OKR覆盖全员月度评审
Wesley13 Wesley13
2年前
APP项目合作流程规范
整体流程说明:MRD评审:磨刀不误砍柴工1、MRD对于问题细节分支和细节描述希望能够更多覆盖,避免开发过程中的反复确认和信息不对称。2、MRD评审,RD&QA都要带着问题去评审,这样也可以更好帮助产品规避没有想到的边界问题。开发物料管理:清晰才能简单可依赖PM:负责上传最新MRD文档、交互文档、最终视觉稿、切图标注到项
linbojue linbojue
1个月前
公文写作模板—通告(通用经典模板)
关于公布第××届应征论文评审结果的通告在第××届会××年×月×日至×月×日征文期间,共收到来自、、、大专院校及有关行业的境内外论文××篇。大会技术委员会组织专家根据论文的学术水平,按照系统运行、继电保护、电网调度自动化等专业划分,经过严肃认真的评审,从全部
京东云开发者|代码评审的价值和规范
评审目的代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代,始终保持一个较高的水平,所有在评审中使用的工具和流程都应是为此目的而设计的。评审原则鼓励质疑保持代码风格,遵守开发规范
新支点小玉 新支点小玉
4个月前
信息化建设项目验收
信息化建设项目验收确认测试内容一般包括:需求评审、测试方案、实施测试及回归测试、资料评审四部分。(一)验收评测工作主要包括:文档分析(招投标文件、建设合同、可研分析、需求规格说明书等)、测试方案制定、现场测试、问题单提交回归测试、测试报告;(二)验收测试内