第3章 项目范围管理 视频讲解 很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后，往往不知道项目什么时候才能真正结束，到项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束，谁的心里也没有底。这对于企业的高层来说，是最不希望看到的，然而这种情况的出现并不罕见。造成这样的结果就是由于没有管理和控制好项目的范围。 一般来说，在启动软件项目初期，客户就应该提出一个相对明确的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理画出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能出现模糊、扩大的现象，这些模糊和扩大的部分会给项目带来风险。 针对上述问题，本章将介绍项目范围管理规划、范围定义、范围分解、范围核实和范围控制等内容。 3.1范围管理规划 范围管理规划是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。本过程的主要作用是在整个项目中对如何管理范围提供指南和方向。经过范围管理规划，将分别得到一份范围管理计划和需求管理计划。 3.1.1基本概念 项目范围(Project Scope)是指产生项目产品所包括的所有工作及产生这些产品所用的过程。 这个概念有两种含义，一种是产品范围，另一种是项目工作范围。其中，产品范围(Product Scope)是指客户对产品或服务所期望的特征与功能总和，以产品需求作为衡量标准； 项目工作范围(Work Scope)是指为提供客户所期望特征与功能的产品或服务而必须要完成的工作总和，以项目管理计划(实际为其中的范围管理计划)是否完成作为衡量标准。 项目范围管理是指对项目包括什么与不包括什么的定义和控制过程，其任务是界定项目包含且只包含所有需要完成的工作。 上述定义表明了PMI的政策，PMI提倡“不做额外的工作(No Extra)，不要镀金(No GoldPlating)”。项目范围管理是项目能否成功的决定性因素，项目经理在与客户及在组织内界定项目范围时，还必须同时确定项目的假设、限制条件以及排除事项，也就是通常所说的“是什么，不是什么”的问题。 3.1.2范围管理规划需要弄清楚的7个问题 当项目经理开始一个新项目的时候，首先要做的事情之一就是弄清楚这个项目究竟需要一个什么样的东西。 除了一些明确的客户需求和提供的研讨文档之外，可能还有其他一些事情作为项目范围的一部分，而这些往往需要通过调查才能得出来。 如何调查？需要项目经理和项目的赞助商或项目中的其他主要利益相关者坐下来，按照下面提出的7个问题，逐一进行了解。要让他们明白，现在花费一点时间进行询问来更好地了解他们对于项目的期望，胜过项目不停返工所带来的损失。 1. 谁在定义范围 项目经理需要第一个沟通的对象就是项目赞助商，尽管他们可能不是定义项目细节的正确人选，但从他们口中可以得知能够定义项目正确需求的人。 也可能是另一些人，只要知道了这些人员名单，项目经理就能按图索骥，将这些人列为第二轮沟通的对象。第二轮的沟通可以面对面单独沟通，也可以组织一个项目研讨会，将自己理解的要求和对方进行讨论，看双方是不是在范围的定义上保持一致。 或者采取统一的标准描述和名称，便于后续的审核和验收； 又或者如果项目范围过于扩大化，可以建议形成另一个或若干个项目进行。 软件项目管理微课视频版 第 3 章项目范围管理 2. 谁批准范围 不要寄希望于通过一次或几次集体讨论就能确定项目的范围，在此期间总是会不断地出现冲突，这种冲突维持的时间越长，对于项目的启动就会越延误。这个时候需要有人能够在冲突发生的时候进行仲裁，或者当同时存在几个选项的时候进行选择。 这个批准的权力可以交予项目赞助商，如果项目赞助商无法判断，那么可以建立一个委员会进行审核并批准，这种批准需要预留出一定的时间。另外，等到项目正式实施交付的时候，项目范围往往也可能出现变更，这时，委员会也需要进行审核和批准。 3. 项目目标是什么 如果说项目范围是帮助项目经理画了一个“圈”以避免超出范围之外的额外交付，那么了解项目赞助商或主要客户需要通过项目实现的目标则更加重要，这样会更容易帮助对方通过项目来实现。目标和范围是不一样的，目标往往是通过项目最终实现的成果来体现。 如果项目目标较大，则需要和对方沟通，分解确定形成若干个小目标或若干个阶段性目标，这些小目标可以是小的成果，成果可能是有形实体产品，也可能是无形的服务产品。 不管是哪一种，都需要通过相关的文件进行项目总的约定，如果没有最终的文件进行确认，那么项目经理需要开始和项目的关键利益相关者进行沟通并确定。 4. 如何知道是否达成目标 这个问题牵涉到如何衡量目标的达成。想要达成目标，必须制订可实施的计划以及详细的步骤，这些计划要具备可行性，不能脱离实际进行编制。 建议通过专家讨论或经验共享制订项目的目标达成计划，然后从中找出关键步骤，并理清各个关键步骤之间的搭接关系。有了这些关键步骤，就可以整理出完成这些关键步骤的关键因素，通过对关键因素的分析，设定达成目标的衡量标准,通过衡量标准对关键步骤进行监控，或者说通过这些标准制订出关键绩效指标(Key Performance Indicator，KPI)对项目成员进行考核，才能让所有人明白目标是否达成。 5. 项目经理的灵活性有多大 项目经理现在基本上都知道项目管理的三要素(进度、成本和质量)，当前的项目需要依赖哪些资源，是不是有足够的成本和时间来完成这个项目。 在正式开始项目之前，项目经理要确定三要素限制是否可以灵活改变，例如在要求加快进度的情况下可以降低质量标准，或增加资源投入。 对于灵活性的把握，往往会涉及范围的变更以及计划的改动，项目经理必须要确定自己的灵活性大小，如果超出自己的范围，那么必须要确定一个更高层的人或委员会支撑自己应对项目中出现的变动，相当于扩展项目经理的灵活性范围。 6. 关键假设是什么 在确定项目范围的时候，每个人都会做出一些关键假设，项目经理这个时候的主要工作就是确保已经全部了解并记录下来，这些关键假设会大大影响到项目。例如，项目赞助商可能会假设用户喜欢项目最终产品的创意，尽管这些产品的对象实际是未成年人。 项目经理需要分析所有的关键假设，通过提出正确的问题找出错误的关键假设，运用好这一点，可以适当地管理项目以及客户的期望。关键假设往往和风险相关联，一旦关键假设没有成立，严重时会导致项目范围的大范围变更甚至失败，项目经理一定要谨慎。 7. 问题解决是否彻底 想要完美地做完一个项目，项目经理要时刻注意反思。每当项目中解决掉一个问题的时候，项目经理需要组织项目团队进行反思，确保他们已经完成了解决这个问题所做的一切。 而且这个问题要不断地让项目的所有利益相关者来考虑，自己是不是为项目做完了一切该做的事情。 综上所述，想要完成项目范围规划需要做的事情比这7个简单的问题还要多得多，但在项目范围管理规划时思考这些问题，是一个很好的开始，项目经理会发现很多自己不知道的事情。项目经理可以帮助团队确定项目中的优先事项，当开始工作的时候，应该共同理解项目中的交付范围，不断地谈论项目范围是让项目受到关注的好方法。 3.1.3范围管理规划的结果 1. 范围管理计划 根据项目章程、项目管理计划中已批准的子计划、历史项目信息和经验教训等，可以得到项目范围管理计划。项目范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。项目范围管理计划有助于降低项目范围蔓延的风险，其内容主要包括： (1) 如何编制详细的范围说明书； (2) 如何根据项目范围详细说明书制定项目分解结构； (3) 确定如何审批和维护范围基准； (4) 确认和验收项目产出物和项目可交付物的过程和方法； (5) 控制项目范围变更的过程和方法等。 根据项目需要，范围管理计划可以是正式或非正式的，详细的或概括性的。 在范围计划的编制过程中，应注意认真做好3方面的工作。其一是拟定计划的工作流程。因为计划工作可看作是项目管理系统的一个子系统，所以必须建立合理的计划工作程序，提出具体的规范化的计划文件要求。其二是做好计划中的协调。按照总目标、总任务和总体计划，起草招标文件、签订合同，注意不同合同的协调和不同层次计划之间的协调。其三是计划编制后的工作。报主管部门批准后，要争取各方面对计划结果达成共识，作为信息提供给相关利益者，争取他们的支持，为计划的实施创造有利条件，也为以后阶段范围管理提供框架性指导。 2. 需求管理计划 作为范围管理计划的另一个结果，需求管理计划描述将如何分析、记录和管理需求。需求管理计划需要根据项目章程、项目管理计划中已批准的子计划、以往项目的经验和教训等信息制订。需求管理计划也是项目管理计划的组成部分，其主要内容包括： (1) 如何规划、跟踪和报告各种需求活动； (2) 配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限； (3) 需求优先级排序过程； (4) 产品测量指标及使用这些指标的理由； (5) 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。 3.2需 求 收 集 需求收集是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是，为定义和管理项目范围(包括产品范围)奠定基础。 3.2.1需求收集的方法 项目需求收集应该建立在已有的项目文档和项目知识基础上，如项目章程、项目管理计划(范围管理计划、需求管理计划和干系人参与管理计划等)、项目文件、商业文件、协议(项目和产品需求方面的)、事业环境因素和组织过程资产。 以下为常见的几种软件项目需求收集方法。 1. 问卷调查 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况： 受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。 2. 访谈 访谈是一种通过与干系人直接交谈来获得信息的正式或非正式方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答，通常采取“一对一”的形式，但也可以有多个被访者或多个访问者共同参与。访谈有经验的项目参与者、干系人和领域专家，有助于识别和定义项目可交付成果的特征和功能。 3. 引导式研讨会 引导式研讨会通过邀请主要的干系人一起参加会议，对产品需求进行集中讨论与定义。研讨会是快速定义项目需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一好处是能够比单项会议更快地发现和解决问题。 例如，在软件开发行业，就有一种称为“联合应用开发(或设计)(Joint Application Development，JAD)”的引导式研讨会。这种研讨会注重把用户和开发团队集中在一起，来改进软件开发过程。在制造行业，则使用“质量功能展开(Quality Function Deployment，QFD)”这种引导式研讨会，帮助确定新产品的关键特征。QFD从收集客户需求(又称为“顾客声音”)开始，然后客观地对这些需求进行分类和排序，并为实现这些需求而设置目标。 4. 头脑风暴 头脑风暴法又称为智力激励法、自由思考法或集思广益会，是用来产生和收集对项目需求与产品需求的多种创意的一种技术。头脑风暴法分为直接头脑风暴法(通常简称头脑风暴法)和质疑头脑风暴法(也称为反头脑风暴法)。前者是在专家群体决策时尽可能激发创造性，产生尽可能多的设想的方法，后者则是对前者提出的设想、方案逐一质疑，分析其现实可行性的方法。 头脑风暴法的参加人数一般为5~10人，最好由不同专业或不同岗位者参加，会议时间控制在1小时左右。设主持人一名，主持人只主持会议，对设想不作评论。设记录员1~2人，要求认真将与会者的每一设想不论好坏都完整地记录下来。为了使与会者畅所欲言，互相启发和激励，达到较高效率，头脑风暴法应遵守如下原则。 (1) 庭外判决原则： 对各种创意(意见、建议)、方案的评判必须放到最后阶段，此前不能对别人的创意提出批评和评价。认真对待任何一种创意，而不管其是否适当和可行。 (2) 欢迎各抒己见，自由鸣放： 创造一种自由的气氛，激发参加者提出各种荒诞的想法。 (3) 追求数量： 创意越多，产生好创意的可能性越大。 (4) 探索取长补短和改进办法： 除提出自己的创意外，鼓励参与者对他人已经提出的创意进行补充、改进和综合。 5. 原型法 软件项目中，原型法是个相对现代的收集需求的方法。该方法中，在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，它使干系人有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。原型法符合渐进明细的理念，因为原型需要重复经过制作、试用、反馈、修改等过程。在经过足够的重复之后，就可以从原型中获得足够完整的需求，进而进入设计或制造阶段。原型法适用于用户需求不明确的场合。 3.2.2软件项目需求收集的挑战 软件项目的主要目标中进度和成本指标一般都有明确的定义，分歧较少，而对于范围和质量目标弹性较大，不易界定，如果合同签订时这些指标定义模糊不清、主观性较强，会为以后的项目实施埋下隐患。项目纷争的原因很多，有逾期不能完工的，有质量达不到指标的，有甲方不能提供有效支持的，有项目成果不符合实际需求的，等等。从结果上讲，这主要是由其中一方认为项目目标不能达到导致的，当然，由于自身的技术和管理上的原因导致目标不能达到，这部分纷争比较容易沟通、判定和解决，而比较容易引起纷争却又棘手的往往是项目目标理解不一致。 每一个项目管理者都希望尽可能减少纷争，使项目能够顺顺利利地完成。在一些软件项目，由于涉及面广、技术性强、大众对其认识不深等诸多原因，具体需求繁杂多变，质量指标主观性强等不易界定，项目成果难以评估定论。因此，软件项目在管理上矛盾纷争不断。 1. 软件项目需求收集的制约因素 在项目实施之初，做好需求分析是减少软件项目纷争的首要前提。因为只有准确理解并完整描述甲方的需求目标，双方达成共识，才不至于发生矛盾纷争。但是，在实际操作中要真正做到需求分析全面与描述准确并非易事，因为需求分析受以下几方面的影响。 (1) 需求提出的局限性。一般代表甲方(用户单位)提出需求的是技术部门的负责人，大部分对整个企业或其他业务领域并不熟练，造成需求不清。特别是涉及整个组织运作的集成系统，由于负责人职位问题，很少能够熟知全局业务运作，所提出的需求的完整性因人而异。况且，有些业主持有甲方的“霸主”态度，总说“以后不行再改、再加”，或者要求加上“一些有关的功能”等模糊意义的需求，这样导致需求分析者未能全面准确地掌握需求源泉。 (2) 需求描述的复杂性。需求的完整描述不仅面面俱到，而且内部的关联性很强，错综复杂。所以需求描述很花费人力和时间，一个稍大一点的软件项目的需求描述就有上百页，并且需求描述粒度会因客户的要求而不同，粒度小的需求描述就更多。 (3) 需求审查的随意性。甲方面对如此繁杂的需求分析与描述举行的需求评审会，专家和各个业务客户往往因为会议组织安排问题和时间仓促问题而流于形式，并不能对需求描述进行深入细致的分析。 (4) 需求分析的时间性。不管是甲方还是乙方的上层，都希望项目能够真刀真枪地干起来，而不想在这样“纸上谈兵”的需求分析上花费太多的时间。一些资深专家普遍认为，需求分析阶段的时间应不少于整个项目阶段的20%~30%，但迫于各种现实情况，匆匆走过场的大有人在。 2. 减少软件项目纷争的措施 虽然现实困难很多，但是要想避免日后发生矛盾，清除这一主要的矛盾根源，甲乙双方一定要在需求收集和需求分析阶段下足功夫，要有啃硬骨头的精神，不怕繁，不要急，认真沟通协商，千万不要以为只是“纸上谈兵”，急于冒进。一个高质量的需求分析是项目后续阶段的基础和依据，是减少纷争以及项目成功的关键。 (1) 减少软件项目纷争的一个重要控制措施是建立严格的变更控制制度。项目进行过程中，项目的环境和条件在不断变化，导致需求和范围也在变，有增、有减也有修正。一般变更对项目都有影响，有时影响是巨大的、严重的，所以变更必须控制。严格的变更控制制度要求甲乙双方的项目经理对每一次变更的必要性和影响评估必须充分论证，并正确认识到变更的影响，正式签字确认。这样可以有效地抑制变更的随意性和变更频度，减少对项目正常实施的干扰和影响，可以避免因变更随意性或项目失控所引发的纷争。 (2) 减少软件项目纷争的一个最有力手段是及时良好的沟通。合同一旦签订，甲乙双方就是“同一战壕的战友”，为的是项目成功这一共同目标。项目发生矛盾和困难不可避免，但如果双方能够相互理解，充分沟通，精诚协作，问题是可以解决的。如果只顾自身利益，不懂得合作与妥协，只能两败俱伤。为了达到及时沟通，最好甲乙双方等项目干系人组合成立一个PMO(项目管理办公室)，定期举行项目实施会议，依据制定好的时间基线和质量基线实时监督项目进度、质量等目标的实现，发现机会或偏差，认真查找问题，立即采取利用或补救措施，化解矛盾纷争，或扼杀矛盾纷争于萌芽之中。 (3) 减少软件项目纷争的一个重要的保障措施是做好风险预算。一旦发生矛盾，必须控制和处理，一般要产生费用，如果没有资金保障，矛盾和纷争难以解决。一种情况是确实因为自身责任问题产生的矛盾纷争，必须支出进行补救或赔偿的，才能够消除和化解； 另一种情况是未能确定责任主体，需要借助其他工具手段或第三方认定的，也需要暂时为鉴定付出代价，如项目验收时需聘请第三方评估机构，如果没有资金预留很难执行。这两种情况一般会从风险预算中支出。有一些建设单位(甲方)由于缺乏项目管理经验，在建设初期忽视了这份风险预算，只能选择成本低的谈判方式，但这种单一方式有时并不能有效地解决问题，而是陷入了无休止的谈判僵局。 (4) 减少软件项目纷争的一个关键步骤是合同中拟定的验收约定。项目矛盾纷争在短兵相接的验收阶段集中爆发，对该阶段事先拟定详细、清晰、平等的约定，是避免项目验收纷争的关键。目前的建设市场是买方市场，甲方占强势地位，验收是其制约项目的“杀手锏”。如果在合同签订之时，同时约束了该“杀手锏”随意的权力，不会因双方地位失衡而产生纷争，有利于项目验收阶段的顺利进行。 (5) 要约束甲乙双方权利的主观随意性，必须在验收约定中，条款应尽可能详细清晰，具有可操作性。应该避免诸如“大问题不可验收”“小缺陷可以验收”“部分验收”“其他”等模糊描述，而明确定义何谓“大问题”“小缺陷”“部分”等具体规定，如“大问题”包括哪些情形直至可操作为止。有必要的话，还可以制定系统验收评价指标体系，给能够预知成果和风险设定分值和权重，这样大大减少因主观认识发生的误差。 再有，条款的约定应平等公正，甲乙双方的权利和义务必须对等，对事情的处理必须公正公平。例如，甲乙双方对聘请的验收专家都有质疑的权力，可以请第三方公正的质量评估机构参与； 对乙方逾期未能完工的处罚，甲方接受完工申请后未能及时组织验收的当然也应处罚，等等。 3.2.3需求收集的结果 1. 需求文件 根据已有的项目文档和项目知识，通过一定的需求收集方法，可得到需求文件和需求跟踪矩阵。 需求文件描述各种单一的需求将如何满足与项目相关的业务需求。一开始，可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的且主要干系人认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。 需求文件主要内容如下。 (1) 业务需求。整个组织的高层级需要，如解决业务问题或抓住业务机会，以及实施项目的原因。 (2) 干系人需求。干系人或干系人群体的需要。 (3) 解决方案需求。为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。 (4) 功能需求。功能需求描述产品应具备的功能，如产品应该执行的行动、流程、数据和交互。功能需求通常描述业务流程、信息以及与产品的内在联系，可采用适当的方式，如写成文本式需求清单或制作出模型，也可以同时采用这两种方法。 (5) 非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，如可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。 (6) 过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。 (7) 项目需求。项目需要满足的行动、过程或其他条件，如里程碑日期、合同责任、制约因素等。 (8) 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，如测试、认证、确认等。 (9) 验收标准。 (10) 体现组织指导原则的业务规则。 (11) 对组织其他领域的影响，如呼叫中心、销售队伍、技术团队。 (12) 对执行组织内部或外部团体的影响。 (13) 与需求有关的假设条件和制约因素。 2. 需求跟踪矩阵 需求跟踪矩阵(Requirement Traceability Matrix，RTM)是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪。 需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值。它为人们在整个项目生命周期中跟踪需求提供了一种方法，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。最后，需求跟踪矩阵为管理产品范围变更提供了框架。 需求跟踪矩阵主要包括： (1) 从需求到业务需要、机会、目的和目标； (2) 从需求到项目目标； (3) 从需求到项目范围/WBS中的可交付成果； (4) 从需求到产品设计； (5) 从需求到产品开发； (6) 从需求到测试策略和测试脚本； (7) 从宏观需求到详细需求。 应在需求跟踪矩阵中记录各项需求的相关属性，这些属性有助于明确各项需求的关键信息。需求跟踪矩阵中的典型属性包括： 独特的识别标志、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、现状(如“活跃中”“已取消”“已推迟”“新增加”“已批准”等)和实现日期。为确保干系人满意，可能须补充一些属性，如稳定性、复杂程度和验收标准等。一个软件项目需求跟踪矩阵如表31所示。 表31软件项目需求跟踪矩阵 需求跟踪矩阵 项目中心 项目描述 成本中心 编号关联编号需求描述变更标识需求状态对应设计对应代码对应测试复杂程度验收 标准备注 1 1.1网上审批增加已批 1.2 1.3 1.3.1 2 2.1打印功能原始已批 2.1.1 2.2 33.1 44.1 需求跟踪矩阵并没有规定的统一格式，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。一个简洁的软件项目需求跟踪矩阵如表32所示。 表32简化版软件项目需求跟踪矩阵 需 求 编 号需 求 名 称类别来源状态 R23笔记本电脑内存硬件项目章程，笔记本电脑规格说明已完成，已满足用户4GB内存需求 需求跟踪矩阵的作用如下。 (1) 在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效工具，如果不借助需求跟踪矩阵，则发生上述变更时，往往会遗漏某些连锁变化。 (2) 需求跟踪矩阵也是验证需求是否得到了实现的有效工具，借助需求跟踪矩阵，可以跟踪每个需求的状态： 是否设计了、是否实现了、是否测试了。 有多个角色参与建立需求跟踪矩阵(RTM)。需求开发人员负责RTM有关客户需求到产品需求的内容，测试用例的编写人员负责建立RTM关于需求到测试用例的内容，设计人员负责需求到设计的RTM建立，等等。过程质量保证人员负责检查是否建立了需求跟踪矩阵，是否所有的需求都被覆盖了。 此外，需求跟踪矩阵要纳入范围基线管理。纳入基线后，每次变更都要申请，需求跟踪矩阵的变更一般是和其他配置项的变更一起申请，很少单独申请变更需求跟踪矩阵，除非需求跟踪矩阵有错误。 3.3范 围 定 义 范围定义是制定项目和产品详细描述的过程。本过程的主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或成果的边界。 3.3.1范围定义的方法 项目范围定义应该建立在已有的项目文档和项目知识基础上，如项目章程、项目管理计划、项目文件(如假设日志、需求文件、风险登记册等)、事业环境因素和组织过程资产。 常见的项目范围定义方法有以下几种。 1. 专家判断法 范围管理领域的专家判断常用来分析和定义详细的项目范围说明书，他们的判断和专长可运用于任何技术细节。 2. 产品分析 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。每个应用领域都有一种或几种公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。 3. 引导式研讨会 具有不同期望或专业知识的关键人物参与这些紧张的工作会议，有助于就项目目标和项目限制达成共识。 4. 多标准决策 多标准决策分析是一种借助决策矩阵使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准完善项目和产品范围。 3.3.2范围说明书 根据项目章程、范围管理计划、需求文件、事业环境因素和组织过程资产中的相关信息，通过一定的范围定义方法，可得到一份项目范围说明书。 项目范围说明书详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。项目范围说明书也表明项目干系人之间就项目范围所达成的共识。为了便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。项目范围说明书使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作； 它还为评价变更请求是否超出项目边界提供基准。 项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书主要包括以下内容(可能直接列出或引用其他文件)。 1. 产品范围描述 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。 2. 产品验收标准 定义已完成的产品、服务或成果的验收过程和标准。项目可交付成果既包括组成项目产品或服务的各种结果，又包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可以详细也可以简略。 3. 可交付成果 在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。 4. 项目的除外责任 通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。 5. 项目制约因素 列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素，如客户或执行组织事先确定的预算、强制性日期或强制性进度里程碑。如果项目是根据合同实施的，那么合同条款通常也是制约因素。 6. 项目假设条件 列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果。在项目规划过程中，项目团队应该经常识别、记录并验证假设条件。 虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。一个软件项目范围说明书目录示例如图31所示。 图31项目范围说明书目录示例 一个软件项目的初步范围说明书如表33所示。 表33某软件项目的初步范围说明书 某软件项目范围说明书 1. 项目基本情况 项目名称 project name某高校志愿者管理系统项目编号 project codeT0101 制作人 prepared by张三审核人 reviewed by王五 项目经理 project manager吕四制作日期 date2019年6月28号 2. 项目描述 2.1 项目背景 2017年9月，民政部发布了《志愿服务信息系统基本规范》，这是我国志愿服务信息化建设领域第一个全国性行业标准，是开发、完善志愿服务信息系统的基础标准和重要参考，是推进志愿服务制度化建设的重要举措。2019年12月1日起，国务院《志愿服务条例》将正式实施，其中明确强调了志愿服务信息系统建设的重要性及紧迫性。走访调研众多高校，发现此方向内理论研究较多，实际系统开发较少，绝大部分高校还停留在使用电子邮箱、Excel等最原始的工具，没有成规模的系统进行广泛应用。现高校志愿服务数字化程度较低，以QQ群、短信群发为主。志愿管理和招募方面的研究暂时停留在固定模式，在运行和操作方面还有很大的优化提升空间。杭州志愿者推广的志愿中国平台是数字化的一个代表。志愿中国平台致力于为志愿者提供志愿服务和签到签退等。我们结合高校志愿服务的特殊情况，全面引入志愿者管理系统(VMS)平台，做到结合自身和外部环境结合，为全校志愿者提供更全面的服务和信息来源。 2.2 项目目标 项目总目标： 在投资不超过10万元成本的前提下，能设计出一款VMS系统，满足一般高校青年志愿者协会的需求，有效提高其工作效率。 分目标： (1) 项目预算不超过10万元。 (2) 两个月内完成VMS系统的开发工作。 (3) 志愿者管理系统运行流畅，支持多并发的情况，同时符合公司安全性的要求，满足公司提出的项目需求。 实现如下产品特征： 1) 志愿者活动招募 新建招募： 新建的招募活动将在微信“志愿者活动招募系统”显示。 我的招募： 查看用户所在组织的全部招募活动。 2) 志愿者活动管理 新建活动： 新建志愿者活动。 按名称查询活动： 通过名称查询平台内的志愿者活动。 审核中的活动： 查看平台内全部审核中的志愿者活动(志愿汇平台除外)。 未通过的活动： 查看平台内全部未通过的志愿者活动(志愿汇平台除外)。 进行中的活动： 查看平台内全部进行中的志愿者活动。 已完成的活动： 查看平台内全部已完成的志愿者活动。 我的活动： 查看用户所在组织在平台内全部志愿者活动。 3) 志愿者工时查询 一般查询： 通过学号、姓名、活动名称对工时进行精确查询、模糊查询。 续表 某软件项目范围说明书 刷卡查询： 通过读卡器对工时进行刷卡查询。 4) 用户中心 个人信息： 查看用户各项基本信息。 修改密码： 修改用户密码。 5) 维护管理 活动审批： 对平台内审核中的志愿者活动进行审批。 开启上传通道： 开启不在工时表提交时间的活动的工时表上传权限。 删除工时表： 删除已上传的工时表。 同步志愿中国数据： 立即同步志愿中国的志愿者活动信息。 显示/隐藏活动： 显示或隐藏平台内的志愿者活动。 工时总表： 建立工时总表列表，提供下载通道。 工时文件更新： 更新志愿者工时文件。 6) 红黑名单 功能选项： 红名单、黑名单、内部名单。 新增记录： 输入相关人员的个人信息。 删除记录： 系统根据等级和时间限制自动删除记录或手动删除记录。 记录使用： 志愿者报名后，如是名单中的人显示相关记录。 7) 超级管理 用户管理： 对用户进行添加、修改、删除和权限管理操作。 3. 项目范围 3.1 产品范围(功能及其描述) 1) 新建招募 在新建招募过程中，用户需要填写活动名称(不超过15字)、活动地址、活动时间(日期及具体时间)、需求人数(数字)、活动详情和联系人及联系方式共6项内容。新建成功后，活动立即进入招募状态，微信“志愿者活动招募系统”将显示此活动。 2) 招募管理 招募管理功能分别显示正在招募中的活动和已经结束招募的活动，招募中的活动显示实时报名人数。单击“详情”后，进入活动详情页，可进行招募开启/停止，招募信息导出功能。招募停止后，也可再次开启。单击“报名信息”后，将弹出Excel下载框，单击即可下载。 3) 志愿者活动招募系统 志愿者通过微信平台进入志愿者活动招募系统，进入后即可浏览招募中的全部活动。单击活动后的“详情”可查看活动具体内容。单击“我要报名”，可填写报名表格。单击“返回主页”，返回活动列表页。活动报名信息提交前将进行第一次验证，验证填写内容是否有误。 报名成功后，显示“报名成功”页面，信息保存至系统中。 4) 新建活动 用户可通过新建活动功能新增志愿者活动。需要填写的内容有： 活动名称、活动地址、开始日期、结束日期、活动策划。开始日期和结束日期点开后将转至日历，通过日历选择日期。活动策划从Word文档中复制到编辑框中即可。 5) 查询活动 志愿者活动在本平台分为以下4类： 审核中的活动、未通过的活动、进行中的活动、已完成的活动。用户通过按名称查询活动功能，输入活动名称，将查询出全部包含此关键词的活动。 续表 某软件项目范围说明书 6) 跟踪活动 在本平台提交的活动以“审核中的活动”作为初始状态，志愿汇平台提交的活动以“进行中的活动”作为初始状态，活动的最终状态均为已完成的活动。其中，进行中的活动可再细分为审核通过、工时表等待提交、工时表超时未交3类。在提交活动后，活动状态成为“审核中”。在活动审核后，活动状态成为“进行中”或“未通过”，用户可在活动详情页面中查看其所在组织的活动的审核说明等信息。状态为“进行中”的活动在系统中显示为3种情况： 在活动结束之日之前，活动状态为“审核通过”； 在活动结束之日起3天内，活动状态为“工时表等待提交”； 超过活动结束之日起3天，活动状态为“工时表超时未交”。若提交工时表，活动状态立即转为“已完成”。在活动流程结束即完成工时表提交后，活动状态成为“已完成”，活动周期结束。 7) 我的全部活动 在“我的全部活动”功能中，页面显示用户所在组织的全部类型的活动，以便各组织进行排查筛选。 8) 上传工时表 在“工时表等待提交”状态或开启上传通道后，用户可单击“活动详情”，拉至工时表一栏。此时工时表一栏可对本活动上传工时表。选择本地压缩包文件后单击“提交”按钮，文件上传后显示“上传成功”，活动进度栏全蓝，完成工时表提交。请注意，每个活动仅可提交一次工时表，提交后无法进行修改，提交前请仔细核对文件是否有误。 9) 一般查询 用户通过“一般查询”功能可实现通过学号、姓名、活动名称的精确、模糊志愿者工时查询。使用时，首先勾选需要选用的查询条件，然后输入关键字，最后勾选是否模糊，单击“查询”即返回查询结果。查询结果显示的为各查询条件查询结果的并集，并非各关键词的交集。 10) 刷卡查询 此功能仅限已经连接读卡器的计算机使用，无读卡器无法使用此功能。首先通过读卡器读取卡号。若未绑定，则显示“请绑定学号”字样，此时需要输入此卡需要绑定的学号，并单击“绑定”按钮。单击“绑定”按钮后，弹出蓝色的“绑定成功！”字样，同时显示此卡的志愿者工时信息。此时绑定操作成功。如卡号与学号对应关系有误或因其他原因需要变更绑定关系，单击“解绑”按钮进行解绑操作。单击“解绑”后，弹出蓝色的“解绑成功！”字样，同时志愿者工时信息恢复为空白。此时解绑操作成功。 11) 个人信息 个人信息页显示用户唯一序列号(Uid)、姓名、组织和其所有权限。 12) 修改密码 用户可在此处修改其密码，密码重新登录后有效。 13) 活动审批 具有维护管理权限的用户可通过本功能对待审核的活动进行审批操作。单击功能菜单后，页面列表显示全部待审核的活动。单击活动最右侧“审批”按钮进入活动详情页。填写审批意见并勾选是否通过，单击“审批”按钮，提交审批结果。审批后，活动状态自动变更为“进行中”或“未通过”，审批意见及审批人将自动显示在活动详情页中。 14) 开启上传通道 在活动状态不处于“工时表等待提交”时，用户无法提交工时表。通过此功能，可开启工时表上传通道。输入活动号后，单击“开启通道”按钮。通道开启后，可随时上传本活动的工时表。 15) 删除工时表 在工时表已提交后，通过此功能可删除已上传的工时表。输入活动号后，单击“删除文件”按钮，即可对已经上传的工时表文件进行删除。系统自动每5分钟自动同步一次志愿中国数据，如有特殊需要，可自行使用此功能。单击“立即同步”按钮后，系统后台将自动进入志愿中国系统，将已通过审核的活动拉取至本系统。 续表 某软件项目范围说明书 16) 显示/隐藏活动 用户可使用本功能将系统中的活动显示或隐藏。隐藏后，用户及管理员将均无法查询到活动的活动号，请谨慎使用此功能。此功能有可能带来不可挽回的损失。 17) 工时总表 工时总表功能可将工时表文件按上传时间排序后以列表形式显示。进入功能页面后，单击“生成总表下载列表”，页面显示总表下载列表。生成下载列表后，可单击“创建总表下载记录节点”按钮，对下载情况进行标记。标记后则显示为表格中没有“下载表格”按钮的一行。 18) 工时文件更新 此模块为工时文件提供更新功能。进入模块后，选择本地计算机文件，单击“上传”，完成工时文件更新。使用时请注意备份好文件，新文件上传时将覆盖原有文件，原有文件将无法找回。 19) 新增记录 登录成功后选择“红黑名单管理”功能。根据高校具体的(注册)志愿者协会红黑名单方案要求选择红黑名单录入，选择新增记录。 20) 删除记录 根据等级要求，在等级设定时间自动删除该条记录，也可以手动单击“删除”按钮删除该记录。 21) 报名显示 在红黑名单上的志愿者报名参加活动时，会在他们的报名信息上显示红黑名单记录相关信息。 22) 用户管理 进入用户管理功能后，将列表显示系统中全部用户及其部门、权限。单击“新增用户”按钮，可新增用户。新增用户后，初始密码为123456。每个用户后可进行“修改”“重置密码”“删除”3个操作。“修改”功能可对用户的姓名、部门和权限进行修改。“重置密码”功能可将用户密码重置为123456。“删除”功能可删除此用户(不可恢复)。 3.2 项目工作范围 包含开发出满足用户需求的VMS系统，以及针对该系统而进行的用户调研活动和管理活动。该系统的硬件软件配置环境调研，对该系统使用的培训指导工作。 3.3 不包括的范围 (1) 系统应用的软硬件环境的搭建。 (2) 系统布置的服务器的租借与购买。 4. 双方的职责 (1) 甲方应该提供给乙方系统开发的需求，同时提供需求调研的帮助。如有合同外的需求变动应征得乙方评估同意，补充入合同。 (2) 乙方应满足甲方的需求，制定合同文件，按双方协定的开发方案进行开发，开发出符合甲方需求标准的系统，交付包括系统，用户说明，技术文档在内的交付物，如有其他突发情况应及时与甲方联系。 5. 交付成果 5.1 主要交付成果 交付物： VMS系统安装程序、源代码、系统使用说明书、技术文档 5.2 辅助交付成果 交付物： 系统测试报告等 6. 验收标准和验收流程 6.1 产品验收标准 产品应包含合同所签订的所有功能需求。 同时产品应满足以下软硬件环境： 续表 某软件项目范围说明书 硬件配置：  CPU： Intel主频2.33GHz  内存： DDR3 1G  硬盘： 50G 软件配置：  操作系统： Windows Server 2008 R2  数据库： MySQL 5.7  服务器： Tomcat 8.5 系统的可靠性要高，平均故障间隔时间应大于6个月，平均修复时间小于一天，不能出现严重错误，千行代码错误数目应小于2。系统的安全性也需要得到第三方机构的认证鉴定，符合甲方的安全级别。系统的性能应满足10万并发量以下能正常运行的标准，吞吐量应满足每秒1万以上。获得该高校青年志愿者协会认可后，产品才能够成功验收。 6.2 工作验收标准 在开发过程中，应保留各类开发文档、测试文档等资料，同时应保留各个员工的工作日志，以核定开发工作是否严格按照项目书进行，工作量是否与预计工作量接近。 6.3 验收流程 1） 验收申请 开发工作完成后，乙方向甲方提出验收申请。 2） 验收准备 根据软件项目的特点，在验收时开发商应收集以下文档。 编号名称形式介质 1软件需求说明书文档电子、纸质 2系统概要设计说明书文档电子、纸质 3总体设计说明书文档电子、纸质 4数据库设计说明书文档电子、纸质 5详细设计文档文档电子、纸质 6为本项目开发的软件源代码文档文档电子、纸质 7性能测试报告、功能测试报告文档文档电子、纸质 8维护手册文档电子、纸质 9系统参数配置说明文档电子、纸质 10系统崩溃及恢复步骤文档文档电子、纸质 11技术服务和技术培训等相关资料文档电子、纸质 12项目总结报告文档电子、纸质 除上述文档外，还应单独收集、保存各应用软件源程序代码及开发商所用第三方资源信息； 对于原始程序代码，要求能够在本地不经过任何特殊设置，即可编译并正常运行。 3） 验收测试 验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动，它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。软件验收测试分为3部分： 文档代码一致性审核、软件配置审核和可执行程序测试，其顺序可分为： 文档审核、源代码审核、配置脚本审核、功能测试、性能测试等。 4） 文档审核 文档审核的主要要求是确定软件开发的所有过程都在提交文档的控制下，对文档的具体要求如下。 续表 某软件项目范围说明书  文档完备性： 是否按照合同及其附件要求提交了全部文档。  内容针对性： 文档是否是甲方要求的文档。  内容充分性： 该文档全面、详细的程度。  文档的价值： 文档应该能够反映软件开发的整个过程，即需求中提到的功能在概要设计中体现，在详细设计中实现，在测试计划中检验。  内容一致性： 是否存在前后矛盾； 是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况。  文字明确性： 不使用“可能”“也许”“待定”等语义含糊不清的语句。  易读性： 能够在一篇文档中说明清楚的内容，尽量不要拆分成若干文档，不要循环引用，文档目录一目了然，结构清晰。 5） 源代码审核 源代码审核的主要要求是确保开发商将全部源程序交付甲方，并确保交付的代码没有版权问题，对源代码审核的具体要求如下。 (1) 版权明晰  提交的代码中注释版权的地方均应去掉版权声明，或声明版权为甲方所有。  得到甲方允许，可以使用的控件，由开发商提供无版权争议承诺书。使用其他的具有源代码的控件，均需要当作提交代码的一部分，直接置于编译环境的工程文件中，在编译发布时无须额外设置。 (2) 代码完整  开发商必须将所有实现用户需求的代码交付甲方。  除非已经得到甲方的允许，使用的控件也必须有源代码，并得到授权使用证明；  包含开发工具的程序文件； 要求能够在甲方计算机中正常编译、运行； 除非得到甲方允许，在甲方计算机中编译的时候无须额外安装开发工具的插件或控件。 (3) 可读性强 注释是软件可读性的具体体现。程序注释量不少于程序编码量的30%。程序注释不能用抽象的语言(如“处理”“循环”等)，要精确表达出程序的处理说明。为避免每行程序都使用注释，可以在一段程序的前面加一段注释，有明确的处理逻辑。 6） 配置文件审核 对于B/S程序，部署维护是软件生存周期中最长的一个过程，配置文件的审核显得尤为重要。对配置文件的审核要求与源代码的审核要求完全一致。 7） 测试用例编写及测试程序、脚本审核 这个过程是在文档审核和配置脚本审核后，为了检验通过源代码编译后的程序是否满足设计需求。检验方式主要是功能测试和性能测试； 这一阶段应该完成设计及其有关测试所包括的特性，还需要完成测试所需的测试用例和测试规程，并规定特性的通过准则。 (1) 测试用例说明： 列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。要求将测试用例与测试设计分开，可以使它们用于多个设计并能在其他情形下重复使用。 (2) 测试规程说明： 规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。 8） 集成测试/压力测试 常见的黑盒测试包括： 集成测试、系统测试。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。通过一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作，在协同工作时是否能够达到功能要求。 续表 某软件项目范围说明书 9） 验收测试 目的是检验待验收软件是否对平台和其他软件保持良好的兼容性。 10） 验收结论(成绩评定标准) 验收结束时，根据以上文档，填写验收结论，对软件的质量做出评价。 (1) 优秀  材料完整  软件可正常运行  实现项目软件需求说明书要求的各项功能需求  软件界面友好，易于交互  软件功能新颖，有较强创新 (2) 合格  本标准第2.1条要求的材料完整  可正常运行实现功能达到软件需求说明书要求的2/3以上 (3) 不合格  要求的材料不完整  软件不能运行 7. 项目的约束条件 (1) 时间约束： 必须满足最后期限(两个月内完成)。整个产品包含产品使用说明，将在项目开始后20天内交付使用。 (2) 成本约束： 必须满足预算限制(成本低于10万元)。 (3) 政策法规： 产品符合各项政策法规要求。 (4) 其他约束： 产品必须是可靠的； 结构必须是开放的，以便将来增加额外的功能； 产品必须是用户友好的； 项目可交互使用。 8. 前提和假设 假定： 假定所有资源都能及时提供。 9. 变更流程 9.1 变更管理组织 由CEO、项目经理、项目组成员等组成变更管理组织。 9.2 变更管理流程  建立基线、变更控制系统和变更控制流程  识别变更，并以书面格式提出变更请求  变更控制委员会(Change Control Board，CCB)审查变更请求  CCB批准或否决变更  将批准的变更纳入项目管理计划中  实施被批准的变更  监控被批准变更的实施情况  变更验证  沟通存档  变更日志更新 变更请求流程图(略) 9.3 决策与仲裁 决策与仲裁由变更管理委员会和产品代表共同商议决定。 3.4WBS创建 创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。本过程的主要作用是对所要交付的内容提供一个结构化的视图。 WBS最低层的工作单元称为工作包，工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。 创建项目WBS应该基于已有的项目文档和项目知识，如项目管理计划、项目文件、商业文件(如项目范围说明书和需求文件)、事业环境因素和组织过程资产。 3.4.1WBS创建的方法 最常用的WBS创建方法就是分解，分解就是把项目可交付成果划分为更小的、更便于管理的组成部分，直到可交付成果被定义到最底层的工作包为止，其中工作包是能够可靠地估算工作成本和活动历时的最底层工作单位，工作包的详细程度因项目大小与复杂程度而异。在WBS分解过程中，征求具备类似项目知识或经验的专家的意见是很有必要的。 1. 分解包含具体的任务 (1) 识别和分析可交付成果及相关工作。 (2) 确定工作分解结构的结构与编排方法。 (3) 自上而下逐层细化分解。 (3) 为WBS组成部分制定和分配标识编码。 (4) 核实可交付成果分解的程度是否恰当。 2. 分解的方法 (1) 把项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层，一个例子如图32所示。 (2) 把主要可交付成果作为分解的第二层，例子如图33所示。 (3) 按子项目进行第二层分解。子项目(如外包工作)可能由项目团队之外的组织实施。然后，作为外包工作的一部分，卖方须编制相应的合同工作分解结构。 (4) 对工作分解结构上层的组成部分进行分解，就是要把每个可交付成果或子项目都分解为基本的组成部分，即可核实的产品、服务或成果。工作分解结构可以采用列表式、组织结构图式或其他方式。不同的可交付成果可以分解到不同的层次。 (5) 某些可交付成果只需分解一层，即可到达工作包的层次，而另一些则需分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下以及工作实施效率降低。 (6) 要在未来远期才完成的可交付成果或子项目，当前可能无法分解。项目管理团队通常要等到这些可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的相应细节。这种技术有时称为滚动式规划。 图32以阶段作为第二层的WBS示例 图33以可交付物作为第二层的WBS示例 (7) 工作分解结构包含了全部的产品和项目工作，包括项目管理工作。通过把工作分解结构底层的所有工作逐层向上汇总，确保没有遗漏工作，也没有增加多余的工作。这有时被称为100%规则。 3. 一个WBS分解实例 一个软件项目WBS分解例子如图34所示，通过Microsoft的项目管理工具Project，可以自动为各个层次的任务编码。 图34某软件项目WBS分解 4. 分解结果的检验 在实际项目过程中，进行项目的工作分解是一项比较复杂和困难的任务，工作分解结构的好坏直接关系到整个项目的实施。任务分解后，需要核实分解的正确性。 (1) 更低层次的细目是否必要和充分？如果不必要或不充分，这个组成要素就必须重新修改(增加、减少或修改细目)。 (2) 最底层的工作包是否有重复？如果存在重复现象就应该重新分解。 (3) 每个细目都有明确的、完整的定义吗？如果没有，这种描述需要修改或补充。 (4) 是否每个细目可以进行适当估算？谁能担负起完成这个任务？如果不能进行恰当的估算或无人能进行恰当的估算，修正是必要的，目的是提供一个充分的管理控制。 5. WBS分解注意事项 对于实际的项目，特别是对于较大的项目，在进行工作分解的时候，还要注意以下几点。 (1) 要清楚地认识到，确定项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也是给项目的组织人员分派各自角色和任务的过程。应注意收集与项目相关的所有信息。 (2) 对于项目最底层的工作要非常具体，而且要完整无缺地分配给项目内外的不同个人或组织，以便明确各个工作的具体任务、项目目标和所承担的责任，也便于项目的管理人员对项目的执行情况进行监督和业绩考核。任务分解结果必须有利于责任分配。 (3) 对于最底层的工作包，一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典，用以描述工作包、提供计划编制信息(如进度计划、成本预算和人员安排)，以便在需要时随时查阅。 (4) 并非工作分解结构中所有的分支都必须分解到同一水平，各分支中的组织原则可能不同。 (5) 任务分解的规模和数量因项目而异，先分解大块任务，然后再细分小的任务； 最底层是可控和可管理的，避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量(40小时)。 需要注意的是，任何项目不是只有唯一正确的工作分解结构。例如，两个不同的项目团队可能对同一项目做出两种不同的工作分解结构。决定一个项目的工作分解详细程度和层次多少的因素包括： 为完成项目工作任务而分配给每个小组或个人的任务和这些责任者的能力； 在项目实施期间管理和控制项目预算、监控和收集成本数据的要求水平。通常，项目责任者的能力强，项目的工作结构分解就可以粗略一些，层次少一些； 反之，就需要详细一些，层次多一些。而项目成本和预算的管理控制要求水平高，项目的工作结构分解就可以粗略一些，层次少一些； 反之，就需要详细一些，层次多一些。因为项目工作分解结构越详细，项目就会越容易管理，要求的项目工作管理能力就会相对低一些。 3.4.2范围基准 根据项目管理计划、项目范围说明书、需求文件、事业环境因素和组织过程资产等知识信息，通过征询专家意见下的逐步分解，可得到项目范围基准。 范围基准包含经过批准的范围说明书、WBS和相应的WBS词典，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括如下内容。 (1) 项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件、制约因素以及验收标准的描述。 (2) WBS。WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。在WBS中一般会设置控制账户，控制账户是工作分解结构中的要素，是项目经理对项目的管理控制点，即针对控制账户的要素对项目的执行情况进行检查与考核。可以把工作包作为控制账户，也可以把更高层的要素作为控制账户。 (3) 工作包。WBS的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账户可以拥有两个或更多工作包，但每个工作包只与一个控制账户关联。 (4) 规划包。一个控制账户可以包含一个或多个规划包，它是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。 (5) WBS词典。WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。WBS词典中的内容可能包括： 账户编码标识、工作包描述(内容)、负责的组织、所需资源、成本预算、进度安排、质量标准或验收要求、责任人或部门或外部单位(委托项目)、资源配置情况、其他属性等。 (6) 其他信息。其他信息包括假设条件和制约因素、技术参考文献、协议信息等WBS词典之外的其他必要信息。 另外，在创建WBS后，应该对项目文件进行更新，需要更新的项目文件如下。 (1) 假设日志。随同本过程识别出更多的假设条件或制约因素而更新假设日志。 (2) 需求文件。可以更新需求文件，以反映在本过程提出并已被批准的变更。 3.5范 围 核 实 范围核实是正式验收已完成的项目可交付成果的过程。本过程的主要作用是使验收过程具有客观性； 同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。 软件项目的可交付物包括各工作阶段文档以及最终产品、服务或成果，如项目文件、项目工作说明书、WBS、资源日历、风险登记册、各阶段管理计划、协议、变更请求、软件产品、服务等。 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。范围核实与质量控制的不同之处在于，范围核实主要关注对可交付成果的验收，而质量控制则主要关注可交付成果是否正确以及是否满足质量要求。质量控制通常先于范围核实进行，但二者也可同时进行。 项目范围核实应该基于已有的项目文档和项目知识等，如项目管理计划(其中的范围管理计划、需求管理计划和范围基准等)、项目文件(如经验教训登记册、质量报告、需求文件、需求跟踪矩阵等)、核实的可交付成果、工作绩效数据等。 3.5.1软件项目的范围核实 范围核实包括与客户或发起人一起审查已完成的可交付成果，核实可交付成果的满意完成，并获客户或发起人对已完成的项目可交付成果的正式接受。 1. 范围核实 范围核实过程在项目或项目阶段末尾进行，如果项目提前终止，确认范围过程应当把项目完成的水平和程度记录下来。因为该过程在项目的每个阶段末尾发生，因此是贯穿整个项目生命期的过程。 范围核实通常和项目验收同时进行，一个范围核实示例如表34所示。 表34项目范围核实(验收)表 WBS编号交付物名称验收标准验收方式验收签署人员 3.1.1设计方案见文件设计方案审查标准会审A——项目经理 B——客户方项目经理 服务器一台该型号服务器的到货加电测试标准测试C——测试工程师 B——客户方项目经理 (略) 2. 范围核实与质量控制的区别 (1) 范围核实主要强调可交付成果的接受，质量控制强调可交付成果的正确并符合为其制定的具体质量要求。 (2) 质量控制一般在确认范围前进行，但也可同时进行。 (3) 范围核实一般在阶段末尾进行，质量控制并不一定在阶段末尾进行。 (4) 质量控制属内部检查，由执行组织的相应质量部门实施，范围核实则是由外部利害关系者(客户或发起人)对项目可交付成果检查验收。 3. 范围核实与项目收尾的区别 虽然范围核实与项目收尾工作都在阶段末尾进行，但范围核实强调的是核实与接受可交付成果，项目收尾则强调结束项目或阶段所要做的程序工作。 二者都有验收工作，范围核实强调验收项目可交付成果，项目收尾强调验收产品。 4. 范围审查 范围审查是指开展测量、检查与核实等活动，判断工作和可交付成果是否符合要求及产品验收标准。审查有时也称为检查、产品审查、审计和巡检等。在软件项目领域，审查包括各种确认和验收测试(如Alpha/Beta测试等)。 表35是软件项目范围审查表，表36是软件项目WBS审查表。 表35项目范围审查表 项目范围审查条目审 查 状 态审 查 结 果 项目目标是否准确和完整？ 项目目标的度量指标是否可靠和有效？ 项目的约束条件和假设前提是否真实和符合实际？ 项目的风险是否可以接受？ 项目范围能否保证项目目标的实现？ 项目范围定义下的项目工作效益是否高于项目成本？ 项目范围是否需要进一步研究和定义？ 表36WBS审查表 项目WBS审查条目审 查 状 态审 查 结 果 项目目标和目标层次描述是否清楚？ 项目产出物描述是否清楚？ 项目产出物及其分解是否都是为实现项目目标服务的？ 项目产出物是否被作为项目工作分解的基础？ 项目WBS层次划分是否与项目目标层次描述统一？ WBS中的各工作包是否都是为形成项目产出物服务的？ WBS中各工作包之间的相关关系是否合理？ WBS中各工作包所需资源是否明确和合理？ WBS中各工作包的考核指标是否合理？ 5. 范围核实中可能出现的问题及应对方法 (1) 范围核实通过： 先正式记录在文件中，并作为依据，继续进入项目或阶段收尾过程。 (2) 范围核实未通过： 无论何种原因被拒绝或未核实，都要记录下来，并附未验收通过的理由，一般需要继续进入整体变更控制过程处理。 6. 范围核实未通过的原因 范围核实未通过几乎都与当初的定义范围过程有关，可分为以下几种情况。 (1) 最初SOW不完整、理解错误。 (2) 定义范围时漏项。 (3) 制定定义范围和验收标准时未让重要利害关系者参与，也未得到利害关系者批准。 3.5.2范围核实的结果 1. 验收的可交付物 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给项目收尾管理过程。 验收通过的可交付物，双方可能需要签署范围承诺书，以便在范围变更时进行规范化管理。 2. 变更请求 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案，并提出适当的变更请求，以便进行缺陷补救。范围变更，应该交由项目整体变更控制过程管理。 3. 工作绩效信息 工作绩效信息包括项目进展信息，例如，哪些可交付成果已经开始实施，它们的进展如何，哪些可交付成果已经完成，或者哪些已经被验收。这些信息应该被记录下来并传递给干系人。 4. 项目文件更新 需要更新的项目文件包括经验教训登记册、需求文件和需求跟踪矩阵。 3.6范 围 控 制 一个软件项目的范围计划可能制订得非常好，但是想不出现任何改变几乎是不可能的，因此范围变更是不可避免的，关键问题是如何对范围变更进行有效控制。 3.6.1软件项目范围失控原因 1. 需求范围不明确 合同中规定的内容往往都是模糊不清的，需求不明确，或者只有几行说明，而且还可能有大段的套话、官话。项目参与者对客户业务不一定了解，如果对客户真正想要的需求没有真正了解，往往会导致后期无止境的修改。 2. 需求理解不一致 我们经常会遇到，按照客户书面上记录的需求进行开发后，客户却并不认可，而实际情况中，客户对自己写的书面内容也并无异议。原因是对于同样的内容，客户的理解与我们的理解不同。例如，需求中写道： “购物后付款”，开发人员开发出来的是用户选择好商品进入购物车直接付款，而客户实际想要的是到购物车付款前先向客户发送一条短信验证码，让购买人二次确认无误后再付款。同样的文字，对细节的理解可能就是不同的，但实现的细节在客户提供的需求里可能根本就没有提。 3. 有些需求并没有直接写出来 中国人喜欢儒家思想，话多为隐晦而不直白地说出，客户提的多是自己期望解决的需求，而对于最基本需求往往不说，因为他认为你就应该有。例如做一款手机，手机打电话的功能是不用说的； 再如智能面包机，做面包的功能也是不需要说的，他只会说如何智能。 4. 项目结束前客户总有提不完的需求 客户总是会在结项前提出各种需求，前期没有讨论过的各种需求都会在这个时候冒出来，让项目被动受制。这种情况的原因一般有两种，一种是在项目开发过程中没有与客户充分沟通； 另一种就是客户生怕项目一结束付款，乙方就不会再很好地支持甲方了。那么所有需求不论重要与否，都要在结束前做完。 5. 项目经理无条件迁就客户 虽然项目成功的标志是客户满意度，但无条件迁就客户最终可能导致项目预算超标或时间超期，反而会导致项目失败。客户在提一条新需求时可能自己都没有想清楚，也可能只是他的灵光一现，许多需求可能只是冗余需求。客户往往不懂程序，随便说出的需求，可能让我们付出很大的代价。 6. 沟通不顺畅 进行软件项目管理时，可能会遇到完全不懂计算机专业知识的客户，他们的许多想法根本无法实现向他解释，又很难理解，似乎我们什么都做不了。这种客户有时会让我们有一种无力感。 3.6.2范围控制的方法 项目范围控制应该建立在已有的项目文档和项目知识基础上，如项目管理计划(其中的范围管理计划、需求管理计划、变更管理计划、配置管理计划和绩效测量基准等)、项目文件(如经验教训登记册、需求文件、需求跟踪矩阵等)、工作绩效数据(如收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量)和组织过程资产。常见的范围控制方法如下。 1. 偏差分析 偏差分析又称为挣值法，是一种确定实际绩效与基准的差异程度及原因的技术。在范围控制中，可利用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。此外，根据历史偏差分析，可以对今后的范围变化趋势进行分析，趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。 2. 范围计划调整 为有效进行项目范围的变更与控制，应不断进行项目工作任务的再分解，并以此为基础，建立多个可供选择及有效的计划更新方案。 3. 范围变更控制系统 该系统由来自多方的项目干系人组成，他们在变更过程中所承担的角色各有不同，是整个项目变更控制系统的组成部分，主要包括： 控制程序、控制方法和控制责任体系； 文档记录系统； 变更跟踪监督系统； 变更请求的审批授权系统。 3.6.3项目范围变更控制 项目范围变更控制是指为使项目向着有利于项目目标实现的方向发展而变动和调整某些方面因素而引起项目范围发生变化的过程。项目范围变化及控制不是孤立的，它与项目的工期、费用和质量密切相关。因此，在进行项目范围变更控制的同时，应全面考虑对其他因素的控制。 对项目范围进行控制，就必须确保所有范围变更的请求、推荐的纠正措施或预防措施都经过项目整体变更控制程序(详见12.6节)的处理。变更不可避免，因而必须强制实施某种形式的变更控制。在变更实际发生时，也要采用范围控制过程来管理这些变更，控制范围过程需要与其他控制过程整合在一起，未得到控制的变更通常被称为项目范围蔓延。 1. 范围变更控制程序 变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。为执行变更控制，必须建立有效的范围变更流程，项目范围变更控制流程如图35所示。它对管好项目至关重要。在变更过程中要跟踪和验证，确保变更被正确执行。 图35项目范围变更控制程序 2. 范围变更的权衡因素 项目范围变更不仅涉及项目范围，而且会对项目的时间、费用、质量等因素产生影响，如图36所示。这就需要进行权衡，在确定的需求范围内，全方位满足干系人的要求。 图36范围变更的权衡因素 3. 范围变更控制的作用 项目范围变更控制的作用主要体现在以下几个方面。 1) 合理调整项目范围 范围变更是指对已经确定的、建立在已审批通过的WBS基础上的项目范围所进行的调整与变更。项目范围变更常常伴随着对成本、进度、质量或项目其他目标的调整和变更。 2) 纠偏行动 由于项目的变化所引起的项目变更偏离了计划轨迹，从而产生了偏差。为保证项目目标的顺利实现，就必须进行纠正。所以，从这个意义上来说，项目变更实际上就是一种纠偏行动。 3) 总结经验教训 导致项目范围变更的原因、所采取的纠偏行动的依据及其他任何来自变更控制实践中的经验教训，都应该形成文字、数据和资料，以作为项目组织保存的历史资料。 3.6.4软件项目范围控制的方法 对于一名项目经理来说，做出让客户满意的产品是他的终极目标。在3.6.1节中我们已经提到了可能导致需求失控的原因，下面给出几个具体可操作的解决办法。 1. 明确项目范围 项目一定要有清晰的目标、准确的方向，大海航行靠舵手，项目经理要有把握好项目范围的能力，尽量将项目需求让所有项目干系人(范围相关的所有人)知晓，尤其要得到客户的认可，必要时要让客户确认。以前经常听有的项目经理说： “需求最后一定要让客户领导签字”，这有点难度，如果你真有这个能力，能弄到客户签字，这对项目是极大的帮助。 2. 多问问为什么 对于客户每次提出的新需求，我们尽量多了解他的目的是什么，多问，多想，当我们知道客户的终极目标时，就可以主导客户需求了。同时，了解客户提出此需求的目的也有利于我们对需求的更好把握，不至于项目需求出现偏差。 3. 需求理解要一致 项目经理要对项目进行跟进和监控，需求要很好地贯彻到每个人，不要出现理解偏差。记得有一篇图文的短文，大致意思是客户想要的产品、项目经理理解的产品、设计人员设计的产品、开发人员要做成的产品、开发人员最后做出来的产品、测试人员看到的产品都不一致。每个人在信息传递过程中让需求不断出现损耗和变形。需求理解的一致性是项目成功的基础，在项目管理的各个阶段，要让所有相关人正确的了解和把握需求。 4. 要让客户参与到项目的各个阶段 项目经理要拉着客户参与到项目的各个阶段： 需求分析、总体设计、详细设计、编码、测试，要让客户参与到项目的每个阶段，并随时让客户了解和提出自己的真实想法。这样就不会导致客户在项目最后时提出各种需求。尤其是在需求分析和设计阶段，当整理完需求文档和设计文档时，一定要请客户一起参与评估，以避免需求理解不一致、需求范围不确定等问题。我们以前常提敏捷软件开发方法，敏捷开发又不至于项目出现更大问题的办法就是让客户随时参与项目的各个阶段，让客户与我们的项目管理人员一起把关。 要让客户对需求进行确认。当多次与客户确认需求后，尽量让客户签字认可，如不能签字，也尽量让客户方领导在正式场合当面确认。这样做的好处有： (1) 可以有效地控制需求，当客户再有想加的需求时总不至于那么理直气壮； (2) 如客户真要加需求时，我们可以因需求变更而提出一定的经济补偿； (3) 如果需求增加了，项目经理可以凭借签字在公司内部规避自己的责任，毕竟客户以前是认可的，这回再提增加需求，就不是项目经理能力范围了，可以请领导出面； (4) 有了客户确认的需求，项目组可以放心地去完成项目，以减少需求变更所带来的影响。 5. 做好服务，要让客户信任我们 客户之所以在项目结束前让我们尽量把所有能想到的做好，有时还提出各种刁难，就是怕我们在项目结束后就不能很好地给予支持了。对于公司和团队，我们要建立完整的服务机制，要让客户看到我们的服务。如果客户对我们公司和团队认可了，相信以后的服务过程中有了问题，我们还会及时处理，那么客户会允许我们把部分非核心需求放到将来处理。信任是一种力量，让客户信任我们就要始终如一地做好服务。 6. 做好需求变更机制 有时需求的变更是不可避免的，当发生需求变更时，我们要有一定的需求变更机制。首先要冷静看待需求的变更，与客户沟通好，要对需求变更的工作内容、工作量进行评估、因变更所产生的费用、针对需求变更提出的方案，并填写需求变更文件让客户签字，要让客户知道需求变更对项目产生的影响，对于需求的变更，客户也要承担一定的责任(时间或经济)。 7. 条条大路通罗马 对于客户提出的需求，不要一味迁就，“客户永远是对的”的思想在项目开发过程中不一定正确。项目成功的标志应该是在规定的时间内利用有效的资源完成项目并使客户满意，为了一味满足客户的需求，而使项目进度超期、预算超期都不能算成功的项目。当客户提出一个不好解决的需求时，我们只要了解客户的目的，帮助客户分析后应该可以找出其他同样能达到相应效果的方案，并让客户知道他的方案会给项目带来什么样的影响，客户最终还是会接受我们的意见，这样比与客户直接冲突要明智。 综上，项目需求的管理是一个复杂的过程，它涉及项目所有相关人的利益。有效地避免与客户的冲突，多给客户一些中肯的意见，同时也要让客户参与到项目的各个阶段，要让客户了解项目的各个过程，让客户了解我们的公司和团队，建立起信任度，在有信任的前提下做事，友好沟通，会让我们工作起来更加舒畅。 3.6.5范围控制的结果 项目范围控制通常可以得到如下几个结果。 1. 工作绩效信息 本过程产生的工作绩效信息是有关项目和产品范围实施情况(对照范围基准)的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。 2. 变更请求 分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制程序(见12.6节)的审查和处理。 3. 项目管理计划更新 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。范围变更引起的需要变更的项目管理计划组成部分如下。 (1) 范围管理计划。可以更新范围管理计划，以反映范围管理方式的变更。 (2) 范围基准。在针对范围、范围说明书、WBS或WBS词典的变更获得批准后，需要对范围基准做出相应的变更。有时范围偏差太过严重，以致需要修订范围基准，以便为绩效测量提供现实可行的依据。 (3) 进度基准。在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。有时进度偏差太过严重，以致需要修订进度基准，以便为绩效测量提供现实可行的依据。 (4) 成本基准。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以致需要修订成本基准，以便为绩效测量提供现实可行的依据。 (5) 绩效测量基准。在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。 4. 项目文件更新 本过程可能需要更新的项目文件如下。 (1) 经验教训登记册。更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。 (2) 需求文件。可以通过增加或修改需求来更新需求文件。 (3) 需求跟踪矩阵。应该随同需求文件的更新而更新需求跟踪矩阵。 3.7小结 本章介绍了软件项目产品范围、项目工作范围、需求获取的常用方法、创建WBS的分解方法、软件项目范围核实、范围控制的任务以及它与变更控制的关系等内容。 项目范围对项目的影响是决定性的，它确定了软件项目工作内容的多少，也是后续开发的依据，更是系统测试的依据。没有它，很多扯皮的事情就要发生； 没有它，系统测试都无所适从。有效的范围管理可以保证项目只做必须做的事情，避免范围蔓延和做无用功，同时也避免不清晰的需求所导致的严重的系统缺陷。 3.8案 例 研 究 案例一： 如何面对需求变更http://www.leadge.com/news_list/100592.html 小王的公司最近遇到的两个颇为有趣的项目。据小王介绍，这两个项目分别由两个项目经理负责。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给予解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。相比之下，项目经理B显得有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。 话刚一说完，小李就抢着说： “A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗?” 小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于客户的要求，应该在有限的范围内给予解决，但不可以做出太大的牺牲。一味迁就客户将会使整个项目失败。” 小林接着小王的话说： “当前，国内的项目一般情况下是由销售出面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。” 小赵反驳道： “不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，会造成做一次项目丢掉一个客户，太不划算了。” 【案例问题】 (1) 小王公司的项目经理A和项目经理B哪一个做法更好？请说明理由。 (2) 小李和小王，你更同意哪个人说的？为什么？ (3) 怎么理解小林的“一个唱白脸，一个唱红脸”？ (4) 怎样理解小赵的“顾客是上帝”，你有没有更好的对策？ 案例二： 范围管理100%原则： 苹果公司完成了99%，少了1%http://www.zpedu.org/Inforneirongye1217_114.html 大家都知道，iPhone手机给苹果公司带来了巨大的成功，可以说让其他手机制造商只能去模仿而无法去超越。但是，有些人可能不知道，在研发第一代iPhone时，苹果公司竟然出现了可能是消费电子市场上最尴尬的一个失误： 已经投入生产的iPhone手机没有电话功能！这款手机，或者已经不能称为手机，叫作最酷的手持计算设备可能更贴切一些，竟然不能打电话，着实给期待它的全球消费者开了一个大大的玩笑! 2007年年初，苹果公司宣布召回所有正在生产的iPhone手机，因为它发现这款大肆炒作的便携设备竟然漏掉了“电话”功能!苹果公司创始人史蒂夫·乔布斯在公司总部为这个荒唐的失误发表了致歉辞，脸色通红的乔布斯在与华尔街分析师召开的电话会议上说： “首先，我们表示十分的歉意。因为我们在iPhone这款产品中漏掉了电话功能。”他解释道，苹果的设计工程师们一直在琢磨那些与电话无关的功能，如照相机、MP3播放器、跟踪天线系统以及其他高级功能等。虽然乔布斯表示首批已经运送到全球各地的零售店的九百万台iPhone手机大部分已经“打道回府”，重新运回苹果的生产厂，但是他还是建议那些通过某种方式已经拿到iPhone手机的消费者“拿起iPhone手机，然后放在耳边，假装在打电话。” 现在iPhone手机已风靡全球，再听到上面这个故事可能都无法相信，但这是真的! 在研发这款革命性的手机产品时，项目团队可能太过于关注那些令人激动的额外功能，却把最基本的通话功能给遗漏了，毫无疑问的是，这个项目团队在制定项目范围时绝对忽略了这1%的功能，我想他们肯定在研发中不断地核实项目范围，却从未发现，甚至在投产的产品测试时也没有把这1%加到试验计划中，最终导致在量产时才尴尬地发现了这个致命疏忽! 【案例问题】 (1) 你怎么看苹果公司“完成了99%，少了1%”？ (2) 怎样理解范围管理的100%原则？101%行不行？ (3) 项目范围管理中的“No More，No Less(不多，不少)”，怎样才能做到？ 3.9习题和实践 1. 习题 (1) 什么是项目范围管理？主要包括哪些过程？ (2) 简述需求收集对于范围管理的影响。 (3) 创建WBS是项目范围管理中的重要过程，一个详细的工作分解结构对项目管理有哪些好处？ (4) WBS创建方法和原则是什么？ (5) 如何进行范围变更控制？ (6) 软件项目范围控制的挑战有哪些？如何应对？ 2. 实践 (1) 面对干系人不断提出的变更要求，作为项目经理如何应对？ (2) 从以下几个软件项目选择一个,创建WBS,并定义项目的初步范围说明书。  校内二手物品交易系统  图书管理系统  校园周边服务推荐系统  网上订餐服务App  学工处就业指导网站