软件项目管理 项目范围管理
项目范围管理概述
项目为管理是指对项目包括什么与不包括什么的定义与控制
这个过程用于确保项目组 项目干系人对项目结果的项目产品以及生产（开发）这些产品所用到的过程有共同的理解
灰色地带是项目的祸根
启动过程控制后，项目范围管理开始进行，其主要过程有
- 范围计划编制内容
- 范围定义（wbs）
- 范围核实
- 范围的变更控制
范围的概念包含两个方面，，一个是产品范围，及产品或服务所包含的特征或功能；另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。
在确定范围时，首先要确定最终产生的是什么它具有哪些可清晰界定的特征。
特征必须要清晰，用文字、图标或某种标准表达出来，能被项目参与人理解
定制软件的范围通常由项目目标、主要功能、性能需求（包括安全性、稳定性、准确度和响应速度方面的性质、系统接口和其他特殊要求等几个方面来说明
范围计划编制内容
- 项目范围计划是指形成正式文件，就是编写项目范围说明书（或工作约定书等）等的过程
- 项目范围计划过程的主要输入（收集和参考的资料）包括项目章程（目标）和项目概述，二其主要输出（结果）是形成书面的范围说明书
项目目标如何描述
- 目标必须符合SMART原则，明确、可信、具体和可以度量
- 在6个月内，在200万元的预算内，开发完成一套新版本的电信网络管理软件，能够将甲方的4中电信机芯的20中告警综合显示在一个web界面上，性能指标必须符合某某技术规范的要求。
范围计划编制
项目范围计划主要包括项目论证（可惜分析的简要内容）、项目产品概述7项目交付成果简述、工作或服务内容（通常是乙方或厂商、开发方）、项目成功的主要因素（可选）
项目说明书实例
- 不同项目，范围所明书长度和内容不一
- 政府项目通常会成为工作说明书
- ERP项目范围说明书（项目约定书）
范围定义
项目范围定义就是把项目的工作分为较小的、更易管理的单元
项目范围定义结果就是工作分解结构
项目的结构分解
- 结构分解的用局势wbs，他是一个分级的树形结构，是将项目按照其内在结构或实施过程的顺序进行逐层分解而形成的结构示意图
- 核心思想：化整为0
项目实施和云效过程的全生命周期管理
WBS重要性与实例
- 项目的结构分解的重要性
- wbs图是实施项目，创造最终产品或服务所必须进行的全部活动一张清单，也是进行计划、人员分配、预算计划的基础
- 没有WBS工作，后面的一切工作都没有依据
网站建设的WBS图（按产品进行组织的企业内部网项目的wbs实例）
围绕项目阶段设计的企业内部的wbs
wbs设计方法和原则
主要有类比法、自上而下法、自下而上法
- 类比法
- 是以一个类似项目的wbs模板为基础（如project中的模板）制定本项目的工作分解结构（又如SAP的例子，有成熟的方法论）
- 自上而下法
- 自上而下法常常被视为构建wbs的常规方法，即从整个项目开始，逐步将他们分解成下一级的多个子项。这个过程就是要不断的增加级数，细化工作任务
- 自下而上法
- 自下而上法是要让项目各个团队从一开始就尽可能的确定项目有关的各项具体任务，然后将各项具体任务进行整合。并归并到一个整体活动或wbs的上一级内容当中去。这种方法一般很费事，但是这种反法对于wbs的创建来说效果较好
- 工程项目中会用到，在it项目中使用较少
项目范围( )。
A、只在项目开始时重要
B、在授权项目的合同或者其他文件得以批准后就不再重要了
C、从项目概念阶段到收尾阶段都应该加以管理和控制
D、是在项目执行阶段通过变更控制步骤进行处理的问题
任务分解可以( ),它是范围变更的一项重要输入。
A、提供项目成本估算结果
B、提供项目范围基线
C、规定项目采用的过程
D、提供项目的关键路径
范围核实与变更控制
范围核实是项目干系人对项目范围的正式承认
项目组必须形成一些明确的文件（文档）说明项目产品范围
范围和时候，是项目将来进行验收的基准
一个项目范围特别大、特别广的话则会引起许多问题。范围的蔓延并且为了技术而强调技术导致了一个大型制药公司，位于得州的福克斯迈耶药业公司的破产。该公司的信息主管竭力争取一个6500万美元的系统项目用于管理公司关键的业务运作。但是，他却不主张将事情做得简单。
公司花了将近1000万美元用于配置完美的软硬件，并且把该项目的管理交给了一个著名的（并且是成本昂贵的）咨询公司去做。项目内容包括要建立一个1800万美元的自动库房，根据内部人士透漏，这有点像是从科幻电影中来的。项目的范围搞得越来越大，并且越来越不实用。这个精致的自动仓库结果没能准时完工，新系统也屡屡出错致使福克斯迈耶无法挽回的1500万美元的巨额损失。当年7月，该公司四季度就花了3400万美元。到8月，福克斯迈耶公司不得不申请破产。
保持項目範圍和用戶需求的前後一貫性是非常重要的
如果出现需要改变原定实施范围的需求，应以正式文档方式提出，项目小组成员必须谨慎考虑项目范围的改变或需求的改变将对整个项目进程可能产生的影响。必须在批准后才能进行，在实施过程中必须加以跟踪
范围变更控制
批准程序
- 提出项目变更、需求变更申请报告（申请单或申请表）
- 对于较小的范围改变，需要项目经理查阅和签字批准并内部存档，然后提交双方项目协调小组
- 凡涉及到整个项目进展，费用成本调整较大的改变，必须交由双方（甲方和乙方）项目领导小组批准通过
跟踪执行
- 需求变更申请报告签字后，开始正式执行
- 调整相应的实施计划
- 进度报告定期提交项目主管检查
希赛信息技术有限公司(CSAI原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。
【问题1】
对张工的行为进行点评？
- 张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求
- 张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。
- 张工在第一问题发生后人没有对范围进行有效的管理，造成系统的第二次变更
- 张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发
- 张工没有对设计质量进行有效地控制，造成表现层中耦合了业务逻辑，增加了修改的代价
【问题2】
请从项目范围管理的角度找出该项目实施过程中的主要管理问题？
- 张工没有挖掘到系统的全部隐形需求，缺乏精确地范围定义
- 在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的第二次变更
- 重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复
【问题3】
请结合你本人实际项目经验，指出应如何避免类似问题？
- 有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是很重要的。对于本案例，要几盒行业特点进行需求分析。挖掘系统潜在需求。同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。
- 在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更
希赛信息技术有限公司(CSAI )刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和范围。由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。张工认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%, M的业务代表也因为系统的延期表示了强烈的不满。
【问题1】
对张工在项目管理工作中的行为进行点评。
- 张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效率和质量
- 张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现
- 张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差
- 张工对需求的补鞥进行缺乏有效控制，最终造成项目延期50%
【问题2】
请从项目范围管理的角度找出该项目实施过程中的问题。
- 在范围定义中，张工没有对理工定义的需求进行评审，造成需求中的质量缺陷没有被及时发现
- 再范围确认中，张工没有主动的要求用户对需求进行确认
- 在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需求变更
【问题3】
请结合你本人项目经验，谈谈应如何避免类似的问题。
- 对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问题，对已经定义的需求需要与用户进行确认，保证双方理解的一致。在发生需求变更时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围
金源正在召集一个项目组会议，讨论一个信息技术更新项目的范围确定。这个项目是上周她的上司交给她办的。公司正在优先开发几个外因特网应用软件，该更新项目对于实施这些软件开发是必要的。该更新项目要制定并实施一个计划，让公司所有员工的信息设施在9个月内达到新的公司标准。这个标准规定了每个台式机的最低配置要求，包括处理器型号，内存大小，硬盘容量，网络接口类型，以及装载软件等。金知道要进行更新，他们必须首先为公司2000多名员工列出一个所有现有硬件、网络和软件的清单。
金用项目章程描述了项目的主要目标和主要干系人的角色和责任。章程还包括一个粗略的成本和进度估算。金召集项目组成员和其他干系人开这个会是为了进一步计划和定义项目的范围。项目会涉及哪些工作？都由谁去做？如何才能避免可能的范围蔓延？她想通过这次会议征集大家关于这些问题的看法。金的老板建议项目组的第一步工作应该是建立一个WBS以清晰地定义更新项目会涉及的所有工作。但金并不清楚怎样着手建立WBS。她以前是用过，但这次她是项目经理，她还是第一次领导项目组来建立WBS。
在这个浓郁信息技术更新项目的会议上，金源首先让大家审阅项目的章程。参加会议的人共有12人。代表了主要地项目感谢人。在看完章程之后，金直接就让大家提问，所有的问题他都胸有成竹，对答如流。然后，金就直言这次会议的目的就是要准备开始进行项目的范围计划和工作确定
他向与会者询问是否有人具有撰写范围说明书与制定工作分解结构的经验，有几个人举起了手，他们是伊冯。伊冯来自市场部（改部门是公司内该项目最大的用户之一）
他在政府部门工作过6年，对范围说明书和WBS都非常熟悉。金向伊冯询问了政府项目中这些文件的类型和用法。金将伊冯的谈话总结成一个活动图，她的一个同事做了会议记录。
比尔是信息技术运营部的一个主管经理，讲述了前几年他在其他一些公司类似的信息技术更新项目中的经验。会议继续进行着，大家对项目范围管理内容都有一个更好的了解。
思考题：本案例中涉及项目管理的知识点包括哪些？