本文以我作为项目承担单位项目经理负责开发的某“某某铁路软件过程管理平台”项目为例，论述了项目范围管理在信息系统项目中的重要性。项目范围管理是项目管理中一项至关重要的管理工作，范围管理包括收集需求、定义范围、制订WBS、范围核实、范围控制等过程。本文首先概述了项目背景，其次介绍我在本项目范围管理各个过程中面临的困难、应对措施以及部分心得。在本项目中，我通过培训、现场调研、加强干系人识别、采用原型法等方法完成了需求收集与范围定义工作；通过细化需求说明书、利用类比经验、细化WBS词典等方式确保了WBS的顺利制订；通过持续交付、阶段性评审、正式书面记录等手段完成了范围核实；通过建立CCB及变更控制流程、制订项目范围管理计划中变更相关规定的方法完成了范围的控制。最后对本项目在范围管理中的经验教训进行了总结。本项目由于管理措施得当，按时完成并顺利通过验收。

2008年底，国家某部委组织多家科研院所、院校、企业启动了某“高速列车网络控制系统”国家科技支撑计划重点课题（以下简称“高铁课题”）。

为了对高铁课题提供高可用、高可信、高可靠性的软件过程管理支持与服务，“某面向高铁的软件过程管理平台”项目于2008年底正式启动，项目预算为500万元人民币，项目工期为一年。该项目目标是从项目管理及质量保障的角度考虑，借鉴国外高铁行业公司的过程管理经验，引进ISO9000、CMMI、IRIS、PMBOK等管理体系、思想与方法，自主研发面向高铁的软件过程管理平台，从而保证复杂系统环境下的软件质量，建设符合高铁项目特点的过程体系。该软件过程管理平台主要采用B/S和C/S的混合架构，使用Java、JSP、js等开发语言，以及Struts、Hibernate以及Ajax等开发技术。主要功能为系统管理、项目管理、过程资产管理、度量分析管理、需求管理、高铁故障管理等。

由于具备比较扎实的技术基础、比较丰富的项目管理工作经验以及项目管理系统知识（PMP和PMI会员），我有幸担任面向高铁的软件过程管理平台的项目经理，负责整个项目的核心研发与统筹管理工作。

项目范围管理是项目管理中至关重要的管理知识领域，项目范围包括项目的最终产品或服务以及实现该产品或服务所需的各项具体工作。项目范围管理主要包括收集需求、范围定义、制订WBS、范围核实、范围控制等过程。下面在本项目的范围管理各个过程中，我主要做了以下工作：

1.       收集需求与定义范围

软件的范围直接与需求相关，需求收集和分析的不到位导致项目执行过程中范围不断“蔓延”是信息系统项目失败最常见的原因之一。因此明确项目需求，做好项目范围定义，确认项目该做的工作，使项目范围清晰化是项目管理中至关重要的一项工作。

我在接手本项目之后，经过认真分析，总结了该项目在需求分析过程中有以下两大特点：

（1）课题复杂

本项目作为面向高铁课题的软件过程管理平台，需要充分考虑高铁课题的一些特点，概括总结起来就是“大”、“多”、“难”：课题规模大、战略目标意义重大、预算金额大；课题组成项目多、承担单位多、参与人员多、通信路径多、硬件设备与平台数量多、开发环境与运行环境种类多；由于国外技术垄断、行业技术基础薄弱、外部技术资料获取难、高铁控制逻辑调研与理解难、可靠性保证与控制难等等。

（2）专业障碍

俗话说，“隔行如隔山”，在信息系统开发项目中经常遇到这类问题。就本项目来说，我们需要高铁行业、项目管理专业、软件行业三方面的知识，从而将高铁软件功能需求、项目管理业务逻辑与软件开发技术实现三者结合起来，而实际上通常是铁路用户不懂软件、软件开发团队不懂铁路、这两方都懂一些项目管理知识，但不够精深。

针对以上两大特点，我在需求收集与范围定义阶段采取了以下几点措施：

（1）为了减少沟通沟通语义障碍，提高需求分析速度和准确率，我首先组织了高铁、软件、项目管理等三方面的专家对项目团队进行了集中培训，从而使项目团队能够在短时间内熟悉高铁软件业务特点和行业术语，在需求分析中能够与客户在同一个维度和语境下顺畅地进行沟通。另外，我安排项目团队进行列车主机厂现场调研，做好了需求分析之前的准备工作。

（2）为了减少需求遗漏的可能性，我着重加强了识别干系人的工作，并召集用户各方面代表、课题各参加单位专家代表、以及其他重要的干系人进行了多次的、逐渐细化的需求分析讨论会，不断明晰用户模糊的需求、挖掘和引导用户的潜在需求，从而使项目范围边界不断清晰。

（3）我安排需求分析工程师使用Rational Rose画用例图，将分析的需求形成需求说明书和需求跟踪矩阵，在功能性需求与非功能性需求上周期性地向用户确认，以保证项目团队与用户在需求理解上达成一致。最后，将已定义的需求整理为项目范围说明书，形成阶段重要可交付物。

（4）由于用户在UI、性能、易用性、兼容性等需求方面缺乏了解，这部分需求往往无法在初期确定，因此本项目在开发中采用了原型法，以降低范围定义不完全的风险，减少相应损失。

2.       创建WBS。

WBS是进度规划、成本规划等项目管理过程的重要输入，WBS的精度和粒度决定了项目进度和成本规划的准确率，因此，创建WBS是项目管理过程中非常重要的一环。

在创建WBS过程中，我个人认为最重要的因素有两点：

（1）范围说明书的清晰度与完整度。

WBS的建立依赖于成功的需求分析与清晰的范围定义，在本项目的实际操作中，我们是将需求文件做细，将整个过程管理平台分为50个功能模块，每个功能模块分别具有多个子功能，这样需求文件本身便是一个三级的WBS雏形，WBS的分解也相对容易。

（2）WBS分解粒度。

WBS分解粒度的确定是对项目经理的考验。在本项目中，由于我曾经有过类似软件过程平台的开发经验，将WBS分解为三级编码结构，最底层工作包平均为16个人时（两个人日）。

（3）WBS词典的详细程度。

WBS作为项目的重要文档，可以说是项目开发整个过程的工作手册，WBS的词典越详细，项目干系人尤其是团队成员对于工作包的理解就越趋于一致而减少理解偏差。在以往的项目中，我经常见到WBS词典非常粗略甚至缺失带来的许多麻烦，因此，在本项目中，我对WBS词典亲自审核并在定稿后专门开会发布。事实证明，这一举措十分有效。

3.       范围确认。

范围确认是项目干系人正式接受已完成的项目范围的过程，范围确认需要审查可交付物和工作成果，以保证项目中所有工作都能正确满意地完成。

在本项目中，由于采用了原型法、不断迭代、持续性交付阶段性成果的开发方法，因此范围确认贯穿整个项目始终。在WBS制订后，我确定了多个重要里程碑，每个里程碑是一个重要时间节点，我邀请相关干系人参加阶段评审会。评审过程中的偏差和问题都会被记录并马上投入TO DO LIST进行解决，评审过程产生的意见都会形成评审意见表并请代表签字以形成正式书面记录。

4.       范围控制。

根据我的经验，范围是最可能变更的基线，范围变更也是最常见的变更。一般来说，范围变更源自于用户的前期需求未正确识别或用户中后期新增需求，少数情况下也会出现项目团队内部的范围蔓延，也就是镀金。

在本项目中，为了减少范围变更频度和降低相应不利影响，我做了以下工作：

（1）建立变更控制委员会（CCB）与变更控制流程。保证包括范围变更在内的项目变更在CCB的控制和变更控制流程的约束下统一进行。

（2）在范围管理计划中对范围变更控制进行规定。尽量在满足用户需求的前提下缩小范围变更的幅度，降低不利影响，避免理解不一致带来的重复变更，杜绝镀金。

由于过程管理得当，本项目于2009年11月完成外包测试合同验收、内部预验收与审计，于2009年12月上线开始试运行。经历了3个月的试运行后，修复了实际使用过程中发现的Bug并对系统进行了完善，最终于2010年3月顺利完成了项目验收。

本项目在范围管理方面总体比较顺利，但也有一些问题，例如在制订WBS时，由于对高铁故障管理模块工作量估计过于乐观，导致估计值不准确，与实际值偏差较大，造成了几天的工期延误，在通过赶工等手段及时修正了偏差之后，问题才得以解决。在干系人管理中，由于没有识别出知识产权管理员也是项目干系人之一，导致在前期需求分析中出现了遗漏，直到第一次阶段评审时才由专家发现并及时弥补。这些问题在以后的项目中会加以改进。

该论文由信管考友提供，感谢分享