059_冀中某区县级船舶污染物接收监管系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2024 年 2 月，我作为项目经理牵头承建冀中某区县级船舶污染物接收监管系统项目。该项目由该地区交通运输主管部门发起，是辖区水污染防治与船舶环保监管数字化升级的重点工程，旨在解决船舶油污水、生活污水、生活垃圾等污染物接收转交过程监管缺位、纸质联单流转低效、跨部门数据不通等痛点，构建覆盖污染物申报、接收作业、联单流转、转运处置、监管追溯的一体化信息系统。项目合同额 645.12 万元，建设周期 7 个月，于 2024 年 9 月完成全流程验收并正式交付使用。项目采用强矩阵型组织结构，组建 11 人核心团队，下设项目经理 1 人、技术经理 1 人、产品经理 1 人、系统架构师 1 人、需求分析师 1 人、研发人员 5 人、测试工程师 1 人、QA 与 CM 各 1 人，我全面负责项目启动、规划、执行、监控与收尾全过程管理。技术架构上，平台采用低代码平台与微服务网关承载业务编排，以国产分布式数据库 OceanBase 实现主数据存储，依托 RocketMQ 消息中间件完成申报、接收、转运等子系统间的异步解耦；前端基于 Vue3 与 TypeScript 构建监管大屏与移动端，后端采用 Java 17 与 Spring Boot 开发核心服务，中间件选用国产东方通 TongWeb，整体部署于政务云信创环境，并按等保三级要求落实安全防护。项目最终交付一套完整的船舶污染物接收监管系统，完成与海事、生态环境及环卫处置单位的数据对接，顺利通过交通运输主管部门组织的验收并投入常态化运行。

在本项目推进过程中，我面临三个突出的范围管理难点：一是现场施工与在线业务需并行，不能中断日常办理；二是存量老系统接口文档缺失，改造边界难以厘清；三是第三方厂商交付质量参差，集成测试反复返工。作为项目经理，我以范围管理各过程为抓手，针对每个难点先摆问题、再讲用何种过程与工具化解，确保项目范围清晰、无蔓延、可验证。

一、难点一：现场施工与在线业务并行，不能中断日常办理

本项目的污染物接收作业依托既有业务系统持续运行，新系统建设期间旧业务不能停摆，这对范围边界的界定提出了特殊要求。若把 " 保障旧业务连续运行 " 误纳入本项目交付范围，极易造成范围蔓延与责任混淆。

我运用规划范围管理与定义范围过程化解该难点。在规划范围管理时，我将 " 在线业务不中断 " 明确列为项目执行的约束条件而非交付范围，据此编制《范围管理计划》，规定所有功能需求必须围绕新建监管系统本身，旧系统的平稳运行由独立的运维保障方案承接。在规划范围管理过程中，我还专门识别了范围管理的制约因素与假设条件，把 " 既有业务系统须持续运行 "" 硬件传感由其他专项承建 " 列为假设与制约，写入范围管理计划，使团队在后续执行中不被边界外工作牵扯。这一前置动作，让需求评审会从此聚焦 " 新建系统本身 "，评审效率较同类项目明显提升。在定义范围阶段，我通过产品分析将 " 船舶污染物接收监管 " 这一宏观目标拆解为申报、接收、联单、转运、追溯五大功能模块，并形成项目范围说明书，明确排除 " 旧业务系统改造 " 与 " 硬件传感网络新建 " 两项边界外内容。在拆解时，我进一步把 " 污染物申报 " 细化为 " 企业自主申报 "" 船舶到港触发申报 "" 移动端扫码申报 " 三种作业模式，并逐一明确每种模式的数据来源与责任人，使范围说明书不仅写清 " 有什么 "，也写清 " 怎么来 "。同时，我把 " 在线业务保障 " 单列为独立的保障工作包，与功能范围包并列管理，使团队对 " 做什么、不做什么 " 形成统一认知。在控制范围过程中，我借助控制图监控范围变更请求的月发生频率，将其控制在预设上控制限之内，凡超出趋势的变更一律提交变更控制委员会评审，从源头杜绝无控蔓延，最终项目范围偏差始终保持在正负百分之三以内。这一做法让建设单位清晰看到新旧系统的责任分界，避免了就 " 为何旧业务故障算项目问题 " 产生的反复扯皮。

二、难点二：存量老系统接口文档缺失，改造边界难以厘清

项目需与海事、生态环境等既有系统对接，但这些老系统的接口文档大量缺失，导致 " 要对接哪些数据、对接到什么程度 " 长期模糊，范围边界摇摆不定。

我运用收集需求与定义范围过程，并引入标杆对照工具化解该难点。在收集需求阶段，我组织交通运输主管部门、海事与环卫处置单位开展联合需求工作坊，逐一梳理各单位的业务诉求与数据期望，最终归纳出污染物联单、接收量、转运去向三类核心数据流。为厘清改造边界，我选取沿海先进地区的船舶污染物接收监管系统作为标杆，对照其功能边界与数据接口规范，逐项比对本项目应当覆盖与可以省略的内容，形成差异清单。通过标杆对照，我们还统一了与海事、生态环境系统的数据字典，把原本含糊的 " 对接 " 变为字段级的可验收清单，需求澄清效率明显提升。例如标杆系统将 " 联单电子签章 " 列为必选，我将此纳入范围；而标杆中 " 卫星定位轨迹回放 " 属可选增强，结合本区县级实际我将其列为二期，不在本期范围。值得一提的是，标杆对照并非简单照搬先进地区做法，而是结合本区县级财政与运维能力做减法与适配。例如先进地区的 " 无人船采样 " 能力远超本地需求，我明确将其排除；而其 " 联单全生命周期追溯 " 的闭环逻辑，则被完整保留并下沉到本期范围，确保监管不留断点。在控制范围环节，我继续用控制图监控需求澄清平均时长，当某接口澄清时长连续两周超出上控制限时，及时增派架构师驻场对接，避免边界拖延影响整体进度。

三、难点三：第三方厂商交付质量参差，集成测试反复返工

本项目集成多家第三方厂商的硬件与子系统，厂商交付质量不一，集成测试阶段频繁出现联调失败、数据格式不符等问题，若不在范围确认环节卡住质量，将导致范围 " 看似完成、实则不可用 "。

我运用确认范围与控制范围过程，并运用因果图工具化解该难点。在确认范围阶段，我制定标准化验收核对单，将每一项可交付物的验收标准、数据格式、联调通过条件书面化，组织监理与建设单位逐条确认，杜绝 " 差不多就算通过 "。针对反复返工，我运用因果图从人、机、料、法、环五个维度溯源，定位主因为 " 厂商接口规范未强制约束 "（法）与 " 测试环境与生产环境配置不一致 "（机）两类。据此我推动两项整改：一是将接口规范以契约文件形式固化，要求厂商交付前先通过契约自检；二是在确认范围前统一测试基准环境。同时，我以控制图持续监控集成缺陷率，设定上控制限并每周点检，缺陷率从初期的高位稳步回落至受控区间。例如一家厂商的电子联单模块因未遵循契约反复失败，经根因整改后一次联调通过率由四成升至九成以上，集成周期缩短近半。对厂商交付质量的卡控，也倒逼其建立内部自检流程，项目后期的集成一次通过率稳定在九成以上，基本消除了反复返工对进度的吞噬。确认范围的刚性还改变了厂商心态——他们在需求阶段就主动与我们对齐契约，而非等到集成时再扯皮，监理方在阶段性确认中对可交付物的完成度给予高度评价，验收一次通过。

本项目于 2024 年 9 月按期验收。回顾全程，范围管理之所以有效，得益于针对三大难点分别施策：以规划与定义范围守住业务并行下的边界，以标杆对照厘清老系统改造范围，以确认范围加因果图、控制图卡住厂商交付质量。范围管理的要害在于 " 先划界、再卡质 "——边界不清则扯皮不断，验收不刚则交付注水，二者缺一不可。从更宏观的视角看，范围管理是项目成功的地基：地基不稳，再好的进度与质量管控都无从谈起。本项目能在七个月工期内交付一个边界清晰、质量可控的系统，正是问题驱动式范围管控的直接回报，也为同类区县级环保监管信息化项目的范围管理提供了可复用范本。