070_江浙某区县级渣土车辆监管系统信息系统项目整合管理

ONEPSOFT | 软考学习知识库

---

一、我参与管理的项目概况及本人承担的工作

渣土运输是城市管理中最容易引发投诉的环节之一：车辆不密闭造成抛洒滴漏，夜间超速穿行居民区，工地出场不称重、消纳场进场不核验，出了问题往往查不到源头。江浙某区县原有的管理办法依赖路面巡查和事后处罚，既费人力又难以形成闭环。为把监管前移到运输全过程，该地区城市管理主管部门于二〇二一年二月立项建设江浙某区县级渣土车辆监管系统，由我所在单位承建，合同额一千六百八十万一千二百元，建设周期十五个月，二〇二二年五月通过验收并投入运行。

系统包含车辆与企业资质备案、工地与消纳场电子联单、车载物联感知与轨迹监控、违规行为智能研判、协同执法处置、统计分析与决策支持六个业务模块，同时完成全区七百四十六辆渣土车的车载终端加装以及三十一处工地道闸与称重设备的联网改造。交付成果包括系统软件与部署包、源代码及接口文档、车辆与场所基础数据集、设备联网改造资料、运维手册与培训课件、等级保护测评报告与验收资料。技术上，服务之间通过服务网格 Istio 完成流量治理与故障隔离，数据层选用 GaussDB 作为主库并以分布式缓存支撑高频轨迹查询，整体按多活容灾架构部署；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件为东方通 TongWeb，运行于政务云信创环境，安全防护按网络安全等级保护第三级同步建设。项目采用矩阵型组织形式，团队十二人，其中需求分析三人、技术研发六人、运维测试两人，加上担任项目经理的我共十二人，人员构成与总数完全对应。我负责项目的整体策划、跨部门协调与全过程管控。系统上线后，月度报表出具时间由五天缩短至四小时，跨部门数据共享接口调用量月均突破一百二十万次，并发承载能力由八百提升至五千用户同时在线。

本项目有三处硬骨头：早晚运输高峰时段并发访问集中，性能压力大；全区仍有部分偏远消纳场未通政务网专线，通信稳定性不足；系统涉及执法与企业经营敏感数据，必须按等级保护第三级要求同步建设。这些约束使得需求变更频繁、技术方案反复、跨方协作复杂，整合管理因此成为贯穿始终的主线。下面我先谈对整合管理的理论认识，再讲本项目的具体做法，最后作一番反思。

二、理论认识

从理论上讲，项目整合管理包含识别、定义、组合、统一和协调各项目管理过程组内的过程与活动，具体由制定项目章程、制定项目管理计划、指导与管理项目工作、管理项目知识、监控项目工作、实施整体变更控制、结束项目或阶段七个过程构成。它与其他九大知识领域的根本区别在于，别的领域各管一段，整合管理则要把这些段落缝合成一个整体。

在我看来，整合管理的统一作用体现在三个层次。第一层是计划的统一，各知识领域的子计划必须彼此不冲突，最终汇聚为一份经批准的项目管理计划，形成范围、进度、成本三大基准。第二层是执行与变更的统一，项目一旦启动，来自各方的偏离基准的诉求会源源不断，如果没有一个统一的入口和统一的裁决机制，基准就会在不知不觉中被架空。第三层是知识与收尾的统一，项目的价值不止在于交付了什么，还在于留下了什么，知识若不沉淀就随人流散，收尾若不彻底就会长期扯皮。这三层认识，正对应本项目最需要下功夫的三件事。

三、实践做法

（一）用四道闸门管住变更。 本项目建设期需求变更压力极大，仅电子联单的核验规则就随着上级政策调整改了五轮。为守住基准，我设计了四道闸门，任何变更都必须依次通过，缺一不可。

第一道是受理闸。所有变更诉求必须以书面变更请求单的形式提出，注明提出人、事由、期望完成时间，口头意见和微信留言一律不作为受理依据；配置管理员当日登记编号，纳入变更登记册。第二道是影响闸。我牵头组织技术、进度、成本三方联合评估，量化该变更对工期、费用和已完成工作的冲击，同时对涉及架构调整的方案，运用面向可维护性、面向安全性、面向性能的设计矩阵横向比较备选方案，避免只看眼前不看长远。有一次工地方要求把道闸接入放到企业资质审核之前，我们通过设计矩阵评估后发现，此举虽能提高进场效率，却会让未备案车辆绕过管控，安全性得分明显偏低，最终改为并行受理、资质通过后方可开闸的折中方案。第三道是决策闸。评估结论提交变更控制委员会审议，委员会由主管部门执法科负责人任主任委员，成员含交通、住建协办代表、企业代表和我方技术负责人共七人，审议结果无论批准与否都书面答复并归档。第四道是回归闸。批准的变更实施完成后，必须经回归测试与业务确认双重验证，确认无误后由我签字关闭该变更请求，同步更新受影响的基准与文档。

为了判断变更管理本身是否健康，我把每件变更从提出到关闭的处理时长做成直方图按周更新。第八周的图形呈现明显右偏，有九件变更的处理时长落在十五天以上的长尾区间。追查后发现，长尾几乎全部卡在跨部门会签环节。我随即把会签方式由逐级串行改为限时并行，三日内未回复视为无异议，此后长尾区间的变更件数降至一到两件，变更平均处理时长由九点七天缩短至四点二天。

（二）让知识留下来而不是随人走。 项目知识分为显性知识和隐性知识两类。显性知识是能够用文档、图表、代码明确表达的部分，本项目的接口协议、车载终端安装规范、违规研判阈值配置说明、等级保护整改记录都属于此类，我要求统一入库、按模块编号、随变更同步更新，保证文档版本与系统版本严格对应。隐性知识则是藏在个人经验里的判断力，例如什么样的轨迹形态最可能是偷倒、哪种车型的终端安装位置最不易被遮挡，这类知识只能通过面对面交流才能转化为团队可共享、可管理的显性成果。

为此我坚持每两周开一次经验共享会，会上每人写下本阶段最有价值的一条心得和最深的一个教训，贴到白板上。到第七次共享会时，卡片已积累两百余张，杂乱无章。我组织团队用亲和图的方法把这些卡片按内在亲缘关系归类，最终收敛为设备安装、数据治理、跨部门协作、性能优化、安全合规五个主题簇，并为每个簇指定一名维护人负责整理成册。这套按主题归拢的知识资产，后来直接支撑了运维交接培训，也被同事在邻区项目中反复调用。

（三）收尾时守住三条清单。 项目收尾不是签个字那么简单，我用三条清单来管。第一条是成果清单，依据范围基准逐项核对全部可交付成果，请业主方对每项成果进行评价并签署确认意见，未通过的当场登记整改事项。第二条是责任清单，核查与设备厂商和分包单位的合同履行情况，确认无未决索赔与争议后办理合同收尾，并明确质保期内各方的响应义务。第三条是资产清单，一方面把需求、设计、测试、变更、验收全套资料归档并更新到组织过程资产，另一方面按计划释放团队成员与租用环境，对项目占用的可用资源作出后续调整安排，同时完成系统权限与账号台账向区级执法指挥中心的正式移交，移交前对运维人员开展两轮培训与实操考核。

四、反思与改进

本项目于二〇二二年五月顺利通过验收，各项指标均达到合同约定。回过头看，仍有值得改进之处。其一，变更控制的四道闸门是在第三个月才补齐的，此前有三件小变更未经登记直接实施，虽未造成实质影响，却给后期回溯带来麻烦，说明规矩必须在开工之初就立好，而不是等出了问题再补。其二，知识管理起初重收集轻整理，两百多张卡片堆到第七次会议才动手归类，若能每次会后即时归并，团队受益会来得更早。其三，收尾阶段的运维培训安排偏晚，导致移交后头两周仍有大量咨询涌向项目组，今后应把培训提前到系统试运行期同步开展。整合管理的功夫，说到底就是把这些看似零碎的接口一个个焊牢，任何一处虚焊，最后都会在交付时显形。