2015年3月，我参与了某公司网管支撑系统一体化支撑服务的集成共享平台项目的建设。本项目属于工具平台级的应用，服务器为虚拟机，数据库为oracle，操作系统为Redhat。项目大量接口采用WebService方式，为解决系统间的耦合性问题，平台本身高度开放，采用标准协议如SOAP1.1等，采用松耦合的集成架构，系统间通过总线交互，消除蜘蛛网。本项目采用矩阵型组织结构，从各职能部门抽调主干人员，组成专门的项目团队。根据需求，本项目人力资源配置为：1名项目经理，8名程序开发工程师（4名高级，2名中级，2名初级），3名测试人员，1名QA，1名配置管理人员。该集成共享平台项目主要实现以下功能模块：消息处理引擎，服务接入网关，接口能力池，接入适配，服务治理，服务质量。该项目还提供了三种安全机制：用户请求服务时的用户身份识别；服务提供开表加载动态访问控制；个别服务实现基于证书的信任传递。由于本项目的顺利上线涉及到各系统间的互操作和共享服务，涉及的项目干系人较多，因此，在本项目中，范围管理尤为重要。在本项目中，我作为项目经理，对于范围管理，主要做好了以下几点工作。
一、制定范围管理计划
在本项目中，我特别重视范围管理计划的编制。范围管理计划的编制，需要合理、有效的根据，因此，在正式编制计划前，我通过已有的组织过程资产，找出了制定范围管理计划的模板，根据项目合同、建设单位独特的环境因素，再结合以往的项目经验，制定出了一份初步的管理计划。计划制定后召集所有相关干系人，在全员参与下，通过讨论修改，制定了一份相对科学、详细的范围管理计划。
二、范围定义
定义详尽的项目范围说明书对于项目的成功是至关重要的。为了实现这一点，在项目的早期阶段，我带领我的团队到了客户现场收集需求，确定产品范围和项目范围。负责网管系统的网管中心员工大都具备一定的开发能力，又对建设单位所属领域的业务特别熟悉，所以他们对需求的描述相对清晰、透彻，但其他系统所属的业务部门的员工就难于沟通了。比如负责客服中心系统的客户，他们无法明确他们究竟想要实现什么功能，也不清楚要处理的业务数据的来源，因此，在彼此的沟通上很难有一个透彻的理解。基于这种情况，我与甲方领导进行了沟通，提出了用户参与全过程开发的开发原则，让网管中心的员工全程参与开发。这些员工既以甲方代表身份出现（可监控项目的状态和进展），又因成为了真正的开发人员，这样他们不但能学到一些基本的技术和维护方法，等我们撤退后，一些不难的操作就可自己做或自己开发。甲方领导非常认可这一举措。有了网管中心员工的参与，与其他业务系统用户的交流变得简单起来。基于需求文件，我们团队召集项目的主要干系人进行了开会讨论，同时邀请了各系统的最终用户代表对系统功能做出了评价。从他们的角度出发，发现并改进了系统的功能，最终形成了完整的项目范围说明书。
三、创建工作分解结构
通过工作分解结构，把项目范围分解开来，使项目相关人员对项目一目了然，都能通过WBS，把握项目、了解项目过程。工作分解结构还便于责任的划分和落实。因此，基于项目范围说明书，我们团队采用列表型结构开始对项目范围进行分解。在分解前，我通过组织过程资产，找出了WBS模板和WBS中工作包的格式模板，在按照滚动波式计划进行分解的同时，我们团队严格遵守创建WBS的八大原则。如参照8/80原则细化具体的工作包，在“粗”与“细”之间进行权衡，严格控制每个工作包的大小。对于每个工作包，都指定唯一的负责人和其负责的工作内容。
四、范围确认
范围确认贯穿项目的始终。我们要根据项目工作的进展，不断与甲方进行范围确认，完成阶段性验收。范围确认通常通过“检查”来实现。在我们开发完消息处理引擎功能模块，找相关负责人进行确认的时候，客户表示自己不熟悉不了解，无法确认。针对这种情况，我们请全程参与开发的网管中心员工出面，用他们的声音去向其他系统主管部门作出介绍。这样的桥梁作用，既有益于网络中心员工的学习（对他们进行沟通培训），也有益于各业务部门对范围的认可和信任。当然，还是有个别部门对项目质量信心不足，怕承担责任，怕以后使用不便，因此不愿签字。针对这种情况，我们给客户做出了承诺：虽然范围确认是正式的，但不意味着不能再修改了。
五、范围确认
范围确认不是一经定义就一成不变的，项目干系人根据业务需求，总会有一些需求变更。为确保对范围的有效控制，我定期召开状态审查会，通过对照范围基准，进行偏差分析，严格杜绝范围蔓延。如在一次阶段评审会上，我发现某开发人员的功能介绍中多了一个“增加综资订单接口”的功能，但合同和需求里都没有，也没有相关变更记录。仔细询问得知因业务需求，各系统需共享处理综资订单，于是直接跟开发人员提出了这个要求。针对这种情况，我专门开会强调了变更控制的重要性，要求相关人员提交正式变更申请，走正常变更控制流程，一定要进行分析、审核、批准才可以实施，不能擅自改动。
经过我们团队不懈的努力，历时8个月，本项目终于于2015年10月通过了建设单位组织的验收，为该公司各系统间的互操作和能力共享提供了基础平台，实现了系统间能力共享时所要求的每次交易时间在3秒内，70%在1秒内的性能要求。本项目的成功，与有效的范围管理是分不开的。当然，本项目还存在一些不足之处，比如：在本项目的实施过程中，由于项目组1名成员因为自身突然离职，导致项目团队建设出现了一些小问题，还有，项目团队成员反映团队建设活动的开展不够丰富多彩……不过，这些都是小问题，经过我们团队的纠偏，这些对我们的项目并没有产生太大影响。同量，由于系统的特殊性，牵扯到多个系统的集成，服务的规范实施得不到有效监管，这些问题都有待进一步总结与完善。通过本项目的建设，我将认真总结该项目的成功与不足之处，在后续的学习和工作中，不断努力的提升自己的管理能力和管理水平。
