092_皖北某区县级航道船闸调度系统信息系统项目综合管理

ONEPSOFT | 软考学习知识库

---

皖北地区某区县境内的航道货运繁忙，多座船闸承担着船只过闸调度任务，调度长期靠电话与纸质台账，船闸通行数据分散在闸站与航运部门手中，调度效率低、拥堵处置慢，船民对过闸时间心里没数，高峰期闸前排队成了常态。为提升船闸调度效率，该地区交通运输主管部门于 2024 年 12 月发起了区县级航道船闸调度系统信息系统项目，经公开招标由我司承建，合同额 1680.04 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合航道与船闸通行数据，实现过闸申报在线化、调度排班自动化、船舶动态可视化。建设内容包括船舶过闸申报、调度排班、船闸状态监测、预警与处置、统计分析与报表五个模块，并与航运部门、各闸站及船闸控制系统对接。涉密与敏感数据较多、国产化要求高、老系统接口文档缺失，三大约束在规划阶段就写进了风险清单。技术方案采用服务网格 Istio 统一治理微服务调用与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件采用东方通 TongWeb，系统运行在市政务云信创环境，按等级保护三级完成安全建设。项目团队共 18 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 9 人、测试工程师 3 人、实施与运维工程师 2 人。开发人员按模块分成三组，分别对接过闸申报、调度排班与预警处置三条业务线，测试人员随模块交付集中投入，资源随难点动态调配。船闸调度直接关系通航安全，系统的每一笔数据都要经得起核查，这也让资源投入的优先级格外清晰，安全与可靠相关的投入从不含糊。项目于 2025 年 11 月通过终验，上线后预警事件平均处置时长缩短 55%，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，数据自动核验比例由 42% 提升至 91%。

资源管理要解决的是项目靠什么把事做成的问题。资源分团队与实物两大类：团队资源是开发的骨干，实物资源是服务器、终端与许可，两类资源在三个难点面前各有各的调度逻辑。这个项目既有国产化整体适配的硬要求，又有涉密数据与等保三级的安全约束，还要面对老系统接口底数不清的麻烦，资源的调配必须围着这三道难题转，哪里风险大，资源就往哪里倾斜。下面我以项目推进中遇到的三道难题为线索，说明资源管理的各项过程与工具是如何嵌入其中发挥作用的。

一、难题一：国产化替代要求，数据库与中间件须整体适配

项目要求数据库与中间件整体采用国产产品，GaussDB 与东方通 TongWeb 的采购、原厂技术支持与适配验证环环相扣，任何一环不到位，测试环境就建不起来，开发进度就会被拖住。国产化不是换一个数据库那么简单，而是牵动测试环境、开发习惯与运维模式的一整套调整。

这一难题在获取资源与执行阶段集中显现。规划阶段，我依据资源管理计划把国产数据库与中间件的采购列入关键路径，提前与厂商锁定排期与技术支持资源，避免测试环境迟迟建不起来。资源估算时，我们把国产化适配单列为一项工作量，按数据库迁移、中间件替换、联调验证三个子项分别估算，避免适配工作被摊进普通开发里而低估。适配过程中，我发现部分数据迁移脚本在 GaussDB 上的运行效率明显偏低，没有急着调优，而是组织团队用根本原因分析逐层追问：先问为什么慢，再问为什么索引策略不兼容，追到根子是迁移脚本沿用了老库的写法，未针对 GaussDB 的优化器调整。找准根因后，我们安排两名熟悉 GaussDB 的开发工程师专项改造，索引与分区策略按新库特性重写，迁移效率提升明显。资源的精准投放让适配工作没有演变成全团队的持久战，两周内就回到正常节奏。

二、难题二：涉密与敏感数据较多，须按等保三级同步建设

船舶过闸数据涉及船民身份、货物信息等敏感内容，系统须按等级保护三级同步建设，安全资源投入不足或时序不对，测评就会返工，连带影响上线节点。

这一难题在控制资源阶段重点应对。我把安全建设所需的资源单独列账：等保测评服务、安全设备、渗透测试人力与数据脱敏工具，逐项纳入资源分解结构，避免与其他资源混在一起被挤占。安全建设从设计阶段就与功能开发同步推进，我编制了一份等保三级逐项检查清单，从物理安全、网络安全、主机安全、应用安全到数据安全逐项核对，每两周对照检查一次，凡不满足的项立即补资源、限期整改。逐项检查让安全要求从一纸规范变成了可打钩的动作，测评时一次通过，没有因安全欠账返工。等保三级对运维人员也有资质要求，我们提前安排两名运维人员参加相关培训并取得证书，避免测评时人员资质不达标。敏感数据的处理范围与访问控制也在需求阶段就写入范围说明书，涉密数据不出政务云环境，从源头上控制了安全风险面。安全资源虽然不直接产出功能，却是项目合规交付的底线，宁可多投也不能省。

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

需要对接的几套老系统接口文档残缺，字段含义要靠猜，改造边界说不清，接口工作量无法估算，资源安排也就没有依据。老系统接口文档缺失，最直接的影响是资源估算失去了参照，工作量说不清，人就没法排。

这一难题在估算活动资源阶段最棘手。我没有对整体盲目估算，而是先组织技术骨干对老系统做接口普查，把每个待对接接口的文档完整度、字段复杂度与改造工作量记录下来，画成散点图：横轴为字段复杂度，纵轴为预估改造工作量。图形清楚显示，绝大多数接口集中在低复杂度低工作量区域，少数几个文档缺失严重的高复杂度接口偏离主群，属于高风险项。据此我们把接口分为直接复用、补文档后对接、重写三档，分档套用不同的估算系数，自下而上汇总出接口改造的资源需求，比经验拍脑袋靠谱得多。对那几个高风险接口，我们专门安排了骨干力量并预留了缓冲，最终全部按期交付，高风险接口没有拖累整体进度。散点图把主观判断变成了可视的分布，资源投放因此有了依据，也让我们与建设单位解释工作量时有了数据支撑，不再各说各话。

四、心得体会

项目最终按期通过终验，预警处置时长缩短 55%，办理时长由 3.5 个工作日压到 0.8 个工作日，自动核验比例由 42% 提升到 91%，船闸调度从人工电话指挥升级为系统自动排班，船民过闸的等待时间明显缩短。回顾整个过程，资源管理的价值在于把有限的人与物投放到最需要的地方：国产化适配难，就用根本原因分析找准根因、精准补人；安全要求高，就用逐项检查清单把资源压到点上；接口底数不清，就用散点图把工作量分布看清、分档安排。三道难题各有各的解法，背后是同一条主线——资源围着难点转，人到位、物到位、责任到位，项目自然就顺了。回头看，散点图、根本原因分析与逐项检查清单三件工具，恰好对应了估算、执行、控制三个环节，工具的选用从来不是为用而用。把国产化、安全、接口三件事的资源账算清楚，项目的底座就稳了。资源管理不是一次性动作，而是贯穿 11 个月全程的持续功课，从规划到收尾，每一项资源投入都要能回答用在哪儿、为什么用。这套做法后来也被复制到公司其他交通类项目，验证了它的可复制性。