8.7.2　评审会中遇到的问题分析

在需求评审的时候，应该根据不同的需求层次而进行不同的评审。因为笔者经常参加需求评审会议，所以对需求评审中常见的问题有所了解，几个案例和场景如下所示：

案例&知识：

（1）某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。

（2）某次需求评审会，主要是公司内部相关领域的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。

（3）某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有达到预期效果，不得不改日重新进行。

（4）在需求评审会，与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。

综上，需求评审常见问题汇总如下：

（1）目标性需求没有沟通好，后面的需求变成空中楼阁。

（2）缺乏评审的可操作依据，遗漏评审内容。(https://www.daowen.com)

（3）没有做好前期准备工作，导致评审时间长，效率低。

（4）没有选择合适的评审人员，无法获得有价值的反馈。

（5）参加人员过多，容易陷入细枝末节的讨论，会议演变成一场毫无意义的讨论。

针对以上问题，提出如下建议：

（1）准确说明需求文档的质量特性作为评审的标准。例如，国标文档（GB/T9385-2008）提出来的正确性、完整性、一致性、无二义性、可修改性、可跟踪性和可验证性等。

（2）编写辅助文档进行初步验证。例如，根据用户需求所要求的产品特性，写出黑盒功能测试用例；在需求开发早期起草一份用户手册，用它作为验证的参考并辅助需求分析。

（3）需求文档的编制人员包括业务领域专家和信息化系统建设人员。只有业务领域专家写不出来产品功能的内在本质特性，只有信息化系统建设人员会陷入技术实现而对业务关注较少，点有双方共同参与、共同编制、多方讨论，才会编制出既符合业务现状又具有技术实现途径的需求文档。

（4）需求获取不是一次性工作。需求获取不仅仅在分析阶段，在问题定义、可行性研究阶段及业务的设计和开发过程中都会有往复，对此要做好准备。但也要分清主次，在进行需求评审时主要的需求是确定的。