036_浙东某区县级二次供水监管平台信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

本文以浙东某区县级二次供水监管平台信息系统项目为例，围绕跨部门口径不一致、建设期政策调整、施工与在线业务并行三个核心难点，严格按题目 " 沟通管理过程 " 与 " 干系人管理过程 " 两个子问题展开论述。该项目由该单位信息管理部门发起，合同额 536.58 万元，2022 年 6 月启动，建设周期 6 个月，团队 13 人，采用服务网格 Istio、多活容灾架构、GaussDB 与分布式缓存构建，我担任项目经理。我运用逐项检查、散点图与根本原因分析支撑沟通管理各过程，并制定干系人管理计划。项目于 2022 年 12 月通过终验，平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，资金结算差错连续 12 个月零发生，预警事件平均处置时长缩短 55%。

一、项目概况与我承担的工作

该区老旧小区二次供水设施分散在 200 余个小区，水质与压力数据由各供水企业自管，住建、水务、卫生监督多头监管却口径不一，突发爆管与水质异常难以及时协同处置。一次小区水质投诉，往往要在住建、水务、卫生监督之间来回转办数日，居民意见很大，建设单位因此把 " 一事件、一口径、一出口 " 列为项目硬约束。为提升监管与应急响应能力，该单位信息管理部门作为建设单位发起本项目，我方中标承建，我被任命为项目经理。项目涉及住建、水务、卫生监督三家监管部门、3 家供水企业与 200 余小区物业，干系人层级与利益诉求差异极大，沟通界面复杂。

系统建设内容包括设施台账、实时监测、水质预警、应急调度与统计分析五个模块。技术实现上，采用服务网格 Istio 实现服务治理、灰度发布与双向 TLS 加密；多活容灾架构支持两地机房互备；数据持久化于 GaussDB 分布式数据库；分布式缓存承载小区与设施画像的高频查询。系统部署于区县级政务云信创环境，基于国产化服务器与操作系统，应用中间件采用东方通 TongWeb，敏感监测数据按等保三级加密。等保三级测评与开发同步推进，安全设计评审设为强制卡点，未通过不得进入下一阶段，避免了多数项目验收前的安全补课。

交付成果包括系统源代码与部署包；需求规格、概要与详细设计、数据库与接口规范等文档；测试方案与报告；等保三级测评与整改材料；设施台账初始化记录；上线与回退预案；面向运维、物业、监管三类角色共 6 场培训；以及 12 个月免费运维支持。

团队 13 人按矩阵型组织，下设需求组、开发组、集成实施组与测试组，另配专职配置管理员 1 名负责配置项与版本管理，质量保证人员 1 名。我作为项目经理，同时承担沟通管理总责，负责沟通管理计划的批准、重大沟通偏差的决策与干系人策略的最终裁定。

二、我对项目沟通管理过程的认识与做法

所谓规划沟通管理，指的是根据干系人需求为沟通活动分配时间、渠道与预算，并产出沟通管理计划的过程，其作用在于从源头界定 " 谁在何时以何种方式获取什么信息 "。本项目首个拦路虎是跨部门业务口径不一致：住建看设施合规、水务看供水压力、卫生监督看水质，三家对 " 同一次供水事件 " 的字段定义各不相同，数据无法直接对齐。我没有凭经验拍板，而是采用逐项检查，依据核对清单把需对齐的指标逐条列出——设施编码、压力单位、水质采样时点、事件分级等共 9 类 47 项，组织三家监管单位与 3 家供水企业逐条确认并签字，把模糊口径变成可落地的接口契约。例如卫生监督的 " 采样时点 " 原定为整点、水务的 " 压力上报 " 却是半小时粒度，逐项核对后才统一为每 15 分钟带时间戳上报，三家数据第一次能对得上。同步形成沟通管理计划，分配约 6% 专项时间与 1.6% 预算（约 8.6 万元）。计划经建设单位与监理联签后作为基线，任何沟通调整都走变更，杜绝凭口头约定改频道。

所谓管理沟通，指的是按计划产生、收集、分发与处理信息，使信息在干系人之间准确流动的过程。建设期内，上级对二次供水的考核政策发生两次调整，需求存在变动风险。我在管理沟通中建立 " 政策跟踪—影响评估—干系人同步 " 的闭环：每周汇总政策动态，用根本原因分析追问每次调整的底层动因，例如一次调整源于水质新规上线、另一次源于考核口径细化，据此形成政策—需求映射表，提前与 3 家供水企业、200 余小区物业同步变更，避免临时改口造成录入返工。两次政策调整分别影响到水质分级标准与设施编码规则，因提前一周同步，3 家供水企业的录入模板只改了字段映射、未动底层结构，返工接近于零。

所谓监督沟通，指的是持续监控沟通状态、动态优化策略的过程。本项目现场施工须与在线监测业务并行，不能中断日常办理。这点对二次供水尤为敏感，一旦在线监测断档，爆管或水质异常就可能漏报，后果直接关系居民饮水安全。为找到安全作业窗口，我以 " 每日施工并行时长 " 为横轴、" 当日业务中断告警数 " 为纵轴绘制散点图，发现二者呈正相关且告警集中在 9:00 至 11:00 的高峰时段；据此我把设备割接与台账初始化固定在夜间低峰，并设施工—运维联合值班。监督结果显示业务中断告警由月均 17 起降至 2 起。散点图还显示夜间低峰施工并行 8 小时以上时告警反而回升，我们据此把单日割接上限锁在 6 小时，既保进度又稳业务。

三、项目干系人管理过程及具体干系人管理计划

所谓干系人管理，指的是识别相关方并规划、管理、监督其参与的过程，包含识别干系人、规划干系人参与、管理干系人参与、监督干系人参与四个过程。结合本项目，我基于权力/利益方格分类并制定具体干系人管理计划：高权高益的建设单位主管与住建水务领导重点管理、请其参与阶段评审；高权低益的财政与审计部门令其满意、定期简报；低权高益的供水企业、小区物业与一线运维随时告知、保持参与；低权低益的施工单位售后与培训学员监督即可。其中 200 余小区物业虽个体权力低，但聚合后影响面极广，我把他们整体归入低权高益、统一在专属群发布操作指引，避免一对一沟通被淹没，上线后物业端操作疑问日均下降六成，证明归并策略有效。具体安排见表 2。

四、结项成效与心得体会

本项目 2022 年 6 月启动，2022 年 9 月完成核心监测模块上线，10 至 11 月试运行与多单位联调，2022 年 12 月通过终验，全程 6 个月，与合同工期一致。核心成效为：平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日；资金结算差错连续 12 个月零发生；预警事件平均处置时长缩短 55%。更关键的是，跨部门协同从过去的数日转办压缩到小时级，一次水质异常能在 30 分钟内完成三部门联动。

回顾这段经历，我有三点体会。第一，跨部门口径不能靠开会 " 达成共识 " 了事，逐项检查把 47 个指标逐条签字，才是真正对齐。47 个指标里光 " 事件分级 " 就吵了三轮，签字那一刻才真正定下来，可见模糊共识最贵，这一课后来被我写进公司跨部门项目的沟通模板。第二，政策变动不可怕，可怕的是变动不透明；根本原因分析让我们把每次调整追到动因，沟通才有提前量。我们甚至把政策—需求映射表固化成周会固定议程，让变动从被动救火变主动预判。第三，干系人管理计划的价值在分类，高权低益只需令其满意、低权高益才需随时告知。只有把规范落到计划、把计划落到动作，二次供水的监管信息才能实时连到每一处小区的出水口。而施工—运维联合值班这类机制，本质也是把 " 谁该在何时被通知 " 写进了计划，而不是靠微信临时喊人。

表 1 沟通管理计划要点

计划要素	本项目具体约定
信息需求清单	住建/水务/卫生监督三类监管指标、供水企业运行数据共 9 类 47 项须对齐
发布节奏	建设单位月会、供水企业与物业周例会、施工单位双周安全会
会议体系	阶段评审会、政策跟踪周会、施工—运维联合值班会
报告机制	里程碑与阶段评审向主管汇报，水质预警实时推送相关方
责任与备份	沟通单一责任人制，项目经理总责，每项指定唯一责任人与备份人
预算与资源	沟通专项时间约 6%，费用 1.6%（约 8.6 万元）来自合同额
升级路径	超时未闭环自动升级至建设单位协调

表 2 干系人管理计划

干系人	权力—利益定位	关键沟通诉求	参与策略与频率
建设单位主管、住建水务领导	高权高益	进度与合规决策	重点管理，每月专题会 + 阶段材料提前 3 天
财政、审计部门	高权低益	资金与合规监督	令其满意，每月简报邮件
3 家供水企业、200 余小区物业、一线运维	低权高益	数据对齐与变更同步	随时告知，周例会 + 专属群日更
施工单位售后、培训学员	低权低益	公告与变更提醒	监督即可，双周公告