410_湘中某经济开发区能源管控中心系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

论湘中某经济开发区能源管控中心系统信息系统项目的范围管理

2022 年 9 月，我作为项目经理，负责湘中某经济开发区能源管控中心系统的全面建设。该项目由该制造集团信息化管理部牵头，目标是把园区内水、电、气、热及光伏等各类能源数据统一接入管控中心，实现能耗实时监测、能效分析与碳排放在线核算，支撑园区绿色低碳运营。项目周期 13 个月，合同额 1180.12 万元，团队 16 人，技术栈采用服务网格 Istio、多活容灾架构、GaussDB 与分布式缓存。项目有三个突出难点：一是项目周期紧、法定验收时点刚性，进度压缩明显；二是存量老系统接口文档缺失，改造边界难以厘清；三是并发访问峰值集中在办理高峰时段，性能压力大。项目上线后，数据自动核验比例由 42% 提升至 91%，线上办理率由 51% 提升至 93%，系统可用率稳定在 99.9% 以上、全年重大故障 0 起。

一、前期收集需求与定义范围，从源头锚定边界
在项目的启动与规划阶段，需要把干系人的零散诉求转化为清晰、可验证的范围描述，这一工作被称为收集需求与定义范围。园区涉及能源、安环、运维、财务等多部门，初轮共收到 53 条需求，口径差异极大。为理清脉络，我先用直方图对各业务条线的需求频次做分布统计，直观呈现 " 能耗监测 "" 告警联动 " 两类需求高度集中；再用亲和图把 53 条需求按业务域聚类为 6 个主题包，剔除 7 条与能源管控无关的诉求，形成需求全景。随后我组织核心干系人评审，将聚类结果写入范围说明书，明确 " 哪些做、哪些不做 "，使后续争议有了统一依据，避免了范围从起点就失控。

二、中期创建 WBS 与确认范围，把边界织成可执行网络
在项目的执行与监控阶段，需要把获批的范围逐层分解为可交付、可分配、可验收的工作包，这一工作被称为创建 WBS；而定期核对实际交付物与范围基准是否一致，则被称为确认范围。考虑到老系统接口文档缺失，我在 WBS 分解时对 " 数据采集接入 " 单独设层，把边界不清的接口列为高风险工作包并标注待验证假设。为建立需求到交付的双向可追溯，我运用面向 X 设计矩阵，将每条核心需求映射到对应功能模块、测试用例与验收准则，任何一条需求的增删都能立刻定位影响面。中期我每两周组织一次范围确认会，对照矩阵核对已完成工作包，及时把偏差摆在桌面上，使范围始终与基准对齐。

三、后期控制范围与验收移交，守住交付底线
在项目的收尾阶段，需要监督范围状态、管理变更以防蔓延，并对照范围基准完成正式验收，这一工作被称为控制范围与确认最终交付。进入试运行后，某部门提出新增 " 碳排放因子自定义 " 功能，我先用面向 X 设计矩阵核查其影响面，发现将牵动数据模型与报表引擎，属重大范围变更，遂提交 CCB 按受控流程评估，最终以迭代方式纳入二期而非当期范围，守住了验收时点。验收阶段我组织干系人逐工作包核对交付物，确认全部范围内功能上线、性能指标达标，范围说明书 100% 闭合。正是 " 前期用直方图与亲和图理清边界、中期用 WBS 与面向 X 设计矩阵织网、后期严控变更 " 的范围管理，让我在 13 个月刚性周期里既满足了能源管控的核心诉求，又未陷入无休止的需求拉锯。

四、以成效检验范围管理成色，沉淀边界治理心得
项目于 2023 年 10 月顺利通过竣工验收，能源管控中心系统上线后运行平稳，数据自动核验比例由 42% 提升至 91%，线上办理率由 51% 提升至 93%，系统可用率稳定在 99.9% 以上、全年重大故障 0 起。回望全程，我最深的体会是：范围管理不是把需求 " 记下来 "，而是把边界 " 管起来 "。前期用直方图看清需求分布、用亲和图聚类主题，让范围从一团乱麻变为清晰拼图；中期用 WBS 把拼图拆成可执行的工包，用面向 X 设计矩阵建立需求到交付的双向追溯，让任何变更都能立刻看清影响面；后期严控变更、逐项验收，守住了 13 个月刚性周期里的交付底线。对于同类老系统改造边界模糊的集团信息化项目，我建议从规划阶段就引入需求追溯矩阵，并把 " 待验证假设 " 显式标注为高风险工作包，方能以可控的范围换来确定的交付。正是这种贯穿始终的边界治理，让我在满足能源管控核心诉求的同时，未陷入无休止的需求拉锯。

五、以范围规划与结构化需求收集筑牢基线
在启动阶段，我没有急于拆解任务，而是先用访谈、问卷与原型演示三种方式并行收集需求，并组织业务、工艺、设备、信息四方的联合需求研讨会，把分散在各部门头脑中的诉求一次性摊开对齐。针对能源管控涉及的水、电、气、冷、热多介质计量，我把需求按关键程度分级，对高优先级的实时采集与越限告警做重点确认，对低优先级的报表定制则排入二期。随后用亲和图把上百条原始需求聚类为十二个需求包，再逐包与干系人确认范围边界与验收标准，形成了各方签字的范围说明书。这一步看似耗时，却让后续几乎所有变更都有据可依，从根本上压低了范围蔓延的概率。

六、以分阶段范围确认把验收做在过程里
范围管理最怕临到上线才做一次总验收，彼时偏差已难以挽回。我把项目划分为采集接入、数据治理、智能分析、可视化四个阶段，每个阶段结束都设置正式的范围确认节点：由业务方代表对照范围说明书逐条核验，签署阶段验收单后方可进入下一阶段。在智能分析阶段，业务方一度要求增加碳排放测算模块，我依据范围说明书判定其属于新增范围，启动变更流程而非直接纳入，既尊重了干系人诉求，也守住了原合同的交付底线。这种把验收拆进过程的方式，使项目在十三个月的周期里始终没有出现过范围性的方向返工。

七、复盘与展望：边界清晰才能交付从容
回望整个项目，范围管理的核心不在于把计划写得多厚，而在于把边界划得多清。直方图让我看清需求分布的重心，亲和图把混沌的诉求聚成有序的需求包，面向 X 设计矩阵则确保每一项需求都能追溯到交付与验证，而分阶段的确认机制把验收前移，让范围蔓延无处藏身。若重来一次，我会更早引入需求追溯矩阵工具，并在需求研讨会前先发放结构化问卷，缩短现场对齐的时间。对于同类老系统改造边沿系统的集团信息化项目，我建议从规划阶段就引入需求追溯网络，并以可验证的假设显式标注高风险工作，方能以可控的范围换取确定的交付。

回望整个项目，若让我给同行留下三条范围管理铁律，其一是需求不急收敛，用亲和图把混沌诉求聚成需求包之前，绝不轻易拆解任务；其二是边界不口头约定，所有范围确认必须落到签字的范围说明书与阶段验收单；其三是变更不随手纳入，任何新增诉求先过变更流程再谈排期。这三条让十三个月的项目在多次诱惑面前守住了交付底线。

项目最终于 2025 年 9 月通过整体验收，能源管控中心接入各类能耗采集点逾两万个，越限告警平均响应时间由过去的半小时压缩至三分钟，年度节能测算收益超出合同签订预期。回望这段经历，范围管理给我最深的教训是：老系统改造类项目最危险的不是需求多，而是需求边界模糊。直方图、亲和图与面向 X 设计矩阵是我划定边界的三件工具，而分阶段的范围确认则是守住边界的护栏。若将这套方法浓缩成一句话，便是用结构的手段管住混沌的诉求，用过程的确认锁住漂移的边界。范围说明书不是束之高阁的文件，而是贯穿项目始终的契约；每一次变更评审，都是在保护与干系人共同约定的那条直线。项目经理的价值，正是在无数次加一点的诱惑前，有底气说不，并把不转化为下一期更有序的是。