集成共享平台项目的范围管理

第第页集成共享平台项目的范围管理一、制定范围管理打算

在本项目中，我特殊重视范围管理打算的编制。范围管理打算的编制，需要合理、有效的依据，因此，在正式编制打算前，我通过已有的组织过程资产，找出了制定范围管理打算的模板，依据项目合同、建设单位独特的环境因素，再结合以往的项目阅历，制定出了一份初步的管理打算。打算制定后召集全部相关干系人，在全员参加下，通过商量修改，制定了一份相对科学、具体的范围管理打算。

二、范围定义

定义详尽的项目范围说明书对于项目的胜利是至关重要的。为了实现这一点，在项目的早期阶段，我带着我的团队到了客户现场收集需求，确定产品范围和项目范围。负责网管系统的网管中心员工大都具备肯定的开发力量，又对建设单位所属领域的业务特殊熟识，所以他们对需求的描述相对清楚、透彻，但其他系统所属的业务部门的员工就难于沟通了。比方负责客服中心系统的客户，他们无法明确他们到底想要实现什么功能，也不清晰要处理的业务数据的来源，因此，在彼此的沟通上很难有一个透彻的理解。基于这种状况，我与甲方领导进行了沟通，提出了用户参加全过程开发的开发原则，让网管中心的员工全程参加开发。这些员工既以甲方代表身份消失〔可监控项目的状态和进展〕，又因成为了真正的开发人员，这样他们不但能学到一些基本的技术和维护方法，等我们撤退后，一些不难的操作就可自己做或自己开发。甲方领导特别认可这一举措。有了网管中心员工的参加，与其他业务系统用户的沟通变得简洁起来。基于需求文件，我们团队召集项目的主要干系人进行了开会商量，同时邀请了各系统的最终用户代表对系统功能做出了评价。从他们的角度动身，发觉并改良了系统的功能，最终形成了完好的项目范围说明书。

三、创建工作分解结构

通过工作分解结构，把项目范围分解开来，使项目相关人员对项目一目了然，都能通过WBS，把握项目、了解项目过程。工作分解结构还便于责任的划分和落实。因此，基于项目范围说明书，我们团队采纳列表型结构开头对项目范围进行分解。在分解前，我通过组织过程资产，找出了WBS模板和WBS中工作包的格式模板，在根据滚动波式打算进行分解的同时，我们团队严格遵守创建WBS的八大原则。如参照8/80原则细化详细的工作包，在“粗”与“细”之间进行权衡，严格掌握每个工作包的大小。对于每个工作包，都指定唯一的负责人和其负责的工作内容。

四、范围确认

范围确认贯穿项目的始终。我们要依据项目工作的进展，不断与甲方进行范围确认，完成阶段性验收。范围确认通常通过“检查”来实现。在我们开发完消息处理引擎功能模块，找相关负责人进行确认的时候，客户表示自己不熟识不了解，无法确认。针对这种状况，我们请全程参加开发的网管中心员工出面，用他们的声音去向其他系统主管部门作出介绍。这样的桥梁作用，既有益于网络中心员工的学习〔对他们进行沟通培训〕，也有益于各业务部门对范围的认可和信任。当然，还是有个别部门对项目质量信念缺乏，怕承当责任，怕以后使用不便，因此不愿签字。针对这种状况，我们给客户做出了承诺：虽然范围确认是正式的，但不意味着不能再修改了。

五、范围确认

范围确认不是一经定义就一成不变的，项目干系人依据业务需求，总会有一些需求变更。为确保对范围的有效掌握，我定期召开状态审查会，通过对比范围基准，进行偏差分析，严格杜绝范围扩散。如在一次阶段评审会上，我发觉某开发人员的功能介绍中多了一个“增加综资订单接口”的功能，但合同和需求里都没有，也没有相关变更记录。认真询问得知因业务需求，各系统需共享处理综资订单，于是直接跟开发人员提出了这个要求。针对这种状况，我特地开会强调了变更掌握的重要性，要求相关人员提交正式变更申请，走正常变更掌握流程，肯定要进行分析、审核、批准才可以实施，不能擅自改动。

经过我们团队不懈的`努力，历时8个月，本项目最终于2022年10月通过了建设单位组织的验收，为该公司各系统间的互操作和力量共享供应了基础平台，实现了系统间力量共享时所要求的每次交易时间在3秒内，70%在1秒内的性能要求。本项目的胜利，与有效的范围管理是分不开的。当然，本项目还存在一些缺乏之处，比方：在本项目的实施过程中，由于项目组1名成员由于自身突然离职，导致项目团队建设消失了一些小问题，还有，项目团队成员反映团队建设活动的开展不够丰富多彩……不过，这些都是小问题，经过我们团队的纠偏，这些对我们的项目并没有产生太大影响。同量，由于系统的特别性，