项目范围管理案例.pdf

. . 第 2 章项目范围管理案例 项目的范围管理影响到信息系统项目的成功。在实践中，需求蔓延”是信息系统失败 最常见的 原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论 是客户 的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使得 信息系 统项目无论在时间、资源和质量上都受到严重影响。 21 案例一：范围定义 阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题 1 至问题 3。 2.1.1 案例场景 希赛信息技术有限公司(CSAI 原本是一家专注于企业信息化的公司，在电子政务如火 如荼的时候， 开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套 工商审批系统。 由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政 务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放， 开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信 息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在 经过审批后可以进入政务内网系统。 张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大 的不同， 有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采 用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严 格评审后实施。 在项目交付时， 虽然系统完全满足了保密性的要求，但用户对系统用户界面 提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由 于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70的代码重写，而第二版的用 户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变 更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100。 【问题 1】请不超过300 字，对张工的行为进行点评？ 【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过 200 字回答。 【问题 3】 请结合你本人实际项目经验，指出应如何避免类似问题？不超过200 字回答。 2.1.2 案例分析 这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中 的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范 围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。 张工对项目范围有一定的把握。在范围定义中， 张工发现了不同行业间具有不同的特点， 电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政 务外网是该行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个 . . 需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在 系统交付时完全满足了用户对保密性的要求。在这一点上， 张工是成功的。 如果在范围定义 时忽略了行业标准，项目肯定会招致更大的失败。 但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我 们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的 范围所约束。 对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗 口而言， 并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体 民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷 性也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求张工没有充分考虑， 从而导致一而再，再而三的变更。 对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。 张工仅仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。 对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系 统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责 人传递到项目组。 但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出 了更高的要求。 除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当 系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定 义系统的界面风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是 完全可以避免的。 在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点 都是项目范围的风险。面对这些风险， 即使再细致的调研也无法完全避免，也不能完整定义 系统的范围。 因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中， 张工也没有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。 对于这个案例， 缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑， 这必然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险， 随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。 综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风 险管理和质量管理上也都存在缺陷。 有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰 的定义， 并最终满足了用户的要求；但不充分的范围定义和范围确认招致了项目的失败，而 采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%. 因此第一题答案的要点就很明确了： (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要 求。 (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成 系统交付的重大变更。 (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。 (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适 应性较差的瀑布模型组织开发。 (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的 代价。 对于第二题， 是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域 的问题。在范围管理中主要包括如下内容： . . (1)范围管理计划。 (2)范围定义。 (3)工作分解。 (4)范围确认。 (5)范围控制。 在本案例中，没有专门设计到范围管理计划和工作分解的内容。从表面上看，范围定义 存在明显的缺陷。但案例中提到系统又发生了第二次变更，由此可见， 张工在范围确认和范 围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可 以避免第二次的变更。 因此，第二题的答案要点如下： (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。 (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。 (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。 在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。 项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任 何疏忽都可能招致严重的后果，造成项目的失败。 而软件项目的复杂性又决定了项目中的工 作环环相扣， 问题也总是相互关联的。在发现问题后， 也需要采取多种手段才能彻底解决问 题。这对信息系统的项目经理来说是重大的挑战。 2.1.3 参考答案 【问题 1】 (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要 求。 (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成 系统交付时的重大变更。 (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。 (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适 应性较差的瀑布模型组织开发。 (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的 代价。 【问题 2】 (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。 (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。 (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。 【问题 3】 有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要 的。对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方 法来辅助需求的定义，避免范围定义不清晰的问题。 在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范 围，坚决避免需求的再次变更。 22 案例二：工作要点 阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1至问 题 2。 . . 2.2.1 案例场景 M 集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI 已经为其开发了多个信息 系统。最近， M 又和CSAI 签订了新的开发合同，以扩充整个企业的信息化应用范围，张 工担任该项目的项目经理。张工组织相关人员对该项目的工作进行了分解，并参考了公司同 M 曾经合作的项目，评估得到项目，总工作量60 人月，计划工期6 个月。项目刚刚开始 不久，张工的高层经理S 找到张工。 S 表示，由于公司运作的问题，需要在4 个月内完成项目，考虑到压缩工期的现实， 可以为该项目在增派两名开发人员。张工认为， 整个项目的工作量是经过仔细分解后评估得 到的，评估过程中也参考了历史上与K 企业合作的项目度量数据，该工作量是客观真实的。 目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也 很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐4 个月完成的目标， 肯定会降低项目的质量，造成用户不满意。因此，张工提出将整个项目分为两部分实现，第 一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准， 这样不增派开发人员也可以完成。高层经理认为该方案可以满足公司的运作要求，用户也同 意按照这种方案进行实施。 六个月以后， 项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月 的工期， 但既达到了公司的要求，客户对最终交付的系统也非常满意，项目组的成员也没有 感受到很大的压力。 【问题 1】请不超过500 字，指出张工是如何保证项目成功的？ 【问题 2】请不超过500 字，试结合案例指出项目范围管理的工作要点？ 2.2.2 案例分析 这是一个成功的项目管理案例，项目经理张工有效的运用范围管理，在不同的项目干系 人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。 作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于 进行信息系统开发项目而言，范围管理是其中最重要的技能之一。 软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整 和控制的。 软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对 于相同的用户价值可以定义出不同的系统需求。举一个简单的例子，用户的需求是 “解决口 渴的问题”，那么最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水， 更复杂的是递上一杯经过多层过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一 杯龙井茶。 用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目 失败。 聪明的软件项目经理总是从范围管理开始，先界定系统的边界，然后再在明确的范围 内进行时间、成本、风险等的管理。 在项目中，时间、成本和范围构成了一个稳固的三角形，如图2-1 所示。 . . 对于该三角形来说，任何一边都不可能孤立地改变。换句话说，我们不可能固定其中两 边而试图缩短第三边。其实这也是很容易理解的问题，如果项目需要做的东西已经确定(项 目范围固定 )，项目的人员也已经确定(项目成本固定)，那么项目需要的时间就也是固定的。 同理， 已经固定的项目投入和项目时间也只能做出固定的工作。对于这个三角形而言，非但 不可能孤立地改变某一边的长短，就是三边的变化比例不一致也不可能。不成比例的变化与 孤立的改变某一边是一样的，都将破坏三角形的结构，违反项目的客观规律，最终招致失败。 因此有效的范围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目 目标。 在本案例中，高层经理S 就提出了试图打破这个三角形的要求。他要求，项目组可以 增加部分资源， 但要提前两个月完成。初一看， 并没有在不增加投入的情况下要求项目提前 完成， 似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想， 增加的资 源和提前的时间还是不成比例。项目经理张工深知此中奥妙，因此在听到高层经理的要求后， 马上意识到这是一个不可能完成的任务。 那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打 破了项目规律， 那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常 运作。 于是，张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的 范围都可以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规 律，最终取得了成功。 在案例中，还有一些细节需要考生注意。张工最初估算整个项目需要花费60 人月的总 工作量， 但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因 素， 超出原计划半个月是正常的。计划在6 个月内完成。 在把项目拆分后， 实际是用了6 个 半月的时间， 也就是花费了65 人月完成了项目。对于上面介绍的时间、成本和范围的关系 而言， 仅是在理想情况下成立，即项目成员始终能以固定的成本完成固定的工作。而在实际 情况下，项目的工期、复杂度等因素都会对项目造成影响。在案例中，虽然看似两部分工作 的总和等于没有拆分前的项目，但这仅对于最终目标而言，拆分后的项目增加了若干中间成 果，项目的范围实际上还是扩大了。 因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求， 而控制的方法就是减少需求的内容。这种理解是完全错误的。 范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。 例如，本案例中，范围控制就是针对高层经理的要求进行的。再比如，在设计中，我们既可 以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以 对系统进行充分良好的设计，甚至可能是过度设计。采取哪一种设计策略也是软件项目范围 管理的一部分。 项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约 束，制定明确的项目范围，保证项目的成功。根据笔者的经验，即时需求已经确定，通过有 效的范围管理仍能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过范围管理来 降低项目成本，缩短项目工期。 上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他 的范围管理工作。 首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了WBS 并对项目进 行了估算和计划。在S 提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩 小了第一步需要完成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定 义，制定了验收标准。最后，张工对重新定义的范围进行了确认，与客户和高层经理达成一 致。 对于项目而言，仅仅管理范围仍不能保证项目的成功。在这个案例中，张工也运用了其 . . 他的管理手段。 其中包括，张工对项目进行了估算，这属于项目时间管理的范畴；张工协调 了多个项目干系人之间的矛盾，这属于沟通管理的范畴。 有了上面的分析，这道考题的答案也就很清晰了。 2.2.3 参考答案 【问题 1】 (1)张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定 了 WBS。 (2)张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。 (3)在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。 (4)张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。 (5)张工对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。 【问题 2】 项目范围管理的要点： (1)范围管理计划。 (2)范围定义。 (3)工作分解。 (4)范围确认。 (5)范围控制。 在本案例中，张工首先进行了范围定义和工作分解，得到了清晰的项目范围；在出现新 的项目目标后， 张工进行了范围控制，重新定义了两个阶段的项目范围；最后，张工将重新 定义的范围与项目干系人进行了确认。 2.3 案例三：范围确认 阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1 至问题 3. 2.3.1 案例场景 希赛信息技术有限公司(CSAI ) 刚刚和M 签订了一份新的合同，合同的主要内容是处理 公司以前为M 公司开发的信息系统的升级工作。升级后的系统可以满足M 公司新的业务 流程和范围。 由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员 李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入 设计与编码。由于M 公司的业务非常繁忙，M 公司的业务代表没有足够的时间投入到项 目中， 确认需求的工作一拖再拖。张工认为，双方已经建立了密切的合作关系，李工也参加 了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张工并没有催 促业务代表在需求说明书中签字。 进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定 义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很 快办理好了李工的离职手续。 在系统交付的时候，M 公司的业务代表认为已经提出的需求很多没有实现，实现的需 求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项 目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%, M 的业务代表也因为系统的延期表示了强烈的不满。 . . 【问题 1】请以400 字对张工在项目管理工作中的行为进行点评。 【问题 2】请从项目范围管理的角度找出该项目实施过程中的问题，以500 字内回答。 【问题 3】请结合你本人项目经验，谈谈应如何避免类似的问题，以500 字内回答。 2.3.2 案例分析 这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开 发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建 设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项 目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。 在案例中，张工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有 的系统， 然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新 系统的需求问题。 这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，张工 是成功的， 找到了合适的资源进行需求的开发与定义。李工也没有让张工失望，很快就整理 出了新系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽 在张工的掌握之中。这是一个阳光灿烂的开端，如果一切顺利的话，项目的成功也就是早晚 的事情。就如同大多数经典的悲剧故事一样，故事的序幕是美好的。 晴朗的天空飘来一块乌云，李工要移民加拿大。不过仅仅是一片乌云而已，并没有下起 雨来。 开发出的需求都已经过设计，一些编码工作也已经开始，李工的工作已近圆满完成，毕 竟，一些细枝末节的问题还可以同客户直接沟通。 经过项目组努力，项目终于完成开发，准备发布了。 这时， 乌云开始下雨， 问题爆发了。 客户不认可项目组的工作，认为很多需求没有实现，实现的功能也与需求不符。 谁是这个项目组的罪人呢？李工？还是张工？换一个思路考虑一下，如果李工没有离开 项目组， 结果又会是什么样呢？客户会因为李工还在项目组就认可这个系统吗？很显然，不 会。至多可以在双发的协商下少一些变更，项目延期不是50%,而是 30而已。如果非要区 分 50和 30的区别，也不过是五十步笑百步而已。 从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管 理项目的范围。 在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺 一不可。 范围定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确 认则是基线化已定义的范围，是范围控制的依据。范围控制的作用在于减少变更，保持项目 范围的稳定性。 在案例中，由于张工没有进行范围确认，最后的范围控制也就变成了无本之木，控制过 程肯定变成了讨价还价，失去本身的意义。 在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探 索出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定 义出完美无误的需求，需求中的缺陷必然存在，无法完全避免。 因此需求确认或者说是范围 确认就显得更为重要。 有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软 件行业的情况， 这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要 进行范围确认， 而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代 表对需求进行评审、详细记录最原始的调研材料，让客户确认调研报告、采用迭代开发逐步 确认系统需求， 都是可以采用的方法。这些方法虽然没有直接确认需求分析报告，但至少可 以让现有需求在项目组和客户之间达成一致，提供范围控制的基准，一样可以达到范围确认 的目的。 . . 再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方 已经有良好的合作，在不紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了 开发。 然而最终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期 造成的成本增加的责任。 有了上面的分析，后面问题的答案就不难得出。首先看第一个问题，对张工的行为进行 点评。 前面已经提到， 张工注意到了需求的问题，专门找到了原系统需求负责人李工进行需 求开发， 这是对项目有利的一面。但由于缺少需求评审和确认的过程，造成需求中的缺陷没 有被及时发现， 系统需求没有与客户确认，造成缺少需求控制的基准，最终导致需求的重大 变更。 对于第二题，联系范围管理的知识，我们不难发现张工在范围确认和范围控制中都有重 大的缺陷，在范围定义中也由于缺乏评审造成需求的质量问题。 在完成第二题后，第三题就水到渠成了，第三题的要点见参考答案，此处不再赘述。 2.3.3 参考答案 【问题 1】 (1)张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定 义的效率和质量。 (2)张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发 现。 (3)张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差。 (4)张工对需求的不能进行缺乏有效控制，最终造成项目延期50%. 【问题 2】 该项目实施过程中的主要问题包括： (1)在范围定义中， 张工没有对李工定义的需求进行评审，造成需求中的质量缺陷没有被 及时发现。 (2)在范围确认中，张工没有主动地要求用户对需求进行确认。 (3)在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需求变更。 【问题 3】 对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求 中的问题。 对已经定义的需求需要与用户进行确认，保证双方理解的一致。在发生需求变更 时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。 . .