项目（Explore）总结之项目范围管理

§1.3  项目范围管理

项目范围管理是确保项目成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。

在该项目中，范围是指为提供具有规定特征与功能的产品、服务或成果而需要完成的工作。

§1.3.1                  范围规划

范围规划是确定范围管理决策的过程，以项目范围管理计划作为决策的载体，包括如何确定项目范围、制定详细的项目范围说明书、确定与制作工作分解结构、核实项目范围以及控制项目范围。

Explorer项目没有正式的项目范围管理计划，但有一些不成文的做法：

1.      确定项目范围：产品范围以三方签字盖章确认的需求说明书确定，包括业务需求说明书和系统规格说明书（主要是界面和功能确认）；

2.      制定详细的项目范围说明书：项目范围说明书的载体为业务需求说明书和系统规格需求说明书。对于每一子系统，制作的过程包括业务需求调研、调研问题讨论和确认，需求说明书编写，需求说明书讨论和确认，往往需要多轮的讨论和确认；

3.      确定与制作WBS：没有专门的文档记载WBS，粗略的把业务需求说明书的每一个功能对应WBS的一个条目；

4.      核实项目范围：没有核实的概念和过程，客户测试通过，系统上线，视为核实的过程；

5.      项目范围控制：以签字确认后的需求说明书作为基线，如需变更，需书面提出，三方签字确认后才予以实施。

§1.3.2                  范围定义

范围定义是根据在项目启动阶段所收集的信息基础上形成项目范围说明书。

Explorer项目没有正式的项目范围说明书，项目范围的主要依据仍然是招标文件，不过，在客户项目组之间都有一个不成文的范围约定，那就是X1-X6等6个子系统，可惜的是一直没有以书面的形式予以明确。除此之外，纲要性的信息，如项目目标，项目要求说明书（根据干系人分析而得）、项目边界、产品验收原则没有说明，项目的初步组织结构（如甲乙双方的PM、项目组成员）没有明确，项目进度和费用上的要求和影响因素如进度里程碑、资金要求、项目的假设和制约因素、初步确定的风险等亦没有说明。

§1.3.3                  制作工作分解结构

工作分解结构以可交付成果为对象，将应由项目组为实现项目目标并创造必要的可交付成果而执行的工作分解之后的一种层次结构。

你没猜错，Explorer项目亦没有正式工作分解结构文档，正如之前所述，项目以业务需求说明书作为项目的WBS。由于X1-X6系统在开始时客户没有提出相关的需求，范围不太清晰，每一子系统的业务需求说明书是在启动该子系统开发时才开始编写的，理论上来说是使用“滚动式”的规划方式。WBS的粒度控制在“菜单”级，亦即，业务需求说明书的每一个功能模块基本都可以对应到系统中的某个菜单上。另外，业务需求说明书中的对每一功能模块的说明可以“牵强”的对应到工作分解结构的词汇表上。

业务需求说明书经签字确认后即纳入基线管理。

§1.3.4                  范围核实

范围核实是项目利害关系者对已完成的项目范围与可交付成果正式验收的过程。

每一个子系统试运行上线前，都有一个客户验收测试的过程，可以视为对可交付成果—子系统—的验收过程。客户验收测试分为两个阶段，第一个阶段是客户测试阶段，由项目组配合客户对可交付成果进行测试，核实是否满足业务要求和性能要求，这个阶段一般需反复回归进行几次；第一阶段结束后，即可进入第二个阶段，即验收评审阶段，这时候一般由PM与客户初步确定上线时间和三方验收测试评审，由客户信息部门负责知会客户代表、监理，同时组织正式的验收测试评审会议。评审会议上，主要由项目组负责演示系统操作，由客户代表和监理对照需求说明书，核实系统的功能完备性，确定是否可以通过验收测试。

在系统演示的同时，客户代表和监理可能会提出意见和建议，属于系统Bug的，进入bug跟踪系统；属于系统变更的，则要求书面提出变更申请，经三方签字确认后予以实施。

验收测试通过，由三方签署系统验收测试报告，以此说明系统已具备条件，可上线试运行。

§1.3.5                  范围控制

范围控制是对造成项目范围变更的因素施加影响并控制这些变更造成的后果。

之前也提到过，以签字确认的业务需求说明书作为基线，在范围出现变更时，需书面提出申请，经三方签字确认后才予以实施。范围变更提出后，项目组和客户信息部门会对变更作评估和影响分析，一般有以下几种结果和处理方法：

1.      接纳建议：三方签字确认予以实施；

2.      接纳建议，但采用替代的方案：与业务部门沟通，如不能达成一致，双方意见无法统一，提交到上层处理；

3.      需求不清，需进一步分析：要求业务部门完善需求，直至可评估为止；

4.      不接纳建议：给出不采纳的理由，反馈给业务部门；如不能达成一致，双方意见无法统一，提交到上层处理。

以上各项处理的结果均归档到项目的SVN中，如涉及需求变更的，更新需求基线。正常来说，范围的变更很可能会影响到项目进度计划，但可惜计划自制定后就扔在一边了。

-------------------------- 本文可任意转载，但请注明作者和出处 ----------------------------

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-630672/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6906/viewspace-630672/