众所周之，产品的缺陷发现得越早代价越小，十乘十乘十法则说的就是这个道理：需求阶段的缺陷遗留到设计和开发阶段，其代价会增加十倍；如果遗留到测试阶段，其代价会增加百倍；如果遗留到客户那里，则代价会增加千倍。因此，产品研发过程中，人们都尽可能地在早期把缺陷发现了。

产品测试是发现缺陷的重要手段，然而，只有当产品构建出来，才可能执行产品测试活动。产品研发的前期如需求、设计阶段如何发现问题呢？其实，广义的测试包括静态测试和动态测试，我们通常所说的测试是指动态测试，即产品构建后让其运行起来从而发现产品缺陷的过程。静态测试又被称为交付件评审，在产品交付件不运行的情况下通过查找的方式发现产品缺陷。技术文档、图纸等研发项目交付件因为无法运行，只能通过评审来发现问题，往往这些技术文档、图纸又是项目前期产生的，其中的缺陷如果没有被及时发现，流入了下一阶段，不仅会带来数十倍、百倍的返工成本，还可能严重影响项目工期和团队士气，因此有效的交付件评审对产品研发的成功至关重要。十多年前，华为引入IPD、CMM方法论和模型进行研发过程变革，被大家最先广为认可的一项变革领域就是交付件评审，所以当时在华为有一句话深入人心：凡事必review。评审如同洗脸刷牙一样，成为了华为研发人员的习惯，甚至软件代码写完了，可以运行了，都不允许立刻测试，只有经过了有效的评审才能测试，因为聪明的华为人发现，通过评审发现缺陷远比测试效率更高、效果更好。

然而，作为汉捷咨询顾问，接触众多的国内研发企业，发现能够有效开展交付件评审的企业真是少之又少，一项简单而非常有效的活动居然没有普及真是非常遗憾，难怪大家都去买日货！下面一个交付件评审场景是否也在您的企业里发生？

产品需求分析人员在周五上午完成了需求文档，并汇报给项目经理，项目经理要求下午先组织一次内部的需求评审（客户不参与），要求所有的开发人员和测试人员都参加，项目组之外的几位技术专家也要尽可能邀请。

下午的评审会上，项目经理和十名项目成员都到了，但项目之外的专家只来了一位，而且评审中途又被电话叫走。需求分析人员用投影仪把需求文档显示在会议室的屏幕上，然后从头到尾开始讲解需求文档，过程中有人对需求不理解或者有质疑，需求分析人员会停下来解答、讨论，如果确认是需求文档的问题，则由需求分析人员会做一个简单的问题记录，以备下来修改。评审过程中，发现7、8处错别字，有3个需求点，需求分析人员也没有搞清楚，经过会议上的讨论，基本搞清楚了。该会议一共持续了3个小时，一共发现10个非错别字类需求问题，其中有7个问题是由项目经理提出的。

评审会结束后，需求分析人员根据评审会所发现的问题对需求文档进行修改，然后发给项目经理，项目经理进行简单的复查后发给客户，准备进行需求外部评审。

很多企业的交付件评审状态与上述案例所描述的非常类似，以至于有时为企业做培训时使用此案例，有学员会惊讶的说：“老师，你怎么用我们公司的案例！”这样的评审实在低效，耗费了大量工时，而收效（发现的技术问题）并不大。因此，大部分企业的研发项目并不欢迎交付评审活动，他们通常以项目进度急迫为由，根本不组织交付件评审，即使组织了评审也就类似上面案例所描述的那样，耗费了大量了人力，发现的有效问题并不多。这样的评审方式，也验证大家普遍存在的“评审效率不高”这样的信念，如此便陷入恶性循环，下次的评审更加难以组织。

真的是评审活动本身效率低吗？显然不是，既然交付件评审能够在优秀的企业里被制度化，就很可能说明交付件评审是个“好活动”，只是我们没有把它执行好。那么问题到底出在哪儿呢？显然案例中的评审过程存在很多问题，比如，文档并没有提交发出来，给各个评审专家预留充分的时间会前阅读资料；作者没有做好自检，甚至明知有些地方没有搞清楚，把问题带到了评审会议上浪费了大家的时间；作者修改后的文档也没有发给各位评审专家做确认，有可能问题漏改或改错......那么正确的交付件评审过程是什么？请关注下期。