论信息系统项目的范围管理

【摘要】

2019年7月，我作为项目经理参与了某证券公司日志分析平台的建设，该项目投资共740万元人民币，项目组织结构为项目型，建设工期为10个月。

2019年3月，证标委秘书处向各委员单位征求《证券期货机构内部应用系统日志规范》立项意见，该文件规定了证券期货业内部应用系统日志的记录、存储、采集、监控、销毁等相关要求。通过该项目的建设，某证券公司实现了对主营业务的日志集中管理，促进了公司运营效率和管理水平提升。该项目于2020年5月底验收，合计纳管通达信、同花顺等50多个业务系统，得到客户和公司管理层的一致认可。本人结合实际项目经历，以该项目背景为例，讨论了范围管理在信息系统项目管理过程中的重要作用，主要从规划范围管理，收集需求，定义范围，创建wbs，确认范围和控制范围几个方面予以阐述。

【正文】

2019年之前，证券行业内部一直没有一个统一的日志管理规范，各证券公司内部日志管理标准不一，给审计工作带来很多困难。2019年3月，证标委秘书处向各委员单位征求《证券期货机构内部应用系统日志规范》立项意见，意见中对证券行业从业机构的应用系统日志管理、日志记录、日志存储、日志采集、日志监控、日志审计和日志销毁作出相关要求。某证券公司根据上述立项意见草案的相关要求，启动日志建设平台项目，我司在6月1日顺利中标，并按照合同要求，在2019年7月1日正式启动该项目。

该系统以elk为核心，以kafka作为消息队列，以jstorm作为流处理工具，以hbase为持久存储器，按照合同要求，it基础设备和应用日志、安全级别中或低的应用系统日志，数据存储周期为12月，应保证1月之内的数据可随时查看，安全级别高的应用系统日志，数据存储周期为36月，应保证3个月之内的数据可随时查看，所有数据要求实时入库和实时告警。系统功能涵盖了日志采集、日志存储、日志查询、日志监控与告警、日志应用场景统计、日志权限隔离、日志审计功能，涉及到50个应用系统和500台主机。

项目自启动以来，经历了需求分析、架构设计、详细设计、开发、测试、实施、验收等几个阶段，在项目整体建设的过程中，因为涉及到日志采集、解析、校验等实施工作，我对范围管理特别重视，从规划范围管理、编制范围管理计划、范围定义、创建工作分解结构、范围确认、范围控制这几个过程有计划、有步骤的实施管理，把控项目进度，保质保量的完成项目交付，并因为客户满意度高，获得了公司内部“明星团队”的嘉奖。

1，规划范围管理并编制范围管理计划

俗话说得好，要着眼于那最初的一小步，科学的范围管理计划是项目成功的一半。

从项目一开始，我就以项目章程为依据，组织项目团队成员整理业务系统日志信息，请业务专家规划部署架构，请大数据专家提供数据接入方案，统计项目干系人信息，并让相关干系人参与到信息收集、资源申请、公共组件管理等工作中，获取干系人对工作的认可。我借鉴以往类似项目的范围管理计划的模板，详细描述了需求管理、范围管理的工作方法，为后续工作展开提供了书面的指导。

2，收集需求并定义范围

范围定义是为实现项目目标而必须完成的工作，并且往往与需求有关，需求的“蔓延”是项目失败最常见的原因之一。

在本项目中，为了避免需求遗漏和需求多次变更，在定义范围之初，我多次召集项目干系人展开需求讨论，围绕着项目章程和证标委秘书处秘书处的意见要求，确认项目边界，围绕着业务信息，确认实施工作范围。在需求清晰之后，我安排需求分析工程师在功能性需求与非功能性需求上周期性地向用户确认，并建立需求跟踪矩阵，以保证项目团队与用户在需求理解上达成一致。

在上述需求确认后，为进一步确保需求分析工作的准确性，保证需求实现，我召集公司业务专家和大数据专家评审需求文档，评审过程中发现，系统之间带宽受限，无法满足大数据量传输的性能要求，硬件资源磁盘阵列错误，无法满足大数据查询的性能要求，经过及时与干系人沟通，修正了磁盘阵列，扩充了系统间带宽，满足了需求实现的条件。

最后，我将已定义的需求整理为项目范围说明书，形成阶段重要可交付物，并将项目范围说明书递交给项目干系人和公司管理层。

3，创建工作分解结构

工作分解结构 wbs 是管理项目工作的主要依据和基础。wbs 的精度和粒度决定了项目进度和成本规划的准确率，因此，在创建 wbs 过程中，我个人认为最重要的因素有三点：范围说明书的清晰度和完整度、wbs分解粒度、wbs字典的详细程度。

在本项目中，我是将需求文件做细，将整个日志分析平台分为日志接入管理、传输通道管理、日志格式校验、日志入库任务管理、日志查询、日志场景分析、告警中心、概览等功能模块，每个功能模块分别具有多个子功能，项目边界清晰，需求文件本身便是一个三级的 wbs 雏形。在本项目中，我将 wbs 分解为三级编码结构，最底层工作包平均为 5人天（以周为单位）。wbs 字典是项目的重要文档，粗略的wbs字典会给项目工作带来许多麻烦，

在本项目中，我细化wbs字典内容，亲自审核，并在定稿后召集项目干系人和项目团队成员举行wbs字典发布会，就工作包的理解达成一致，减少理解偏差。事实证明，这一举措十分有效。

4. 范围确认

范围确认是项目干系人正式接受已完成的项目范围的过程，这个工作贯穿了整个项目。

在本项目中，wbs 制订后，我确定了多个重要里程碑，每个里程碑是一个重要时间节点，我邀请相关干系人参加阶段评审会，审查可交付物和工作成果。由于本项目采用了原型法、不断迭代的开发方法，在阶段评审过程中，项目的偏差和问题都会被记录并马上投入待办事项清单进行解决，在下一个迭代周期进行优化，评审过程产生的意见都会形成评审意见表，相关与会人签字，形成正式书面记录。

5. 范围控制

范围是最可能变更的基线，范围变更也是最常见的变更。在项目执行过程中，范围控制的意义在于确保所有变更请求和变更动作都要通过整体变更控制过程来处理。

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

在本项目中，为了减少范围变更频度和降低相应不利影响，首先，我建立了变更控制委员会（ccb），参与人有公司高层、我（pm）、客户重要干系人，涉及项目基线的重大变更必须经我书面确认后，上报变更控制委员会审批，变更控制委员会同意后方可实施，其他一般变更由我审批;其次，我在范围管理计划中对变更控制流程做了明确规定，并制定了变更控制流程图，所有变更动作均需要按照变更控制流程来处理，严禁开发、实施人员私自变更。

【结尾语】

综上所述，遵照上述范围管理的相关工作执行，我准时完成了项目交付。在本项目范围管理方面总体比较顺利，但也出现一些问题，例如在创建 wbs 时工作量估计过于乐观，导致部分里程碑交付时间点延误，在数据接入环节，因存在部分业务下架或新增节点，业务对接范围出现调整，最后不得不采取赶工、并行的措施加快项目进度。这些问题在以后的项目中我会加以改进。纵观项目的全过程，做好项目范围管理是本次项目成功的重要保证，也让我由范围管理理论到实际应用有了更加深入的理解，为应对未来更加复杂的项目积累了宝贵经验。