122_皖北某区县级轨道交通运维系统信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

皖北地区某区县的轨道交通运维长期依赖纸质台账与人工派单，设备巡检记录、故障报修、备件库存等数据分散在各班组与调度中心手中，数据初始化工作量巨大，系统割接又必须在夜间有限的窗口内完成，一线运维人员信息化基础薄弱，操作习惯迁移阻力大。为把轨道交通运维数字化，该地区交通运输主管部门于 2023 年 11 月发起了区县级轨道交通运维系统信息系统项目，经公开招标由我司承建，合同额 1380.24 万元，建设周期 13 个月，我作为项目经理全面负责项目全过程管理。

项目建设目标是整合设备运维数据，实现巡检在线化、报修流程化、备件管理可追溯。建设内容包括设备台账、巡检管理、故障报修、备件管理、统计分析与报表五个模块，并与调度中心及各车站系统对接。技术方案中，平台按同城双中心多活容灾架构建设，微服务调用经 Istio 服务网格治理并支持灰度发布，运维数据由 GaussDB 承载，热点数据由分布式缓存加速，前端交互基于 Vue3 组件体系实现，后端服务以 Java 17 与 Spring Boot 构建，应用部署在市政务云信创环境，并完成等级保护三级安全建设。项目团队按矩阵型组织搭建，全队 17 人，除我之外设系统架构师、需求分析师、开发工程师、测试工程师、实施运维与数据治理等岗位，按模块规模与接口数量配置到位。项目于 2024 年 12 月通过终验，上线后预警事件平均处置时长缩短 55%，业务差错率由 2.7% 下降至 0.3%，数据自动核验比例由 42% 提升至 91%。

我作为本项目的项目经理，负责从启动到收尾的全过程管理，其中沟通管理贯穿始终。项目交付的成果包括可运行的轨道交通运维系统、与调度中心及各车站的对接接口、系统源码与全套文档，以及面向一线运维人员的操作培训。这个项目涉及调度、班组、备件与外部厂商多方，信息稍一不通，巡检与报修就衔接不上，信息传递工作从第一天起就是团队的主线。本文按理论认识、实践做法、反思改进三层递进展开。

一、对沟通管理的理论认识

从理论上讲，项目沟通管理由三个过程组成：规划沟通管理、管理沟通与监督沟通。规划沟通管理解决的是信息需求怎么摸、传递方式怎么定的问题，管理沟通解决的是信息怎么发出、反馈怎么收回的问题，监督沟通解决的是信息传递有没有效果、要不要调整的问题。三个过程一环扣一环，构成从计划到执行再到改进的完整回路，缺了任何一个环节，信息链路都会出现断点。

从理论上讲，沟通渠道的选择直接影响信息传递的效果。项目中的沟通渠道可以按信息形态分为书面与口头两类：书面渠道包括邮件、报告、会议纪要等，好处是内容留痕、便于回溯、责任清晰，弱点是制作耗时、反馈链路长；口头渠道包括电话、面对面、即时语音等，好处是响应快、能即时澄清，弱点是口说无凭、容易失真。书面渠道适合传递结论性、契约性信息，口头渠道适合传递过程性、协作性信息，二者配合才能既保证信息准确又保证响应及时，这也是本项目在信息量大、参与方多的现实下坚持的分类原则。从理论上讲，沟通方法与技巧的运用同样关键：面对复杂敏感的问题宜当面沟通，需要留痕追责的宜书面沟通，日常协作宜即时沟通，多方同步宜会议沟通，关键在结合场景灵活切换，而不是固守一种方式。本项目调度、班组与厂商并存，信息流向复杂，正需要这种方法与渠道的搭配，才能让信息既快又稳地到达目的地。

二、沟通管理的实践做法

规划沟通管理环节，我依据章程与干系人登记册，召集骨干成员开了沟通规划专题会。会上先用亲和图把各方信息需求逐条归类，按调度中心、运维班组、备件管理、外部厂商、主管部门五类聚拢，各类需求的侧重点一目了然。针对一线运维人员信息化基础薄弱的现实，我们在沟通管理计划里专门附了一份通俗术语对照表，把接口、并发这类技术词翻译成业务语言，比如把接口对接解释成系统之间怎么传数据，一线人员听一遍就明白。计划中对信息传递的节奏与载体做了约定：主管部门每月一次专题汇报，调度中心每周一次例会加每日任务推送，外部厂商联调期间每周两次碰头会，项目周报、会议纪要等模板一并固化下来，让信息流动有章可循。

管理沟通环节，我们按计划把信息及时发布到位。每周五把进度周报推送给主管部门与各部门，写明当前进度、待办风险与下一步安排，重要事项同时用电话向负责人确认收到；联调期间组织外部厂商每周两次碰头会，把接口状态与问题责任当面确认清楚。一次设备台账模块的联调中，厂商反馈接口多次联调失败，双方一度各执一词，我们没有急着争对错，而是请双方把联调日志摆出来逐条核对，把分歧聚焦到数据格式不兼容这一个根因上，随即统一了数据规范，问题当场解决。为找准沟通中的堵点，我让助理整理了两个月来的问题清单，按反馈类型画成直方图，图形显示进度不同步类的占比最高，据此我们把厂商联调会加密到每周两次，并固定了会议纪要模板，会后 24 小时内发出待办清单，此后的沟通顺畅了许多。

监督沟通环节，我们每月评估一次沟通成效：统计周报的反馈率、例会纪要的落实率与干系人满意度，把这些数据带进月度例会一起复盘。一次评估发现部分厂商例会参与率明显下降，我没有简单加大沟通频率，而是用面向 X 设计矩阵重新评估信息传递方式，从及时性、便捷性、可追溯性三个维度给会议、电话、即时消息、邮件逐一打分，结果显示日常信息用即时消息群传递最合适，于是把厂商的日常同步改为群内推送，会议只保留里程碑节点，参与率明显回升。监督沟通让我们每月都检查信息传递是否还在起作用，而不是发完文件就不管了。针对一线运维人员倒班频繁的特点，我们还把例会安排在倒班交界的时段，允许请假班组事后补交书面意见，参与率因此稳定在高位，这条经验后来也被写进了公司沟通管理模板。

三、反思与改进

项目顺利通过终验，预警处置时长缩短 55%，差错率由 2.7% 降到 0.3%，自动核验比例提升到 91%，主管部门对系统可用率给出了较高评价，但回顾仍有值得检讨之处。其一，规划阶段的干系人需求摸排依赖集中开会，运维班组倒班频繁，到场率始终不理想，若一开始就采用轮班访谈加书面征询的方式，需求梳理会更扎实。其二，通用术语表完成得偏晚，前期确实发生过因术语理解不一致导致的返工，教训是这类基础文档应该在规划阶段就定稿，而不是等出了问题再补。其三，监督沟通的观测点偏少，主要盯着反馈率，对信息是否真正被理解的测量不足，后来补充了随机回访才补齐这块短板。这些经验都已沉淀进公司的经验教训库。

综上，沟通管理的成败不在于文件发了多少、会开了几场，而在于信息是否真正到达了需要它的人：亲和图把需求梳理成条理，直方图让堵点分布一目了然，面向 X 设计矩阵让渠道取舍有了依据，监督沟通让这套机制不断自我修正。项目在数据初始化量大、割接窗口紧、用户基础弱的多重约束下按期交付，预警处置时长缩短 55%，差错率降到 0.3%，自动核验比例提升到 91%，沟通在其中功不可没，这正是本项目留给我最深的启示。这套以规划定规则、以管理促流动、以监督促优化的做法，后来也被复制到公司其他交通类项目，验证了它的可复制性。