这是《落叶》文集里第 324 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第十章 为什么需求评审总是那么的耗时费力呢？
在经历了几天的思考、答题、学习、讨论和整理之后，终于迎来了第一次需求评审会议，我一个人去参加了这次会议，因为产品经理说，这次主要是针对需求的概要、优先级和技术可行性，所以不需要所有具体执行人参与。
参加完这次算是需求初评会议之后，我发现，除了我之前从老大那和书本上学习到的东西之外，还对之前老大在管项目时的一些任务安排有了不一样的认识。原来有时候会奇怪老大为什么不在需求初评之前就分配任务给我们呢？
现在自己参与了，才大概明白了一些，在没有开始评审之前，我根据需求的概要和初稿，对那些需求只是有了自己的认知和理解，但并不全面，也不一定正确，那时候如果就将任务分配掉，可能在模块关联性和测试量上并不合理。
所以，通过需求初评会议了解了关于需求背景、商业价值、优先级，以及讨论需求可行性时提及的技术方案，可以对需求的功能模块或业务分类，以及大概的测试复杂度和工作量有个基本的认知，基于这些，就可以相对合理地做任务分配了。
分配完任务，我简单设定了一个时间节点，让各个需求的任务责任人开始阅读需求初稿，同步地，我也会将陆续完稿的需求文档转发给相关责任人，让他们按照前面说的需求评审检查表做一轮测试，将问题及时反馈给对应的产品经理。
当需求文档完稿之后，产品经理通常会立即召开正式的需求评审会，这时候一般不会只开一个会议，而是会拆成几个会议，所有具体的需求负责人都需要参加。这些个会议，老大要求我都要参加，具体的需求文档的问题或不清楚的地方，如果会议前没有弄清楚，具体的负责人都会带着去参加评审，在会议中问清楚。而对于会议中没有讨论清楚或得到解答的问题，包括在会议中碰撞出的一些新问题，相关需求责任人要在会议之后持续跟踪，直到弄清楚为止。
而我做为项目的测试负责人，参加所有的需求评审，一方面是为了了解熟悉所有功能性需求细节，另一方面主要是针对一些非功能性需求，去明确一下相关的测试必要性和可行性，比如兼容性测试、性能测试、安全测试等等。同时，这些对后续评审所有的测试设计都非常有帮助。
另外还有两点特别需要注意:
1. 在需求评审会中，有关业务逻辑遗漏较多或对不清晰的地方争议较多时，一定要坚持要求复评，因为产品经理往往会为了省事，在会后补充一下，就直接把更新后的需求文档发给项目干系人了，而新补充的那些内容，可能因为没有经过会议评审，而导致每个人都有不一样的认知和理解。
2. 需求评审会里大家提出的所有问题，都得要求产品经理记录下来，一一解答或澄清，并在需求文档里修订或标注出来，在复评的时候快速回顾一下。尽可能地把问题都在需求评审阶段给弄清楚了，这样可以大大减少在提测之后，发现产品经理、开发和测试对于某个需求点的认知和理解都不一致，而把大量的时间浪费在重新讨论需求，决定是否要修改当前的实现，或者说判定某个 Bug 是不是 Bug这类事情上。
《告诉你如何从执行测试到管理测试》带你迈出第（10）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
