标签：需求 会议 工程师 无效 评审 文档 测试 素养 软件测试
你一定听说过这样的一句话——每天不是在开会，就是在开会的路上。
这句话其实是对会议多情况的一种调侃，但同时这句话里也带有一些对开会反感。
不过请大家想一想，为什么我们会反感一些会议？很大一部分原因是这些会议冗长且毫无结果，效率非常低。
为了尽量减少这种情况的发生，我会分享一种项目会议当中比较重要的评审会议，让大家告别无意义meeting。
本文主要讲一下评审会议的必要性，以及如何高效开展评审会议。
什么是评审
评审，指评议和审查、审议。
为什么要进行评审
01
评审一般是集体活动，有助于从多角度提升工作产品（即评审对象）的质量。
评审的与会人，可能包括项目干系人、技术专家、业务专家、高层管理者，那么与会人的角色不同，对于工作产品的评判角度也是不同的。
例如，在实际项目中，当针对测试设计文档进行评审时，产品经理更关注用户需求有没有得到全面覆盖，开发人员更关心他们对需求的理解与测试人员是否一致，测试评审专家除了关注业务功能有没有覆盖到之外，还会评审测试设计方法是否合理，是否考虑了各个质量属性。
02
评审会议可以提供一个契机，针对一些争议点进行讨论对齐，做到统一思想。
例如，评审需求规格说明书时，项目多方干系人都会在场，一方面可以围绕每条客户需求做好澄清，另一方面，各评审人员可以从各自的专业角度出发，提出需求存在的问题，或者文档没有阐述到的方面。
比如一款APP，产品经理在需求评审会上讲解关于用户注册/登录的需求。
测试人员由于具备APP使用方面的丰富的经验，会提出针对这个需求的更细节方面的问题：
- 用户是先注册再登录还是登录即注册
- 是否既支持验证码登录又支持密码登录
- 验证码的有效期是多久
- 用户登录一次的鉴权保存的时间是多久
- 是否要做用户取消注册的入口等等
随后，针对这些新提出来的需求点，与会人会尽量达成一致，会上无法统一观点的，记录会议纪要，会后闭环。
03
作者自己很难发现自己的工作产品的问题。
曾经在一本书上看到这样一个观点，我觉得非常有道理：因为你记得你的工序，所以，你会认为你的作品是正确的。
其实，这是人在输出产物时候特定的思维方式和输出流程导致的。不管输出的是什么，你的过程通常都是：想出一个思路，然后按照这个思路一直理下去，最后把思路实现为成果。
所以，你的思维方式一直是正向的、顺序的，并且你对整个过程太熟悉了，熟悉到你认为一切都是正确的，这其中当然也掺杂着对自己的“宝贝”的偏爱。
这个时候，评审的作用就体现出来了：找一些毫不知情的人来提意见，因为他们不清楚产品的输出过程，也不会掺杂私人感情，此时他们的评价就是客观的。
另外，大家一定也有过同样的经历。你刚写出来的东西，怎么看怎么顺眼。但是过了1-2两个月再次阅读，你可能会发现很多不合理的甚至是错误的地方。
04
评审是一种静态测试，性价比高。
这项活动可以使问题提前暴露，且测试成本较动态测试低，修复成本也低。
例如，如果在需求评审阶段，就识别出来客户要求支持两种支付缴费方式：微信和支付宝，而需求文档中只提到了微信支付，此时，只要更新需求文档即可。
但是如果到了编码阶段才识别出来，那么，会造成编码返工，甚至架构调整。如果再晚一点，到测试阶段才发现此漏洞，会导致更大量的返工，并且对项目进度造成更明显的影响，从而极有可能导致项目的失败。
试想一下，如果再晚一些，等到版本发布给用户去使用之后，由用户提出来，影响会怎样？损失的是什么？
可见，评审阶段修正错误的成本有多低！
那么，到底什么情况下需要启动评审活动，评审有哪些类型呢？下面只举一些常见的例子。
评审的类型
01 工作计划评审
主要包括项目计划、开发计划、测试计划等。
02 设计文档评审
概要设计、详细设计、测试设计。
03 代码评审
版本开发代码评审、自动化工具代码评审。
04 管理评审
版本发布评审、缺陷评审、风险评审。
如何更好的开展评审
评审本身可以看做是一种特殊的会议。想要更加高效，那么会前充分的准备、会上高效的评审、会后严格的闭环都是非常重要的。
下面列举了对评审成功进行至关重要的几个因素。
01
评审对象作者已完成初稿(具备评审条件的初稿)。
和软件产品一样，如果评审对象没有达到入口条件，仅仅是个半成品，会浪费评审相关人员的时间，甚至影响项目进度。
02
评审主题、评审目的已明确。
评审主题和目的不明确，则会出现在评审会议上漫谈一些与评审对象无关的话题，浪费时间。
比如，一个评审软件产品是否能够发布的决策会议，在不清楚评审目的的情况下，可能会出现开发和测试在讨论bug的产生原因，偏离会议主题。
03
确定好评审时间、地点，以及与会人、组织者、主持人、纪要人。
与会人名单不准确，会出现评审会上一些重要关键人员不在的情况。
纪要人不明确，会导致会上的重要信息没有得到及时记录，从而形成低效会议，甚至是无效会议。
04
会议材料提前下发给与会人，并预留足够的时间进行独立评审。
一个草草组织、无充足时间浏览会议材料的会议，可想而知是什么样的。
与会人直到会议开始才第一次见到相关文档，评审时，经常停下来理解文档想说什么。这样的会议，就像盲人摸象，简直就是在浪费时间。
05
正式评审会议上，评审主持人具备足够的组织协调和沟通解决能力，保证会议秩序，控制好会议效率和效果。
下面是测试资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
最后： 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）
喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
好文推荐
转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！
面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…
标签：需求,会议,工程师,无效,评审,文档,测试,素养,软件测试 来源： https://blog.csdn.net/AI_Green/article/details/120832285
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。