请以“信息系统项目的范围管理和质量管理”为题,分别从以下三个方面进行论述:
- 概要叙述你参加与管理过的信息系统项目(项目的背景、项目规模、发起单位、目的、项目内容、组织结构、项目周期、交付的成果等),以及项目在范围管理方面的情况。
- 结合项目管理实际情况并围绕以下要点论述你对信息系统项目范围管理和质量管理的认识。
- 项目范围管理的基本过程和常用方法。
- 项目范围管理中涉及到的质量管理问题和质量管理中涉及的范围管理问题。
- 范围确认和质量控制的区别与联系。
- 结合项目实际情况说明在该项目中你是如何进行范围管理和质量管理的(可叙述具体做法),并总结你的心得体会。
2017年6月,我作为项目经理参与了xx通信公司知识库项目建设。该项目共投资500万元人民币,建设工期为1年。该公司力图通过知识库项目建设,加强各类知识运营、检索、分析、统计等功能;解决海量知识存储、搜索缓慢、管理困难、知识利用率低下等问题;实现业务和知识的查办融合。该项目于2018年6月通过了业主方的验收,上线运行后,赢得了用户的一致好评。以该项目为例,本文结合作者的实际经验,探讨了信息系统建设中的进度管理,主要从规划进度管理、定义活动、排列活动顺序、估算活动资源、估算活动持续时间、制定进度计划、控制进度这几个方面进行了阐述。最后总结分析进度管理的成功和存在的不足,并针对不足之处,提出了今后的改进思路。
2017年6月,我参与了xx通信公司知识库项目建设,该项目是xx通信公司为实现业务和知识的查办融合而立项,是2017年该公司的重点项目。该项目共投资500万元人民币,建设工期为1年,于2018年6月通过了业主方的验收。该公司旨在建立一套高效实用的知识库系统,全面提升服务质量、降低成本、管理方便、提高知识使用率、实现业务和知识的查办融合。系统采用B/S架构,服务端应用采用J2EE+Oracle模式开发,中间件采用IBM的Webshpere并作集群,操作系统采用Redhat企业版Linux5.4,数据库采用Orcale 11 R2并作RAC,终端应用使用Microsoft的WindowsCE平台,采用C#语言开发,运行于PDA之上。由于本人具有较强的管理和领导能力,因此被有幸任命为该项目的项目经理,负责项目的全面管理,直接向项目总监汇报工作。此项目规模大,建设工期紧,涉及的干系人众多,为了项目的圆满成功,我采用了项目型组织结构,从各职能部门抽调主干成员,组建了项目团队。其中包括需求小组5人,开发小组10人,实施小组5人,测试小组5人,质量小组3人,商务和外协支持5人。
由于本项目的顺利上线涉及到业务的考核,因此在本项目中,范围管理和质量管理尤为重要。范围确认是有关工作结果的可接受问题,质量控制是核实工作结果的正确与否。质量控制一般在范围确认之前进行,也可同时进行,确认范围一般在阶段末尾进行。质量控制属于内部检查,只要由相应的质量部门实施,而确认范围是由外部干系人对项目成果进行检查验收。我作为项目经理,不仅要对其余各管理领域进行认真严谨的管理,还要特别关注范围管理和质量管理,主要从以下几个方面进行了管理。
1、规划范围管理
规划范围管理就是制定一份详细的范围管理计划,书面描述项目范围的定义、确认、控制的过程。项目范围和质量息息相关,一般情况下,在规划范围时很少考虑质量,这种做法是可不取的,要制定可行的质量管理计划并组织实施。因此在制定计划时,要注意质量和范围的平衡点,防止范围不清晰带来的质量问题。在制定计划之前我查阅了公司的组织资产,找到了编制范围管理计划的模板,并结合项目的实际情况,组织项目团队成员和干系人编制了项目范围管理计划,为项目管理工作提供指南和方向。
2、收集需求
收集需求是为完成项目目标,收集、记录和管理干系人需求、需要的过程。项目的范围与需求相关,由于收集需求和分析不充分导致项目范围不断蔓延,影响项目质量管理的进行,甚至会导致质量无法保证,质量保证人员不知如何应对,进而导致信息系统项目的失败。我和项目团队成员根据干系人登记册,利用访谈、观察、问卷调查相结合的方式,开展了第一轮需求调研,考虑到有的成员对质量管理方面的知识了解不多,我为项目组成员提供质量管理要求方面的培训和指导等。接着我组织团队成员、项目干系人、相关专家召开了细化需求的分析会,最终得到了需求文件和需求跟踪矩阵。
3、定义范围
定义范围是制定项目和工作详细描述的过程。在此过程中,一般会忽略让质量保证人员参与,这样是不正确的,需求小组和质量保证人员密切配合,明确产品,服务和成果的边界以及要完成的产品的质量目标。经过我和团队成员的共同努力,组织相关干系人召开了引导式研讨会,最终形成了项目范围说明书,双方签字确认,项目范围说明书包括,产品范围描述,验收标准,可交付物,制约因素和假设条件等。
4、创建WBS
创建工作分解结构是将项目的可交付成果及项目工作分解成较小的,更易于管理的工作组件的过程。在分解时,我也注意以下几点原则:1、一个工作单元只能从属于一个上层单元;2、相同层级的工作单元有相同的性质;3、WBS必须有人负责,有且只有一个负责。我按照8/80原则,将项目的工作单元细化成工作包并制定负责人,同时制作了WBS字典,我将批准的范围说明书,WBS和WBS字典,装订成册,得到了项目的范围基准。为了确保每个活动的质量,我们制定了质量标准和质量规范,安排相关人员进行检查,根据检查的情况并记录,识别与相应软件开发过程的偏差,分析问题原因,发现商可能存在的问题,与当事人协商,争取解决问题。
5、确认范围
确认范围是正式验收项目已完成的可交付成果的过程。有的人会把质量保证放在范围确认之后进行,这样是不对的,质量保证是确保过程质量,旨在建立对未来输出或未完输出将在完工时满足特定的需求和期望的信心,我们明确了质量保证人员在项目中承担的角色,建立了质量保证体系。团队成员倾向于让用户确认以尽快开展后续的工作,但用户则可能认为自己什么也没有看到,怎么会确认呢?针对这种情况,我定期组织客户进行范围确认,主要依据核实的可交付成果、需求文件等,通过现场检查的方法,对范围进行确认,形成了验收的可交付成果。
6、控制范围
控制范围是监督项目和产品范围的状态、管理范围基准变更的过程。造成项目范围变更的主要原因是项目外部环境发生了变化,例如:政府政策的问题;对项目范围管理计划编制的不够周密详细,有一定的错误或遗漏;客户对项目,项目产品或服务的要求发生改变。在控制范围中常常会出现的质量方面的问题有:质量管理进展情况报告做的不详细;测试安排的紧张,以至于测试不充分;质量检查频率的设定有问题。QA发现问题应与当事人协商,如果无法达成一致要向项目经理或更高级别的领导汇报,而不能自作主张。对于一些变更要严格按照变更控制流程进行,控制范围主要考虑工作绩效数据、需求文件、需求跟踪矩阵等,通过偏差分析、识别、判断和控制范围变更,得到了工作绩效信息,并更新了组织过程资产。
当然,在质量管理中也存在范围管理的问题,例如:质量保证人员对范围管理方面的知识了解不足,应进行培训或和范围管理人员多交流,多沟通。测试控制的流程不对,未进行质量控制就进行了范围确认,可能会导致范围蔓延。没有挖掘到全部隐性需求,缺乏精确的范围定义。在控制质量过程中,我们经过检查和统计抽样发现,我们发现有个子功能的范围与范围基准之间存在偏差,利用责任分配矩阵我找到了负责该功能的负责人,该负责人为了尽快完成工作,私自缩小了该功能的范围,我再次强调范围变更要严格走变更控制流程,不能擅自做主。
通过我和团队成员的不懈努力,该项目于2018年6月正式上线并顺利通过了业主方的验收,至今运行状况良好,得到了用户的一致好评。公司的整体运营服务水平、客户满意度以及公司形象得到了提升,为该公司实现业务和知识的查办融合提供了强有力的保障。项目最终能够完成,得益我实施有效的进度管理,采用科学合理的项目进度管理方法、工具和技术,对进度管理起到了事半功倍的效果。我总结了如下几条经验:事先要有明确的计划作为指导;在注意范围管理和质量管理的平衡点;控制好项目需求变更,防止需求蔓延。同时也存在一些不足之处,如沟通管理方面存在沟通不畅的问题;在建设过程中,存在少数项目管理文档不能及时整理和提交。在后续的工作中,我将加强运方面的学习和知识积累,不断提升自身项目管理水平,力争为我国信息化建设做出自己的努力。
版权声明:本文为博主作者:伪菜鸟原创文章,版权归属原作者,如果侵权,请联系我们删除!
原文链接:https://blog.csdn.net/qq_44201969/article/details/123763751