1、精品资料1 范围定义1.1 案例场景希赛信息技术有限公司 (CSAI 原本是一家专注于企业信息化的公司，在电子政务如火如茶的时候， 开始进军电子政务行业。 在电子政务的市场中， 接到的第一个项目是开发一套工商审批系统。 由于电子政务保密要求， 该系统涉及到两个互不联通的子网： 政务内网和政务外网。政务内网中储存着全部信息， 其中包括部分机密信息； 政务外网可以对公众开放， 开放的信息必须得到授权。 系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网， 政务外网的信息在经过审批后可以进入政务内网系统。张工是该项目的项目经理， 在捕
2、获到这个需求后认为电子政务建设与企业信息化有很大的不同， 有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。 因此采用了严格瀑布模型， 并专门招聘了熟悉网络互通互联的技术人员设计了解决方案， 在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议， 认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70 的代码重写，而第二版的用户界面仍不能满足最终用户的要求， 最终又重写的部分代码才通过验收。由于系统的反复变更， 项目组成员产生了强烈的挫折感，士气低落，项目工期也超出
3、原计划的 100 。1.2 问题问题 1 ：请大家对张工的行为进行点评。问题 2 ： 从项目范围管理的角度找出该项目实施过程中的主要管理问题。问题 3 ：如何避免类似的问题1.3 参考答案【问题 1 】(1) 张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2) 张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。(3) 张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。(4) 张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(5) 张工没有对
4、设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。【问题 2 】(1) 张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。【问题 3 】有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。 对于本案例， 要结合行业特点进行需求分析，挖掘系统潜在的需求， 同时通过原型等方法来辅助需求的定义， 避免范围定义不清晰的问题。在发生需求变更时需要进行有效的需求控制， 尽量在满足用户需求的前提下缩小需求范围，坚
5、决避免需求的再次变更。2 工作要点2.1 案例场景M 集团是希赛信息技术有限公司 (CSAI )多年的客户， CSAI 已经为其开发了多个信息系统。最近， M 又和 CSAI 签订了新的开发合同，以扩充整个企业的信息化应用范围， 张工担任该项目的项目经理。 张工组织相关人员对该项目的工作进行了分解，并参考了公司同 M 曾经合作的项目， 评估得到项目， 总工作量 60 人月， 计划工期 6 个月。项目刚刚开始不久， 张工的高层经理S 找到张工。 S 表示， 由于公司运作的问题， 需要在 4 个月内完成项目， 考虑到压缩工期的现实， 可以为该项目在增派两名开发人员。 张工认为， 整个项目的工作量是
6、经过仔细分解后评估得到的，评估过程中也参考了历史上与K 企业合作的项目度量数据，该工作量是客观真实的。目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况， 因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完成。高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。六个月以后，项目在没有增加人员的前提下顺利地完成， 虽然比最初计划延长了半个月
7、的工期， 但既达到了公司的要求， 客户对最终交付的系统也非常满意，项目组的成员也没有感受到很大的压力。2.2 问题【问题1 】指出张工是如何保证项目成功的？【问题2】 (15 分)试结合案例指出项目范围管理的工作要点？2.3 参考答案问题 1(1) 张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定了 WBS 。(2) 张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。(3)在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。(4) 张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。(5)张工对项目进行了沟通管理，协调
8、了多个项目干系人之间的矛盾。问题 2项目范围管理的要点：(1)范围管理计划。(2)范围定义。(3) 工作分解。(4)范围确认。(5)范围控制。在本案例中， 张工首先进行了范围定义和工作分解， 得到了清晰的项目范围；在出现新的项目目标后，张工进行了范围控制，重新定义了两个阶段的项目范围； 最后， 张工将重新定义的范围与项目干系人进行了确认。3 范围确认3.1 案例场景希赛信息技术有限公司 (CSAI ) 刚刚和 M 签订了一份新的合同，合同的主要内容是处理公司以前为 M 公司开发的信息系统的升级工作。升级后的系统可以满足M 公司新的业务流程和范围。由于是一个现有系统的升级， 项目经理张工特意请来
9、了原系统的需求调研人员李工担任该项目的需求调研负责人。 在李工的帮助下， 很快地完成了需求开发的工作并进入设计与编码。由于 M 公司的业务非常繁忙， M 公司的业务代表没有足够的时间投入到项目中， 确认需求的工作一拖再拖。张工认为， 双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义， 项目已经进入编码期， 李工的离职虽然会对项目造成一定的影响， 但影响较小， 因此很快办理好了李工的离职手续。在系统交付的时候， M公司
10、的业务代表认为已经提出的需求很多没有实现， 实现的需求也有很多不能满足业务的要求， 必须全部实现这些需求后才能验收。 此时李工已经不在项目组， 没有人能够清晰地解释需求说明书。 最终系统需求发生重大变更， 项目延期超过50%,M 的业务代表也因为系统的延期表示了强烈的不满。3.2 问题【问题 1 】对张工在项目管理工作中的行为进行点评。【问题2 】请从项目范围管理的角度找出该项目实施过程中的问题。【问题3 】 （8 分）谈谈应如何避免类似的问题。3.3 参考答案【问题 1 】(1) 张工为了更明确地把握系统需求，聘请了原系统的需求调研 人员李工，提高了需求定义的效率和质量。(2) 张工没有对李
11、工开发的系统需求进行评审和复查，从而使得 需求的缺陷没有被及时发现。(3) 张工没有要求用户对已经定义的需求进行确认，从而导致需 求理解的偏差。(4) 张工对需求的不能进行缺乏有效控制，最终造成项目延期 50%.【问题 2 】该项目实施过程中的主要问题包括：(1)在范围定义中，张工没有对李工定义的需求进行评审，造成 需求中的质量缺陷没有被及时发现。(2)在范围确认中，张工没有主动地要求用户对需求进行确认。(3)在范围控制中，张工无法进行有效的范围控制，最终造成了 重大的需求变更。3】对于本案例，项目经理需要对需求定义的结果进行质量控制， 采 取评审等方式减少需求中的问题。对已经定义的需求需要与用户进行 确认，保证双方理解的一致。在发生需求变更时，也应该采取灵活的 手段，在满足用户需求的前提下，尽量减少需求变更的范围。可修改
