实践证明:阶段性评审在项目的全面质量管理中占据了非常重要的作用,它像信息化项目过程中的“过滤器”,被用于项目实施过程中的每一个重要环节点(特别是针对具有里程碑意义的阶段成果)上。技术评审的目的既是为了发现被评审项的缺陷,也是对阶段成果的质量验证。评审结果是否通过标志着项目是否能够进入下一个开发或建设阶段。
  之所以要组织阶段评审,我考虑基于下面两方面的考虑:
  第一,对于有多家企业共同承建的大型信息化工程,例如我曾经组织实施的城市运行指挥平台项目,有六家企业分别承担一些专项子系统的开发建设任务。如果仅根据建设任务的分工,完全由各承担任务的人员自行控制所负责部分的质量,将会是项目承担很大的风险。因为我们每一个人的知识和能力都会有局限性,具体承担设计实施某项任务的技术人员,无论他来自哪一个企业,都可能在对项目目标或需求的认识方面,技术设计方面、以及实施经验方面存在一定的偏差和弱项。如果不加以控制,对整体项目的质量将会产生短板效应。
  在项目的关键环节,我们组织参与项目建设的各个企业的技术骨干共同针对每个子系统进行阶段评审工作(也可说是交叉评审),可将大家的智慧和经验得到共享,纠偏补漏,互相切磋和借鉴,补充当事人在经验、知识、信息方面的不足。组织多人进行阶段评审,是借助不同人员在对问题的认识、技术水平和经验等方面可能存在的差异性,来达到质量控制把关的目的。通过交叉评审,还可以发现各企业分别承担建设的子系统之间接口不一致的问题,以确保项目的实施质量。对于关键环节或关键技术,可以组织专家评审。
  对于一个产品开发或工程实施为主的企业或较大型的开发团队,内部的质量管理来说也是如此。因为技术人员可能分散在并行开发实施的多个项目中,我们不希望具体项目的质量仅是因从事该项目当事人水平的局限性而受到制约。为此,建议在项目的立项,制定项目计划的时候,明确要在实施过程的一些关键环节,组织跨项目的交叉评审,特别是对一些重点项目的设计方案评审,应有针对性组织主要的技术骨干,包括聘请外部的专家参与评审,以达到提高质量的作用。我们多年的项目管理实践证明,其效果还是很明显的。
  第二,项目实施的每一个过程产生的差错在后续的阶段都可能会逐步的积累和放大,开发前期的微小疏忽和差错,会对后期设计实施产生严重的影响。而且不同阶段引入变更和纠错所付出的代价是不同的,错误和偏差发现的越早越容易调整与纠正,为此所花费的时间、人力和经费的投入也越少。甚至有些错误如在项目的后期才暴露出来会对项目产生无法弥补的损失。
  当然对于大型项目,组织来自不同企业的整个项目团队集中进行正规的评审会议方式是需要一定的成本与时间代价的。从实效性角度考虑,参与一次评审会的关键人员不要超过8名。项目规模如果很大,应根据阶段和被评审内容的不同采用不同的范围和方式组织技术评审。技术评审也可通过电子邮件、文件汇签,甚至是网络聊天或私下进行专题讨论等多种形式进行非正式的评审。两种不同的评审形式各有利弊,在有些情况下可能非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用不同方式。
  例如我们在开发电子政务信息化应用系统的过程中,主要都是针对项目的需求分析、概要设计、测试计划与测试用例等阶段成果,组织参与项目的各企业的骨干人员(包括项目经理、客户方代表、与其相关的子项目经理、技术骨干、项目监理等)举行正式的技术评审会议,而其他环节的技术评审由各承建企业自行组织或采用非正式的评审方式。由于紧紧把住影响项目建设质量的关键点开展工作,尽可能将缺陷发现在下一个实施环节之前,取得了明显的效果。
  为了提高阶段评审会的效率和实际效果,我们通过实践总结出以下一些经验:
  一、充分做好评审前的准备
  评审质量的好坏很大程度上取决于在评审会议前的准备活动。
  1. 要检查参与评审的内容是否真正完成,是否达到评审的条件。在评审的对象中如果存在大量的低级错误,文档中存在许多方向性的偏差,或缺少大量的关键性内容,可能导致评审无法进行下去,不得不等待下次补充、修正后再举行复审。所以应事先明确要求按照规范文档模版编写技术文档。在评审过程中其中很重要的内容之一也是审查技术文档的内容是否符合文档模版的要求,是否有遗漏项。另外也需要根据评审内容事先准备出一些背景资料和参考素材。
  2. 精心挑选评审人员。根据评审内容及评审目的的不同来确定关键人员的范围,除了客户方的管理人员、用户方的业务人员、IT主管、承建方的分析设计人员、质量保证人员、实施人员、项目经理之外,需求分析评审时应考虑请关键用户代表参与,设计评审时也可邀请一些第三方的行业专家参加。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,不同的观点可能形成互补的关系。为了保证评审的质量和效率,需要精心挑选评审员。首先尽可能邀请到所有不同类型的关键人员参加,否则很可能会漏掉了很重要的需求或出现技术偏差。在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者终不切实际的修改了系统的范围。
  3. 一般欲评审的技术文档内容都会比较多,如果相关文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出充分的时间让参与评审的人员在会前有时间仔细阅读和理解,会出现评审会上花了大量的时间念文档,还使很多参会者不知所云的现象,无法达到评审的目的。所以好在评审会召开前三天前,将技术文档发给所有的评审者。如果要求大家先在会议之前认真阅读,并进行预审,则评审会的效果会更好
  4. 评审检查单是非常好的评审工具,在评审举行之前,应根据其内容和特点事先准备好评审检查单,发给所有参与评审的人员,帮助评审人员思考,以便全面系统地发现评审对象中存在的问题。评审单的内容会随着项目经验的积累逐渐丰富和优化的。
  5. 由于多数评审员是领域专家而不是进行评审活动的专家,他们可能没有掌握进行评审的方法、技巧、过程等,因此需要会前对评审员进行简单的培训,明确评审会议的人员职责分配,评审的具体步骤,评审通过的条件等等。以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率。并指导评审人员充分利用好评审检查单。