260_湘中某省会城市市政设施养护管理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

论湘中某省会城市市政设施养护管理系统信息系统项目的范围管理

一、项目概要叙述

市政设施养护是城市安全运行的基础保障，过去设施报修靠电话与纸质台账，破损发现滞后、养护派单靠人工。我所在的该地区城市管理主管部门，长期受困于设施台账分散、养护响应慢。为破局，该部门于 2024 年 6 月正式启动 " 湘中某省会城市市政设施养护管理系统 " 建设项目，我受委派担任项目经理，统筹需求规划、方案设计、开发实施、集成测试与验收移交全流程。

项目总投资约 480.32 万元，建设周期 18 个月，组建 13 人项目团队，内部含业务分析师 2 人、架构师 1 人、开发工程师 7 人、测试工程师 1 人、质保专员 1 人、配置管理员 1 人，外部含集成实施与多家养护所、热线中心的联调人员。微服务调用由服务网格 Istio 统一治理，数据持久化落到 GaussDB 分布式库并配分布式缓存，整体按多活容灾跨双中心运行，保障高并发下的业务连续。建设内容涵盖设施普查、智能巡检、养护派单、决策看板四大模块：设施普查建立道路、桥梁、路灯等设施电子台账，智能巡检对破损与隐患自动预警，养护派单把工单派给责任所并追踪闭环，决策看板向主管部门呈现设施健康态势。最终交付管理系统、移动端、指挥看板及全套运维文档。项目难点在于：项目周期紧、法定验收时点刚性，进度压缩明显；终端设备种类繁多，兼容性适配工作量被低估；线下流程长期依赖纸质台账，数据初始化工作量巨大。上线后，预警事件平均处置时长缩短 55%，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，运维人工巡检投入下降 60%。

二、前期：规划范围管理与收集需求

在項目启动阶段，需要明确范围怎么管并理清各方诉求，这一工作被称为规划范围管理与收集需求。我组织核心成员与养护所、热线中心代表召开规划研讨会，制定《范围管理计划》与《需求管理计划》，明确设施建档完整率、养护时限达标率等核心标准及变更审批流程。收集需求时，我用散点图分析 " 设施类型与报修频次 " 的 correlations，定位到道路井盖与路灯两类是报修高频设施，遂将其作为需求梳理的优先对象；用逐项检查按普查对象、巡检维度、处置角色、合规要求四个类别逐项核对，避免遗漏关键养护场景；用根本原因分析回溯纸质台账的源头，定位到 " 字段无标准 "" 历史数据残缺 " 是数据初始化难的真正根因，遂把 " 普查数据标准化 " 列为需求基线的前提。最终形成《需求文件》与需求跟踪矩阵，经干系人签字确认生效。收集需求时我还用散点图补充分析了 " 设施等级×养护成本 " 的关系，发现主干道设施虽数量少却占养护预算七成，遂在需求优先级上向主干道倾斜，把有限资源压到刀刃上。根本原因分析还揭示，纸质台账年代跨度大、不同所填写口径不一，是导致初始化返工的隐性根因，我遂把 " 统一字段字典 " 作为需求基线的前置动作，从源头消弭分歧。

本项目的需求跟踪矩阵以 " 需求编号—需求描述—来源—范围基准条目—对应 WBS 编码—交付物—验收准则—状态 " 为列，例如：需求 X01" 设施电子台账 " 来源于养护所访谈，对应基准条目 " 设施普查子系统 "，WBS 编码 1.1，交付物为普查数据库，验收准则为台账完整率≥97%，状态已验收；需求 X02" 破损自动预警 " 来源于热线中心，对应基准条目 " 智能巡检子系统 "，WBS 编码 1.2，交付物为预警引擎，验收准则为预警准确率≥94%，状态已验收；需求 X03" 养护工单闭环 " 来源于主管部门，对应基准条目 " 养护派单子系统 "，WBS 编码 1.3，交付物为派单系统，验收准则为工单按时办结率≥95%，状态已验收。矩阵让每一条需求都可从提出追到交付，从源头杜绝 " 做了没人认、要了没做 " 的脱节。

三、中期：定义范围与创建 WBS

在项目建设阶段，需要把需求钉死成边界并逐层拆解，这一工作被称为定义范围与创建 WBS。我编制《项目范围说明书》，明确交付物包含设施普查、智能巡检、养护派单、决策看板四个子系统，同时将 " 舆情监测大屏 "" 市民互动社区 " 等越界诉求列为除外责任。随后我带领团队按四大模块自上而下分解创建 WBS，遵循百分百覆盖与独立可交付原则，至少分解至 5 层，例如：1 市政设施养护管理系统；1.1 设施普查建档；1.1.1 数据采集；1.1.1.1 移动终端开发；1.1.1.1.1 离线采集功能。最低层级为工作包并分配唯一编码，形成范围基准。针对纸质台账数据初始化量大的难点，我把 " 历史设施数据清洗入库 " 单列为一个工作包并设里程碑，用根本原因分析定位初始化缺陷根因为 " 字段缺失 " 与 " 格式不统一 "，遂把数据质量校验嵌入初始化过程；用逐项检查在里程碑节点核对范围健康度，任何一项不达标不进入下一阶段。WBS 分解时我坚持工作包须可独立验收，把 " 智能巡检 " 拆成图像识别与预警引擎两个工作包，便于分别验收；把 " 设施普查 " 拆成数据采集与质控校验两个工作包，前者先交付、后者随数据治理迭代。分解完成后我组织技术、业务、运维三方评审，补全了系统对接与联调等工作项，WBS 词典也补齐了工期与责任人。

四、后期：确认范围、控制范围与心得体会

在项目收尾阶段，需要对照基准验收并守住边界，这一工作被称为确认范围与控制范围。确认范围阶段，开发测试完成后我组织质保团队内部预验收，修复 5 个缺陷，提交 38 份交付文档；2025 年 12 月召开正式验收会，11 人参会，对照范围基准从功能、性能、文档三方面核查，四大子系统全部就绪、设施台账完整率实测 97.2% 达标，形成经 6 方签字的《项目验收报告》。控制范围阶段，建设期内某养护所提出新增 " 共享单车停放监测 " 功能，我引导其走正式变更流程，经影响评估与 CCB 评审批准后执行并留痕；共受理变更 15 笔，批准 10 笔、驳回 5 笔，被驳回的多是顺手加功能的越界诉求。我还用逐项检查核对各所接入范围与数据质量，发现偏差立即纠偏。验收组事后反馈，正是这份逐环节、留痕迹的确认记录，让他们对系统的范围完整性最有信心；他们还抽选了三条真实报修走完 " 普查—预警—派单—办结 " 全流程，用真实业务而非演示数据印证了范围交付的实效。预验收阶段曾发现养护派单模块的 " 跨所转办 " 在极端并发下出现错分，我立即退回开发组补正路由、补回归用例，复测通过后才进入正式验收，避免了带病交付，也验算了确认范围这道关的真正价值。

项目于 2025 年 12 月顺利验收。做市政设施养护的范围，说到底是替城市把每一处破损都归到该去的工单里。本项目以散点图看清需求分布、以根本原因分析挖透数据根因、以逐项检查兜住范围健康度，形成了可复用的范围管理资产。当然，项目在创建 WBS 初期对活动与工作包层级把握偏晚，导致中期一度返工。回头看，范围管理最怕的就是 " 重功能、轻边界 "——把说明书写实、基准钉死、变更立住，远比堆功能管用。我越来越确信：范围这东西，是规划出来的，不是接出来的，接得越多边界越糊，这句话在我经手的项目里一次次被验证。往后我会把范围基线再磨细，推动范围管理从被动兜底转向主动设防，为城市运行托住每一道线。我还格外关注范围数据的真实性，曾出现某周设施台账完整率统计异常走高，核对是部分所为冲量重复录入，我当即要求采集带唯一标识、抽样复核，把水分挤干再入基准。范围数字若自己都会掺水，再漂亮的基准也只是摆设，这是我始终坚守的底线。市政设施连着城市的脸面与安全，任何范围疏漏都可能变成路上的隐患，因此我比以往任何项目都更较真每一条边界。把边界划清，比把功能做满更有价值，这是这个项目给我上的最贵的一课。