077_滇西某地市级水情雨情监测系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

滇西地区某地市河流密布、山高谷深，汛期暴雨来势猛，水情雨情数据直接关系到沿岸乡镇的防洪调度。过去多年，该地市的雨量站、水位站、水文站分属水利、气象、应急等多个条线管理，观测数据靠电话与纸质报表逐级上报，时效差且口径不一，遇到强降雨，值班人员常常要打十几个电话才能凑齐一份汛情快报。为改变这一被动局面，该地区水利与农业农村主管部门于 2021 年 7 月发起了地市级水情雨情监测系统信息系统项目，经公开招标由我司承建，合同额 850.08 万元，建设周期 13 个月，我担任项目经理，负责项目的全过程管理。

项目建设目标是整合全市雨量、水位、流量与视频监测资源，实现水情雨情数据的自动采集、实时汇聚与可视化展示。建设内容包括监测站点接入管理、数据采集与传输、预警模型与阈值管理、汛情分析与发布、台账报表五个子系统，覆盖全市百余处监测站点，并与省级水利平台、应急指挥系统对接。技术方案采用低代码平台承载表单与流程的快速配置，前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，各微服务经微服务网关统一鉴权与限流，数据存储选用 OceanBase 分布式数据库，跨系统的消息推送由 RocketMQ 承担，应用中间件采用东方通 TongWeb，整体部署在市政务云信创环境，按等级保护三级完成安全建设。项目团队共 12 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 5 人、测试工程师 2 人、实施与数据治理专员 1 人。项目于 2022 年 8 月通过验收，上线后线上办理率由 51% 提升至 93%，资金结算差错实现连续 12 个月零发生，关键业务响应时间由 4.2 秒降至 1.1 秒。

这个项目的难点不在技术本身，而在范围的两头：一头是历史数据与站点底数不清，数据初始化工作量巨大；另一头是用户长期习惯线下纸质台账，对新系统能做什么没有概念，需求说不清楚。范围管理正是解决这两头问题的抓手。下面我按范围管理的六个过程逐一展开，结合各过程的主要成果，说明本项目的范围管理实践，并论述范围管理与规划绩效域、度量绩效域的协同关系。

一、规划范围管理

规划范围管理是为明确如何定义、确认和控制项目范围，编制范围管理计划与需求管理计划的过程，其作用在于为范围工作提供统一的方法与规则。我参考项目章程、合同以及单位历年水利信息化项目的经验教训，组织需求分析师与骨干开发共同拟定了《范围管理计划》，明确了范围说明书的编制要求、WBS 的分解层级、确认范围的验收组织方式与控制范围的变更流程，并配套《需求管理计划》，规定了需求收集渠道、优先级评定方法与追溯矩阵的维护要求。两份计划经主管部门与我司分管领导确认后执行。

二、收集需求

收集需求是为实现目标而识别、记录并管理干系人需要和需求的过程，其作用在于为定义范围奠定基础。考虑到一线人员分散在各乡镇站所，我们采取分批访谈加集中座谈的方式，先后收集原始需求 186 条。需求五花八门，我组织团队用亲和图对需求逐条归类：把意思相近的需求贴在一起，按内在关联归拢，最终聚成监测数据接入、预警处置、报表与台账、系统对接、界面易用性五个族群，其中监测数据接入类需求条目最多，占总量四成。归类之后再用直方图统计各族群的条目数与涉及干系人数量，图形显示预警处置与报表台账两类需求虽然条目不多，但涉及的干系人最广，几乎每个乡镇站所都提到，属于典型的高关注需求。亲和图加直方图的组合，让我们既看清了需求的聚类结构，也看清了需求背后的利益分布。最终产出《需求文件》和《需求跟踪矩阵》并获各方确认。

三、定义范围

定义范围是制定项目和产品详细描述的过程，其作用在于明确项目边界与验收标准。我牵头编制《项目范围说明书》，对边界逐一写明、力求可核：项目范围涵盖上述五个子系统，完成全市百余处站点接入及与省级平台、应急指挥系统的对接；交付成果包括各子系统、站点接入清单、数据迁移报告与运维文档；验收标准写明数据采集到展示的端到端时延不超过 1.1 秒、预警信息 5 分钟内送达责任人员、报表自动生成等；除外事项列明不包含站点土建改造、水利专网重新铺设与历史纸质台账的电子化扫描。针对数据初始化工作量大的风险，我们专门组织了数据接入方案的技术选型：用面向 X 设计矩阵把候选方案按面向兼容性、面向可扩展性、面向可维护性三个目标交叉评分，选定 " 标准适配层加站点能力声明 " 的接入框架，使新增站点只需声明采集能力即可接入。说明书经主管部门逐条确认后发布，作为往后范围工作的基准。

四、创建 WBS

创建 WBS 是把项目可交付成果与项目工作逐层分解为更易管理组件的过程，其作用在于把范围转化为可执行、可考核的工作包。结构上，第一层是五个子系统，加上项目管理与集成测试两类支撑工作；第二层按功能模块拆分，第三层细化到可考核的工作包，遵守 100% 规则，并让单包工期落在 8 到 80 小时区间。例如数据采集与传输子系统向下分解为站点协议适配、数据校验入库、断点续传、传输监控四个工作包，其中站点协议适配又按设备型号进一步细分。WBS 词典对每个工作包补充了负责人、验收标准与依赖关系，成为排程、估算与考核的同一把尺子。

五、确认范围

确认范围是正式验收已完成的项目可交付成果的过程，其作用在于通过干系人逐项确认提高最终验收通过的可能性。我们采取里程碑分阶段验收：监测站点接入完成后先做一次集中验收，预警模块上线后再验收一次，最后整体终验。以站点接入验收为例，我们请主管部门业务科室、乡镇站所代表到场，监理也一并参与，对照站点清单清点、抽查上报时延、验证断点续传，还专门到三处信号弱的偏远站点现场复测，确认数据仍能回传。对验收中发现的阈值配置不合规问题，我们当天登记、限期整改，一周后复核通过。全部确认完成后，各方签署阶段验收报告。一次确认范围的全部过程记录见表 1。

阶段	验收对象	参与方	验收结论
1	站点接入集中验收：站点清单、数据完整率、上报时延	业务科室、站所代表、监理	一次通过，抽查三处弱信号站点正常
2	预警模块验收：阈值配置、信息送达时效	业务科室、值班人员	发现配置不合规项，限期整改
3	问题整改复核：对不合规项复查	测试组、监理	复核通过
4	整体终验：全流程联合验证	主管部门、监理、我司	通过并签署验收报告

六、控制范围

控制范围是监督项目状态、管理范围基准变更并生成工作绩效信息的过程，其作用在于防止范围蔓延。项目执行中，应急指挥中心提出把视频会商功能并入本期建设，在范围说明书中本就不在本次范围之内。我组织团队评估后向变更控制委员会提交了变更申请，说明该功能需新增视频编解码组件与专线带宽扩容，工期与成本均不可控，建议由应急条线单独立项。委员会采纳建议后，本期范围得以保持。为防范围悄悄扩张，配置管理员每周核对 WBS 与实际工作的对应，发现计划外工作立即登记追源。

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

范围管理不是关起门来管的，它与两个绩效域的关系可以归结为输入与反馈两条线。

范围管理与规划绩效域的配合，在项目里最直接的体现是范围说明书与 WBS 先于一切计划而存在。没有清晰的 WBS，进度网络图排不出活动，成本估算没有分解对象，资源安排也缺少依据。本项目在规划阶段把站点接入按区域与设备型号分解到工作包后，进度计划才得以按先接数据、后上预警的顺序排定。反过来，规划中暴露的资源约束同样会倒逼范围做出取舍，例如偏远站点专线条件不足，我们据此在范围说明书中明确了无线与卫星双通道的接入方式，这就是规划对范围的塑造。

范围管理与度量绩效域的配合，体现在绩效数据对范围控制的反馈上。我们每月统计需求变更数量、范围偏差比率与验收一次通过情况，纳入月度例会讨论。数据显示前两个月变更请求偏多，主要集中在报表口径上，我们据此把报表口径的确认提前到设计评审阶段，此后变更数量明显回落。有了这些数据，控制范围就不再是拍脑袋判断，而是建立在可量化的事实之上。

两个绩效域一个提供规划的骨架，一个提供度量的反馈，范围管理的六个过程正是在这个闭环中才真正运转起来。

八、结语

这次实践让我体会到，范围管理说到底是在不确定性中把承诺钉牢。面对底数不清的历史数据、习惯纸质台账的用户和形态各异的监测站点，把范围说清楚、把承诺写下来、把变更管起来，比任何单点技术都更重要。亲和图收敛了零散的需求，直方图暴露了需求的关注度分布，面向 X 设计矩阵让技术选型有了可比较的依据，检查单让确认范围落到了逐项把关。项目最终按期验收，线上办理率由 51% 提升至 93%，资金结算差错连续 12 个月零发生，关键业务响应时间由 4.2 秒降至 1.1 秒，这些数字背后，是范围管理打下的地基。