前段时间参加了一些项目评审会议,发现同事对评审工作的存在一些常见的误区,现将这些问题罗列出来,抛砖引玉,以便管理中心的CMMi推进小组跟进。
一个是对评审的方式的理解存在误区,评审不是一定邀请大批同事参加一个评审会,这样的工作方式很多时候会变成效率低下浪费资源的方式。评审其实可以分正式评审与非正式评审两种形式,而且往往在正式评审之前,多采用非正式评审的方式进行预先评审。
非正式评审会的处理形式如下:
- 组织者(多由项目经理承担)组织项目成员编制阶段性成果的产出物,收集电子的产出物,完成评审的提交物;
- 组织者落实参与非正式评审的人员范围;
- 组织者提交电子评审资料,让参加非正式评审的人员通过电子的形式、非集中会议的形式,从各自的岗位、思考、评判角度针对评审文档进行审核;
- 评审人员将审核的意见通过电子的形式反馈给组织者;
- 组织者将审核意见进行集中过滤,并且组织项目组成员针对提出的审核问题,提出处理意见和方法;
- 将审核意见的处理意见和方法反馈给评审人员,可以通过会议的形式召开总结会,或者使用电子手段进行总结。
非正式评审往往在项目阶段的中期,有的项目甚至设立多个非正式评审的检查点。正式评审往往发生在项目阶段的里程碑,如果在正式评审前已经进行过非正式评审,那么正式评审落实为具体的成果的成功率就比较高。
对于正式评审,很多同事理解成一次会议,这样的理解是错误的。因为会议的出发点是用来落实问题,这样的会议更加有效,忽视了这样的出发点,我看到需求评审会议变成了需求分析学习会,设计评审会变成了设计学习交流会。
正式评审与非正式评审的处理形式非常类似,只是因为这是一次正式的下结论评审,所以使用正式评审的字眼来表达严肃性罢了,并且最后必须有评审小组给出结论性的评审意见。正因为严肃性,最后针对审核意见的处理意见和方法,多以正式会议的形式召开会议,达成项目组和评审小组之间的共识。
另一个是对参与评审人员的理解存在误区,参见的误区是:需求评审只是负责业务需求的同事参加,设计评审是只有开发人员,设计人员参加。其实参与评审人员可以包括以下的各领域:业务顾问、需求分析、技术设计、项目管理、技术开发,甚至是法务工作者。
为什么呢?因为参与评审的人员会从各个角度去审阅提交的文档,以设计评审为例,需求分析的同事评审的是设计对需求内容的覆盖、匹配是否有遗漏,项目管理者会审阅设计的成果落实在计划上是否可行、项目的风险在设计阶段识别出什么新风险、那些在设计阶段被解决,开发者会审阅设计的结果是否有Bug、不要等到开发的时候才去发现设计的Bug。
最近参与的评审工作,我发现进行设计评审的组织者,大多忽略了计划和工作内容评审,因为设计的结果再好,也必须是后续可以推进的工作,应该能够体现在工作量和工作计划中的思路。