同事对评审的常见误区

前段时间参加了一些项目评审会议，发现同事对评审工作的存在一些常见的误区，现将这些问题罗列出来，抛砖引玉，以便管理中心的CMMi推进小组跟进。 

一个是对评审的方式的理解存在误区，评审不是一定邀请大批同事参加一个评审会，这样的工作方式很多时候会变成效率低下浪费资源的方式。评审其实可以分正式评审与非正式评审两种形式，而且往往在正式评审之前，多采用非正式评审的方式进行预先评审。

非正式评审会的处理形式如下：

1. 组织者（多由项目经理承担）组织项目成员编制阶段性成果的产出物，收集电子的产出物，完成评审的提交物；
2. 组织者落实参与非正式评审的人员范围；
3. 组织者提交电子评审资料，让参加非正式评审的人员通过电子的形式、非集中会议的形式，从各自的岗位、思考、评判角度针对评审文档进行审核；
4. 评审人员将审核的意见通过电子的形式反馈给组织者；
5. 组织者将审核意见进行集中过滤，并且组织项目组成员针对提出的审核问题，提出处理意见和方法；
6. 将审核意见的处理意见和方法反馈给评审人员，可以通过会议的形式召开总结会，或者使用电子手段进行总结。

非正式评审往往在项目阶段的中期，有的项目甚至设立多个非正式评审的检查点。正式评审往往发生在项目阶段的里程碑，如果在正式评审前已经进行过非正式评审，那么正式评审落实为具体的成果的成功率就比较高。

对于正式评审，很多同事理解成一次会议，这样的理解是错误的。因为会议的出发点是用来落实问题，这样的会议更加有效，忽视了这样的出发点，我看到需求评审会议变成了需求分析学习会，设计评审会变成了设计学习交流会。

正式评审与非正式评审的处理形式非常类似，只是因为这是一次正式的下结论评审，所以使用正式评审的字眼来表达严肃性罢了，并且最后必须有评审小组给出结论性的评审意见。正因为严肃性，最后针对审核意见的处理意见和方法，多以正式会议的形式召开会议，达成项目组和评审小组之间的共识。

另一个是对参与评审人员的理解存在误区，参见的误区是：需求评审只是负责业务需求的同事参加，设计评审是只有开发人员，设计人员参加。其实参与评审人员可以包括以下的各领域：业务顾问、需求分析、技术设计、项目管理、技术开发，甚至是法务工作者。

为什么呢？因为参与评审的人员会从各个角度去审阅提交的文档，以设计评审为例，需求分析的同事评审的是设计对需求内容的覆盖、匹配是否有遗漏，项目管理者会审阅设计的成果落实在计划上是否可行、项目的风险在设计阶段识别出什么新风险、那些在设计阶段被解决，开发者会审阅设计的结果是否有Bug、不要等到开发的时候才去发现设计的Bug。

最近参与的评审工作，我发现进行设计评审的组织者，大多忽略了计划和工作内容评审，因为设计的结果再好，也必须是后续可以推进的工作，应该能够体现在工作量和工作计划中的思路。