项目管理师论文举例:论项目质量管理
【摘要】
2009年3月,我作为项目经理参加某某公司3G手机应用软件开发平台的研制开发工作。我的主要工作职责是项目管理。该项目的客户是内部客户,主要目的是为公司手机产品的开发提供统一的软件开发平台,以便最大程度的在各个项目之间复用工作成果,从而能够灵活、快速、高质量的完成手机应用软件的定制工作。
项目的成功很大程度上归功于对公司级质量体系的遵守和灵活应用以及对质量管理的重视。作者通过以此项目为背景,论述了如何在公司质量管理体系大环境下,进行项目的质量规划、质量保证和质量控制等项目质量管理工作。最后作者总结了如何通过建立强有力的领导机制,遵循和灵活运用组织级的质量管理体系来提升项目的质量绩效,另外还总结了质量审计在质量管理中的重要作用,另外作者还就项目执行中的教训进行了总结和展望。
【正文】
2009年3月,我作为项目经理参加某某公司3G手机应用软件开发平台的研制开发工作。我的主要工作职责是项目管理。该项目的客户是内部客户,主要目的是为公司手机产品的开发提供统一的软件开发平台,以便最大程度的在各个项目之间复用工作成果,从而能够灵活、快速、高质量的完成手机应用软件的定制工作。该软件平台项目包括三个大的部分:手机端软件开发框架子系统;PC端手机软件辅助开发工具子系统;软件平台版权控制管理子系统;
其中手机端软件开发框架采用M-V-C的设计模型,目的是使手机软件的用户接口(UI)和服务(例如电话、短线、访问电话本,蓝牙等)实现分离。PC端手机软件辅助开发工具,基于.Net平台进行了开发,采用面向对象的技术,主要有手机UI布局可视化设计工具、UML状态机可视化设计工具软件。
考虑的未来我公司可以授权其它公司使用这一套开发平台和工具进行手机应用程序的开发,项目基于J2EE和Structs技术开发了一个软件版权控制系统,用户可以通过Internet访问我公司的版权控制系统,使用我单位签发的数字证书使用该软件平台。
由于该项目是基础平台类项目,公司高层经理十分重视,资源投入方面给予了大力支持。该项目历时12个月,现在已交付使用,大大提高了项目成果的复用率,并使手机项目的开发周期缩短到原来的三分之一。为方便项目的管理,项目成立了两级变更控制委员会(CCB),分别是以作者为领导的第二级CCB和以高层经理为领导的第一级CCB。
下面作者以此软件开发平台项目为背景,论述了如何在公司质量管理体系大环境下,进行项目的质量规划、质量保证和质量控制等项目质量管理工作。
1.
作者所在的公司是一家大型的外包服务型公司,公司已经建立ISO9000质量管理体系,也通过了能力成熟度模型集成(CMMI)三级认证。公司具有较为完备的质量管理体系。公司制订了相关的质量方针和目标,落实了质量责任。按照公司流程,项目管理团队在项目启动后需要对组织的质量管理过程以及相关的项目管理过程进行裁剪。
在作者的领导下,项目管理团队对公司的标准流程进行了裁剪,因为该软件平台项目没有手机硬件设计开发相关的活动、所以首先将硬件设计、开发、生产维护相关的流程裁剪掉了。另外对产品需求说明书的内容进行了修改,由原来要描述整个产品(包括软件和硬件)的系统需求,改为只描述软件系统的需求;另外保留了其他相关的流程和交付物。
由于组织标准流程中没有要求编写《软件系统总体设计说明书》,但是项目组认为该软件平台即涉及三个异构的子系统,各个子系统之间协调配合非常复杂、数据流和信息交互也很复杂,非常有必要通过一份软件系统总体设计来规范和协调各子系统的接口以便指导后续的开发活动。所以项目组决定增加一份新的交付物----《软件系统总体设计说明书》。组织标准流程裁剪完毕后形成的项目质量管理流程报质量保证部门及公司领导批准后,作为项目今后计划、执行和管理控制的行动纲要。
作者和项目管理团队通过定期的项目会议与项目组成员进行了充分的沟通,明确了质量对项目的重要性以及大家如何做才能保证项目的质量,使大家对于如何实现项目的质量目标充满了信心。对于项目组中部分成员认为,“流程是死的、无用的,软件的质量是靠测试保证的”等错误思想,通过多次沟通予以了纠正,使大家就以下内容达成了一致:(1)项目的质量是规划、设计和构建出来的,而不是单靠测试保证的;(2)要十分重视项目的质量成本,越在项目早期发现的错误,纠正的成本越低。(3)项目质量目标的达成需要全体项目成员的参与,而不是个别人的事。
2.
在完成《软件系统需求说明书》及《软件需求详细说明书》后,依据项目启动时公司领导对项目的期望。作者领导和组织项目管理团队开始制定项目的质量管理计划。因为该项目是基础平台类项目,所以项目的质量标准中除了功能性指标外,最重要的就是通用性、可靠性、可维护性与可移植性等指标。另外因为手机硬件的配置普遍都不高,所以对性能的要求也较为苛刻。对于通用性、可维护性、可靠性和可移植性等指标主要是通过吸取公司其他项目的经验教训、采用良好的架构设计的方法来解决。对于性能指标通过优化算法的方式来解决。除了确定项目的质量目标外,还明确了质量责任人,作者作为项目经理对项目质量负有首要的责任;小组组长对相关子系统质量负有首要责任;各开发人员对自己的模块质量负有首要责任;质量保证人员对于项目质量有监督和指导的责任等。质量绩效作为考核团队成员绩效的重要指标。
根据规划,在项目实施期间使用公司规定的PVCS系统对代码进行配置管理,使用MS Sharepoint系统对项目的其他文档类交付物进行配置管理。对于项目交付的文档根据重要程度和预先的规划需要经过评审才允许提交进入配置管理系统。对于项目最重要的交付物----代码的质量,项目组给予了高度重视,项目组除了对重要核心模块进行代码评审以外,还吸取敏捷开发中关于持续集成的思想,强调每次交付的代码都应该经过严格的单元测试和集成测试。并且强调任务“完成”的定义是需求、设计、编码、测试都完成了才算是完成了,纠正了一些开发人员认为只要编码完成了就算完成的错误思想。
通过增量交付的方式,在一些关键点(里程碑)请公司领导进行验收和确认,建立领导对项目的信心,公司领导对项目的质量也给予特别的关注,每次验收后都会对项目组强调质量的重要性。公司的质量控制部门通过系统测试对项目的成果给予了把关。每次里程碑交付时,项目开发组完成集成测试,符合准入条件后,由测试组完成一轮系统测试,在项目最终交付时由测试组完成三轮系统测试,符合要求后方可通过。
项目在实施期间定期或不定期对项目的质量过程执行情况进行审计,由项目组质量保证人员主导对项目执行公司的质量过程情况进行结构性检查。例如质量审计过程中发现部分开发人员在没有完成集成测试报告的情况下就提交了代码,并且相关的小组组长也没有把好关。针对这种现象项目组采取了适当纠正和预防措施来确保质量过程的贯彻执行。
项目组在质量控制过程中除了加强检查以外,还特别注重软件缺陷记录的分析工作。通过缺陷帕累托图发现,GUI子模块和MMS子模块的缺陷占到了总缺陷的50%以上,而且通过对其缺陷趋势的分析发现这两个模块在前三次的交付中的缺陷并没有呈现收敛的趋势。通过分析和总结发现,GUI子模块的问题主要是需求分析时接口需求没有做好导致的;而MMS子模块的问题主要是第三方子模块的缺陷较多导致的。通过重新分析和梳理GUI模块的接口需求和升级MMS第三方的子模块的方式项目很快解决了问题。通过再次分析发现这两个模块的缺陷比例下降了很多,而且缺陷也呈现出收敛的趋势。
3.
在项目交付时,由公司领导和相关部门领导、资深工程师组成的评审委员会,对项目的成果进行了验收。认为项目的主要交付物已达到了公司的要求,而且可以作为公司级的软件开发平台推广应用,并且指定了首个接收使用该平台的项目。另外在评审中发现该软件平台的用户手册不够完善,这将对后续的推广应用造成不利的影响。
项目针对评审中提到的问题就行了补救,完善了相关的文档,评审后提交入项目配置管理系统。项目组还对项目执行过程中的经验教训进行了总结,尤其是项目组的《XX软件系统总体设计说明书》被评为公司最佳实践,并整理成文档模板提交到了公司的财富库中。
历时12个月的项目,最终提前1个月完成了,通过这个项目我深深体会到了项目质量管理的重要性,同时也对项目执行过程中的一些经验和不足进行了反思,现总结如下:
强有力的领导,是保证项目质量的关键。如果领导对项目的质量不表现出特殊的兴趣,那么项目的质量是很难保证的。在这里作者想“领导”不仅仅是指公司高层领导,他们的支持只是项目质量管理的基础,项目经理(或项目管理团队)作为项目的“领导”也同样具有重要的作用,强有力的项目领导才能保证公司的质量方针、项目的质量计划得到执行。
灵活裁剪公司的标准流程。公司级的标准流程是通用的,而项目具有独特性的特点,在裁剪流程时需要根据项目的实际情况裁剪,另外“裁剪”不只意味着减少,它还有“增加”和修改的意思。正式应为“裁剪”使得项目的实践才能不断丰富组织的财富,组织的过程成熟度才能不断的提高和改善。
定期的质量审计有利于项目的持续改进。有时在项目执行一段时间后,项目组成员会陷入“不识庐山真面目、只缘身在此山中”的境况。而质量审计工作恰恰可以跳出谜团,以旁观者清的心态发现项目中的质量问题。
没有真正理解项目的质量除了通过产品的质量来体现以外还有服务的质量。对于软件产品来讲,产品的质量应该至少有两层含义:一层是交付物本身的质量,另外一层就是服务的质量。项目在执行时没有提供较完整的用户手册,差一点影响项目成果的推广使用,这一教训作者记忆深刻。好在项目平时的文档记录保存较为完整,在较短的时间内进行了补救。作者将汲取这一教训,通过不断学习和实践,做好今后的项目管理工作。