阅读以下关于项目范围管理的说明,根据要求回答下面问题。 [说明] RT公司是一家致力于为电子政务市场提供应用系统开发的软件公司,最近接到开发一套向公众开放的政务信息发布与查询系统的项目。由于电子政务项目有一定的保密性要求,因此该系统涉及两个相互

admin2010-01-15  34

问题 阅读以下关于项目范围管理的说明,根据要求回答下面问题。
   [说明]
   RT公司是一家致力于为电子政务市场提供应用系统开发的软件公司,最近接到开发一套向公众开放的政务信息发布与查询系统的项目。由于电子政务项目有一定的保密性要求,因此该系统涉及两个相互独立的子网,即政务内网和政务外网。政务内网中存储着全部信息,包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须一致、可靠,政务内网的信息可以发布到政务外网,政务外网的信息经过审批后可以进入系统。
   该项目的项目经理老陈在了解到系统要求之后,认为保密性是系统的难点,需要进行技术攻关。为了顺利地完成该项目,老陈找到熟悉网络互联互通的技术人员设计了解决方案,在经过严格评审后实施该方案。在系统完成开发进入试运行前,项目发包方认为系统虽然完全满足了保密性的要求,但其使用界面操作复杂,应该简化操作,因此必须在系统交付前增加操作向导的功能。除此以外,试运行需要的服务器等设备已经采购完成,但没有经过调试,发包方要求老陈委派人员在部署试运行环境时,同时对采购的设备进行调试并安装相应的系统软件。在合同条款中仅有一条“乙方负责将系统部署到试运行及正式运行环境”,并没有指出环境的状态,老陈只好向公司求助,找到了可以完成服务器系统软件安装和调试的资源,完成了这部分的工作。
   对于增加“操作向导”的问题,老陈安排程序员小许向项目发包方口头了解“操作向导”的需求后,直接进行开发。但在操作向导功能交付后,项目发包方根据公众用户反馈的结果认为操作向导仍没有满足需求,最终又重写了大部分代码才通过验收。由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,成本和工期都超出了原计划的35%以上。

选项

答案①没有清晰地了解到产品的范围,导致项目后期需求的蔓延。 ②没有澄清模糊的项目范围,在安装服务器的问题上产生异议,最终增加了未计划到的工作。 ③没有进行变更控制,以致变更的结果不理想,因而反复变更

解析 项目范围指为了完成具有所规定特征和功能的产品必须完成的工作。项目范围是否完成由项目管理计划来衡量。项目范围管理包括范围计划制订、范围定义、创建工作分解结构、范围确认和范围变更控制等过程。其中,范围定义阶段给出了关于项目和产品的详细描述,作为将来项目决策的基础。范围变更控制阶段完成监控项目和产品的范围状态,管理范围变更。
   在本案例中,项目经理老陈在项目管理中的工作既有闪光点,也有失败的地方。项目管理中的任何差错都会影响项目的结果,而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
   老陈对项目范围有一定的把握。在范围定义中,老陈捕获到电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求,政务内网与政务外网是该行业一致的标准,这同企业信息化是完全不同的。老陈捕获了该需求,并对这个需求进行了清晰的定义,对设计和实现都进行了严格的控制,因此在系统交付时完全满足了用户对保密性的要求。在这一方面老陈是成功的。如果在范围定义时忽略了行业标准,项目肯定会导致更大的失败。
   用户界面的风格和操作的便捷性也属于系统范围的一部分。同系统运行环境一样,通常称此类需求为隐性需求。这类需求不一定是由用户直接提出的,即使提出也是相当模糊的。对于该系统来说,系统是面向公众开放的,系统的用户来自各行各业,大多不是专业的IT人员,这些人计算机操作能力较低且没有经过正式的系统使用培训。因此,一个界面友好、操作简单的系统是非常必要的。很明显,对于这些系统的隐性需求老陈没有充分考虑,从而导致一而再、再而三地变更。
   对于面向公众开放的系统,范围定义更加困难。这些系统的最终用户几乎不会参与到项目中来帮助项目组定义系统范围,他们的需求都是间接的、通过发包方传递到项目组的。项目组最终得到的信息往往是混合了用户需求和传递者个人意愿的结果。此时,不但要注意仔细分析得到的信息,去伪存真,更重要的是要把分析的结果在各项目利害关系人中达成一致,让各方面对系统范围有着同样的理解和认识,否则,会出现仅能满足部分人需求的情况。在本案例中,虽然开始阶段公众用户没有机会提出要求,但最终用户的意见对项目的结果还是会有影响的,这就对范围管理增加了更大的难度。
   在本案例中,还有一处范围模糊的地方,即项目组是否需要负责服务器系统软件的安装和调试。服务器软件的安装和调试不是一件简单的事情,很多服务器需要专门人员才可以进行维护。这部分内容在合同中并没有明确地写明,在定义项目范围时,应当明确写明这部分工作是否属于项目范围,究竟应该由谁来完成。在没有明确之前,将这项工作作为项目范围和排除在范围之外都是不正确的做法。类似于服务器安装与调试的工作经常会模糊不清,发包方一般会认为项目组应该完成全面部署系统的工作;而开发者往往倾向于认为会有一个完好的环境可供系统部署使用。很多软件项目在后期都会出现这样的纠纷,解决的办法也很简单,只要在项目前期把这个问题谈清楚、明确责任者就可以了。
   在本案例中,当项目发包方提出异议,要求增加操作向导的功能时,老陈直接委派了一名程序员小许去了解需求并进行开发。在这个过程中,没有进行变更控制的工作,没有对范围变更请求进行评估与控制,这种做法也是不可取的。缺少正式的变更控制将造成项目时间和成本的超出、变更后的范围模糊等问题。本案例中,程序员小许直接了解到的需求很难得到正式的确认,这也就是再次变更的原因之一。
   综上所述,项目经理老陈在这个项目中,在范围定义和范围变更上都犯了一些错误,这些错误最终造成了项目时间和成本的超出。这些错误表现在以下3个方面。
   ①没有清晰地了解到产品的范围,即没有挖掘到系统的全部隐性需求,缺乏精确的范围定义,导致项目后期需求的蔓延。
   ②没有澄清模糊的项目范围,在安装服务器的问题上产生异议,最终增加了未计划到的工作。
   ③没有进行变更控制,以致变更的结果不理想,因而反复变更。
转载请注明原文地址:https://jikaoti.com/ti/EUJ7FFFM
0

最新回复(0)