076_豫东某省级充电桩运营管理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

豫东地区某省新能源汽车保有量近年来增长迅速，充电基础设施建设随之提速，但运营管理长期各自为政：不同企业投建的充电桩接入各自的平台，车主跨平台找桩难、结算不透明，主管部门掌握不了全省充电设施的实时状态，月度运营报表要等各企业报送后人工汇总，最快也要五天才能出炉。为补齐这一短板，该能源集团运营管理中心于 2021 年 1 月发起了省级充电桩运营管理系统信息系统项目，经公开招标由我司承建，合同额 786.46 万元，建设周期 13 个月，我担任项目经理，对项目的启动、规划、执行、监控与收尾负总责。

项目的建设目标是把全省充电桩的桩站档案、充电订单、故障告警、运营统计统一接入一个平台，实现一站看全省、一网管到底。建设内容包括桩站档案与地图服务、充电订单与计费结算、设备接入与远程运维、故障告警与工单流转、运营统计与报表五个子系统，并与集团财务系统、客服系统及省级监管平台对接。技术方案采用服务网格 Istio 实现微服务间的流量管控与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端使用 Java 17 与 Spring Boot，应用中间件为东方通 TongWeb，系统运行在集团信创云环境中，按等级保护三级完成安全建设与测评。项目团队共 22 人，采用矩阵型组织，除我之外配置系统架构师 1 人、需求分析师 2 人、开发工程师 11 人、测试工程师 3 人、实施与运维工程师 2 人、质量保证与配置管理各 1 人。项目于 2022 年 2 月通过终验，上线后月度报表出具时间由 5 天缩短至 4 小时，用户满意度测评由 78 分提升至 94 分，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日。

范围管理回答的是项目到底做什么、做到什么程度的问题。回看整个建设过程，范围边界划得清不清、需求抓得准不准、变更控得严不严，几乎决定了其他所有管理活动的走向。下面我从理论认识、实践做法、反思改进三个层面，谈谈本项目在范围管理上的思考与作为。

一、对项目范围管理的理论认识

从理论上讲，范围管理要回答两个问题：项目该做什么，以及交付边界如何守住。回答这两个问题需要六个过程——规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围——前四个集中在规划阶段，后两个属于监控性质，贯穿执行与收尾。

从理论上讲，范围管理的准绳是经批准的基线，它由范围说明书、WBS 与 WBS 词典构成；基线一旦批准，任何调整都必须回到整体变更控制流程，这是范围管理区别于一般任务管理的关键。

从理论上讲，范围管理处在规划绩效域与度量绩效域之间，扮演传动轴的角色：规划绩效域产出计划与基线，范围管理把基线落实为具体交付边界；度量绩效域持续产出偏差数据，范围管理据此判断是否纠偏。

二、范围管理的实践做法

规划范围管理阶段，我依据项目章程、合同与集团信息化项目的组织过程资产，牵头编制了《范围管理计划》与《需求管理计划》，把范围定义方式、WBS 分解层级、确认与控制的流程以及干系人参与规则写明，经集团信息管理部门与我司分管领导评审后发布，成为后续范围工作的总纲。

收集需求阶段，我们访谈集团运营部、财务部、客服中心、接入企业代表与一线运维班组，整理出原始需求 213 条。为排出轻重缓急，我把每条需求按业务价值与实现成本两个维度画成散点图，横轴是预估实现成本，纵轴是对运营效率的影响程度。图形清楚显示，桩站状态实时推送、离线订单自动补传、故障工单自动派发等需求集中在高价值低成本的左上区域，而充电车位预约、车主社区等需求落在低价值区域。这份分布让我们与建设单位商定一期范围时有了共同语言：高价值需求全部纳入，低价值需求排入后续版本。经确认的《需求文件》随后作为定义范围的输入。

定义范围阶段，建设单位横跨运营、财务、客服多个条线，我在《项目范围说明书》里对边界逐条细化：项目范围即建设五个子系统并完成与财务、客服及省级监管平台的对接；交付成果包括各子系统上线运行、接口联调报告、性能测试报告与运维手册；验收标准写明月度报表 4 小时内自动生成、订单计费差错率为零、故障工单自动派发成功率不低于 98% 等；同时列明除外事项：不包含社会第三方充电桩的强制接入、车主 APP 的前端改版与历史欠费数据清理。每一条都经干系人确认，避免验收时扯皮。

创建 WBS 阶段，我把范围说明书按五个子系统加项目管理与集成测试逐层拆解，第二层按功能模块展开，第三层落到工作包，遵循 100% 规则，控制单包工期在 8 至 80 小时之间，形成 WBS 与 WBS 词典。例如设备接入与远程运维子系统拆为协议适配开发、设备档案迁移、远程运维接口、终端联调四个工作包，协议适配再按充电桩品牌细分。WBS 与词典成为估算、排程与考核的统一口径。

确认范围阶段，我们采取分阶段确认的方式，每完成一个子系统就组织一次阶段验收。以设备接入与远程运维子系统为例，验收时邀请集团运营部、一线运维班组、接入企业代表与监理参加，按预编的检查单逐项核对（见表 1）。逐项检查比笼统演示更能暴露问题，这次验收发现部分老旧充电桩因协议版本过旧无法接入，属于范围说明书已明确的兼容性适配事项，我们据此提交差异说明，经确认后纳入适配计划。全部子系统确认完成后，各方代表签署了《阶段验收报告》。

序号	确认事项	确认方式	确认结论
1	接入设备类型与数量	对照站点清单现场清点	齐全
2	状态数据上报实时性	随机抽取终端实测时延	达标
3	远程指令可达性	向终端下发远程指令	全部响应
4	异常终端自动告警	模拟故障观察告警链路	及时触发
5	差异项处理	老旧桩协议不适配说明	纳入适配计划

控制范围阶段，集团分管领导提出把社会第三方充电桩的加盟接入纳入本期建设，涉及新的计费分账模式与外部系统对接，影响面很大。我没有直接答应，而是组织团队做了一次根本原因分析：先追问为什么会有这个诉求，追到根源是运营部希望扩大平台数据覆盖面，而这一诉求此前从未进入需求清单。我把影响评估结果——预计新增工作量约 700 人天、工期延长两个月以上、超出合同范围——整理成变更申请提交变更控制委员会，同时建议作为二期单独立项。委员会评审后采纳了建议，项目得以守住范围基准。与此同时，配置管理员按《范围管理计划》每周用逐项检查清单核对可交付成果与 WBS 的对应关系，防止范围悄悄膨胀。

三、范围管理与规划绩效域、度量绩效域的协同

范围管理在项目中从来不是单打独斗，它与两个绩效域的联动，分别解决了范围从哪来与范围管得怎么样两个问题。

规划侧的联动体现在三处：其一，范围说明书与 WBS 是进度、成本、资源计划的共同输入，基线定了，各专项计划才有了分解对象；其二，规划中的假设与约束会反向影响范围的取舍，本项目终端兼容性适配的工作量被低估，就是在中期规划回顾时被发现，我们据此调整了 WBS 中适配工作包的分解粒度与估算；其三，规划阶段识别出的风险会触发范围基线的重新审视，避免问题积累到执行期才暴露。

度量侧的联动体现在两处：其一，我们把需求变更率、范围偏差率与验收一次通过率纳入月度度量，前期数据显示变更集中在计费规则与报表口径，据此把这两类需求的澄清前置到设计评审，变更数量在第四个月后明显回落；其二，验收绩效数据回流到度量看板，让范围控制从凭感觉变成了看数据。

规划输入与度量反馈齐备，范围管理的六个过程才真正闭环运转，这正是本项目范围管理能够落地的主要原因。

四、反思与改进

项目顺利通过终验，但回顾仍有值得检讨之处。其一，终端兼容性适配工作量在规划期被低估，说明 WBS 分解时对设备存量底数的核查不够充分，此后我要求同类项目在创建 WBS 前先完成设备普查。其二，需求收集阶段对集团多级组织审批链条的理解不足，权限模型在设计中期返工一次，若在收集需求时把审批链路作为独立干系人访谈，本可避免。其三，确认范围的检查单偏重功能核对，对性能与安全项的覆盖不够，后期补充了性能验收条目。这些经验已沉淀进公司的《经验教训登记册》。

综上，范围管理本质上是管理边界感：散点图让需求的取舍有了依据，范围说明书把边界写到可核对的程度，WBS 让做且只做有了落点，根本原因分析与逐项检查分别盯住变更源头与交付对齐。依靠这套机制，项目在审批链条长、验收时点刚性、终端形态复杂的多重约束下按期交付，月度报表由 5 天压缩到 4 小时，满意度由 78 分提升到 94 分，平均办理时长由 3.5 个工作日压到 0.8 个工作日，得到了建设单位的认可。