肖岚
(国家卫星气象中心 北京市 100081)
随着现代社会专业分工的细化,将项目整体或部分进行外包的形式日渐普遍。软件项目的外包是由交办方提出任务需求, 将本单位需要开发的软件项目外包给专业从事软件研发的企业或组织, 从而达到合理利用资源,提高工作效率的目的。
采用外包形式的软件开发项目,作为任务交办方,面临如何对外包开发项目进行检查控制,确保项目承制方如期交付符合实际业务需求的软件产品。交办方如果对外包软件项目疏于控制,可能引发项目出现一些质量问题, 如进度的延期、运用技术过时等,这些质量问题会给交办方造成不良后果或带来很大的损失。因此,作为项目交办方,制定有效的质量控制方法和措施是项目成功的重要因素。
质量管理可定义为:“确定质量方针、目标和职责,并通过质量体系中的质量策划、控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。”
质量管理一般具有三项任务:
(1)制定质量方针目标及其实施规划;
(2)实施质量保证;质量保证是为使人们确信企业能满足质量要求而开展的,并按需要进行证实的,有计划和有系统的活动;
(3)实施质量控制;质量控制是对质量形成的过程进行监视、检测,并排除过程中影响质量的因素。
由质量管理定义,我们可以看出,质量控制是质量管理的一部分。
有着“统计质量控制之父”之称的沃尔特·休哈特(Walter A.Shewhart)首先构想出PDS(Plan-Do-See)的管理模型。到了20 世纪50 年代,美国著名质量管理专家由爱德华兹·戴明(W.Edwards,Deming)将PDS 模型进一步完善,提出了PDCA(Plan-Do-Check-Act)循环质量持续改进模型。因此,PDCA 循环有时也被为戴明环(Deming Wheel)或持续改进螺旋(Continuous Improvement Spiral)。
PDCA 循环是全面质量管理的思想基础和方法依据,它分为四个阶段,包括:
(1)P:Plan 计划—计划目标,确定方针和目标,确定活动计划;
(2)D:Do 执行—按照所制定的计划组织实施;
(3)C:Check 检查--将实施效果与计划目标对比,检查执行的情况,判断是否达到了预期效果,再进一步查找问题;
(4)A:Act 处置--对检查结果进行总结和处理:成功的经验加以肯定,纳入标准,遗留问题转入下一个PDCA 循环。
PDCA 循环具有阶梯式上升的特点,四个阶段的活动不是运行一次就结束,而是周而复始,每循环一次,就取得一部分工作进展;到了下一次循环,又有了新的目标和内容,上了一个阶梯,即新的水平比原有水平提高了。
图1:PDCA 循环示意图
PDCA 循环是质量管理体系的一种普遍方法,可以说在各行各业中,都得到了广泛的实践应用。
我们以某信息处理平台的外包建设过程中出现的问题为例, 分析外包项目质量控制中可能出现的两类问题。
某信息处理平台的任务需求是对数据完成采集后,进行数据处理,最终生成数据产品。在需求与概要阶段,任务交办方与承制方对任务需求有过沟通,承制方也提交了概要设计文档。此后双方未进行进一步沟通,至开发收尾阶段,承制方联络交办方,交付测试版本,交办方才发现承制方对信息流程的规划与实际信息流程有差距,概要设计文档中的设计只提供了框架设计,双方按照各自的理解来解读。 由于对需求理解的偏差,带来了设计上的偏差。
为保证开发任务按照计划进行,在项目之初都会制定软件开发计划,但实际往往会出现进度比预期滞后的情况,例如由于前述需求理解的偏差导致的返工,将不可避免的会对进度产生影响;另外承制方开发人员的流动性也带来了进度的不可控因素,这在某信息处理平台的开发阶段后期尤为明显。
对于外包项目的按需交付,承制方有着不可推卸的责任与义务,交办方对于外包项目的质量控制也必须尽责,实施有效的质量控制手段,对外包项目的质量进行检查、监视与控制。
为避免以往外包项目出现的问题重现,对外包软件开发项目进行有效的质量控制至关重要。
以某业务支撑平台开发项目为例,作为交办方,对业务支撑平台进行了业务层面的设计,包括人员权限管理、故障处理、资源状态监视显示、业务操作记录、关键业务数据的监视显示等功能。 研制任务书由交办方进行编制,开发实现则采用了外包的形式,由专业软件开发公司承担业务支撑平台的软件开发任务。
作为交办方,有责任对承制方的软件开发过程进行监督和质量控制。质量控制依靠事后检查是不足够的,更重要的是事先预防和事中监控。因此,我们引入基于PDCA 循环的质量控制方法。
图2:第N 周工作计划节选示例图
此项目的持续改进的PDCA 循环质量控制以周为单位进行。包括:制定每周工作计划(P)->按照计划执行本周工作任务(D)->检查本周计划完成情况(C)->本周工作完成情况的处置(A)。
4.2.1 P: 计划
首先明确目标: 对承制方的软件开发过程进行质量控制,确保承制方按照进度要求,开发出符合任务书要求的业务支撑平台。
根据以往的教训,外包开发项目进度容易存在前松后紧的情况,即前期进度未控制好,后期局面被动。原因可能有多方面,如前期沟通不足导致理解有偏差,承制方项目组自身管理能力不足等原因,深层原因则是交办方对项目的质量控制力度不够。为避免这一问题的再度发生,我们以周为单位开展质量控制活动。
在需求分析阶段, 承制方项目组编写了软件需求规格说明书与软件开发计划。为了达到质量控制目标,我们要求项目组对软件开发计划进一步细化。以功能完成为出发点, 制定细化到模块级的开发计划:
(1)以进度控制和技术实现为出发点, 在模块开发计划的基础上,制定细化到每周的工作计划。
(2)每周工作计划还应包括对上一个PDCA 循环转入的问题进行原因分析后,所制定的执行措施计划。
4.2.2 D: 执行
(1)承制方项目组按照事先制定的周工作计划,执行本周开发任务。
(2)交办方按计划与承制方项目组进行技术讨论,以及提供必要的资源。
4.2.3 C: 检查
交办方质量控制人员根据计划,对承制方项目组上周工作任务完成情况进行检查,并记录检查情况,识别出全部完成、部分完成、和未按计划启动的模块;对部分完成的模块估算完成进度百分比。
承制方项目组的项目经理、项目质量保证工程师对每周的检查予以配合,展示完成情况,如有未按计划完成的本周工作任务,必须说明原因。交办方质量控制人员记录未完成原因,并生成每周检查报告。
4.2.4 A: 处置
每周开项目周例会,参会人员包括但不限于:
交办方:业务领导、业务技术骨干、质量控制负责人
承制方:项目经理、项目主要开发人员、项目质量保证工程师
周例会一般分三部分:
(1)由交办方质量控制人员做上周开发任务完成情况的检查报告。
(2)承制方项目经理对上周开发工作情况进行说明。
(3)交办方对上周工作进行总结分析,对已实现并达到要求的功能模块予以肯定并放行;找出存在的问题,对问题的解决给出指导性意见。将问题解决转到下一个PDCA 循环,并添加到下周工作计划中。
我们以周为单位,采用PDCA 方法对承制方的项目开发进行质量控制,在此过程中所发现的问题,同样采用PDCA 的方法对问题予以解决。
4.3.1 技术问题解决实例
(1)P 计划: 关于APP 开发有几种技术框架,native app(原生)、web app、hybrid app(混合),承制方应采用何种APP 技术框架,对应使用哪些技术不够明确。为了解决这一问题,做出计划:1 双方进行技术讨论2 承制方项目组提交符合要求的APP 框架设计方案。
(2)D 执行:双方进行了专题技术讨论,承制方项目组对讨论内容整理分析后,完成APP 框架方案设计。
APP技术框架采用web app,依托于浏览器的形式,跨平台使用,无需分别开发Android/ios/pc 端多种版本,这样开发成本低,开发速度快。采用前后端分离架构: 后端采用node,前端采用PWA 技术。
(3)C 检查:对承制方的方案从技术层面进行检查评审。
(4)A 处置:APP 框架方案评审通过,在概要设计中将此APP 框架设计方案包括进去。
4.3.2 进度问题解决实例
(1)P 计划:在项目进展过程中, 发现个别模块的开发进度有停滞现象,与项目经理沟通后,分析原因,负责该模块的开发人员被临时抽调到其它项目组了,项目经理无法保证该开发人员何时回归本项目组。针对这一问题,立即制定与承制方高层进行沟通的计划,目标是确保进度不受影响。
(2)D 执行:与承制方主管该项目的高层进行沟通,督促承制方高层进行干预,确保人员到位,项目进度不得延误。
(3)C 检查:经交办方质量控制人员检查,人员已经到位,该模块开发工作恢复。
(4)A 处置:该进度问题得以解决,总结经验:对影响进度的原因(如:技术原因、人为原因、计划未估计到的原因等)进行分析,及时采取措施消除影响进度的因素。当开发进度出现延迟或停滞,项目经理解决情况不理想的情况下,及时向承制方高层反应,保障开发进度。
在GB/T19001-2016 质量管理体系要求中,“领导作用”是质量管理七大原则之一。在PDCA 循环中,领导作用处于核心位置。
在外包业务软件开发项目中,领导的核心作用对项目的质量控制起着关键作用。领导对项目质量的重视,推动全员积极参与业务支撑平台开发项目的质量控制活动,确保资源可获得,PDCA 各个阶段工作顺利开展,最终项目开发取得预期的效果。
我们采用基于PDCA 的质量控制方法,开展了对外包业务支撑平台软件开发项目的质量控制工作。每周一个PDCA 循环:制定计划,实施计划,检查执行情况,对完成情况进行总结处置; 同时对特定问题的解决也是采用PDCA 方法。正是基于有效的PDCA 质量控制方法,解决了软件开发过程中出现的问题,承制方按照进度完成了开发任务,业务平台如期上线使用。事实证明,基于PDCA的质量控制方法在外包开发项目中适用,实现了质量控制的预期目标。