029_冀中某省级赛事指挥系统信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

本文以冀中某省级赛事指挥系统信息系统项目为例，按规划沟通管理、管理沟通、监督沟通三个过程为主线，论述我在该项目中开展沟通管理的做法。该项目由该地区文化和旅游主管部门发起，合同额 786.46 万元，2023 年 11 月启动，建设周期 13 个月，团队 20 人，采用低代码平台、微服务网关、OceanBase 与 RocketMQ 构建，我担任项目经理。项目面临跨部门业务口径不一致、法定验收时点刚性致进度压缩、赛期并发峰值集中三项挑战。我依次运用逐项检查、根本原因分析与散点图三类工具支撑三个过程，并制作了沟通管理计划与沟通记录表。项目于 2024 年 12 月通过终验，场馆设备在线率由 83% 提升至 98.5%，保障经费结算差错连续 12 个月零发生，运维人工巡检投入下降 60%。

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

该地区承办省级综合性运动会，设竞赛场馆 27 个，涉及协办部门 18 个，参赛与工作人员约 2.6 万人。此前赛事保障依靠电话调度与纸质台账，场馆设备状态不透明，突发情况上报层层转达，指挥层难以掌握全局。为提升赛事组织与应急指挥能力，该地区文化和旅游主管部门作为建设单位发起本项目，我方中标承建，我被任命为项目经理。

系统建设内容包括赛事资源一张图、场馆设备物联监测、赛程与人员调度、应急事件上报与处置、保障经费结算与统计五个子系统。技术实现上，前端采用 Vue 3 与 TypeScript，并借助低代码平台搭建表单与统计看板；后端采用 Java 17 与 Spring Cloud，经微服务网关统一完成鉴权、路由与限流；OceanBase 分布式数据库承载赛事、场馆与设备数据；设备告警、调度指令与结算通知等异步链路由 RocketMQ 消息中间件解耦；全部服务容器化部署于政务云。

交付成果包括：系统源代码与部署包；需求规格说明书、概要与详细设计说明书、数据库设计说明书、接口规范；测试方案与测试报告；上线方案与回退预案；《用户操作手册》《系统运维手册》《赛事保障操作规程》；面向指挥层、场馆值守、协办部门三类角色共 8 场、覆盖 342 人次的培训服务；以及 12 个月免费运维支持。

团队 20 人按矩阵型组织，下设需求组、开发组、物联接入组和测试组，另配专职配置管理员 1 名，负责配置项标识、基线管理与版本发布控制，配质量保证人员 1 名。我在预算编制阶段即把沟通列为独立投入：安排 30 人日用于口径协调会、驻场值守与培训，列支 15.8 万元用于会议保障、资料印制与短信通道，并在 WBS 中设立 " 沟通与协同 " 工作包。

二、规划沟通管理

规划沟通管理是基于干系人的信息需求、可用的组织资产以及项目的具体需求，为项目沟通活动制定恰当方法和计划的过程，其作用在于让后续每一次沟通都有章可循，避免临时起意与信息漏发。

本项目开局遇到的第一个难题，是 18 个协办部门对同一业务对象的口径互不一致。仅 " 场馆 " 一词，体育部门指竞赛场馆，公安部门含周边安保区域，住建部门还包含在建配套设施。口径不一致，信息发出去也对不上。

为此我采用逐项检查，即依照预先编制的核对清单，对每一项内容逐条比对确认，既不抽样也不作归并推断。需求组把 18 个部门提交的 214 项信息需求全部展开，逐项核对数据项名称、统计口径、更新频率、责任部门四个要素。检查结果为：口径冲突 41 项、责任主体不清 23 项、多头重复索取 17 项，合计 81 项。我将其列为口径待办清单，逐项组织提出方、使用方与技术方三方确认，形成《赛事数据口径对照表》并纳入配置基线。这项工作耗时三周，但为后续所有沟通提供了共同语言。

在此基础上，我完成识别干系人，登记 9 类干系人、147 名代表，逐一标注其关心的信息、决策权限与可用渠道，并据此编制沟通管理计划，逐条明确信息内容、面向对象、载体、时间安排、组织者与归档去向。计划有两条自我约束：一是所有例会安排在工作时段，常规期为每周二上午 9:30 与每周四下午 15:00，赛前保障期改为每日 8:00 晨会 20 分钟；二是不设与项目无关的信息推送条目，每一条信息都必须对应一个明确的决策或动作，避免以 " 信息共享 " 之名制造噪声。

计划编好只是起点，真正的考验出现在执行阶段。

三、管理沟通

管理沟通是确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程，其作用在于让计划中的沟通安排真正落地。

本项目工期紧张，赛事开幕日期由上级确定、不可推迟，系统必须在开幕前 45 天完成实战演练，属于典型的刚性时点约束。我据此建立三级沟通机制：项目组每日晨会解决当日阻塞，与 18 个协办部门每周召开联席会推进跨部门事项，每月向建设单位与监理汇报总体态势。凡涉及技术判定的议题，我均会同相关技术负责人共同参加，会后当日形成纪要并线上分发确认。

执行中出现了一起颇具代表性的事件。第 5 个月演练时，指挥大屏显示场馆设备在线率 91%，而场馆现场清点为 76%，两个数字相差悬殊，各方相互质疑数据可信度。我没有急于让开发人员改数，而是组织开展根本原因分析，即通过逐层追问识别问题的深层成因，而不停留在表面现象。沿着 " 现象—直接原因—深层原因 " 追溯：现象是两侧数字不一致；直接原因是心跳超时阈值不同，我方按 15 分钟判定离线，场馆侧按 5 分钟判定；继续追问阈值为何不同，发现口径对照表中 " 在线 " 一项只写了名称与责任部门，未写判定阈值；再追问为何漏写，根子在于当初口径确认会只通知了各部门联络员，未请设备运维人员到场，而阈值恰恰属于运维层面的知识。

据此我采取三条措施：一是补齐阈值定义并纳入配置基线，同步修订对照表；二是把口径确认会的参加范围由单一联络员扩展为业务与运维双岗；三是在沟通管理计划中增列规则，凡技术口径类议题须双岗共同签认方可生效。整改后两侧数字完全一致，设备在线率被纳入统一考核口径，并最终由 83% 提升至 98.5%。

同期我还开展了管理干系人工作。某协办部门担心系统上线后本单位的工作疏漏被实时暴露，长期消极提供数据。我与其负责人一对一沟通，明确系统的首要用途是保障调度而非追究责任，异常记录仅在指挥层可见、不作为考核依据，并邀请该部门参与告警规则评审。该部门态度随之转变，主动补报了三个场馆的设备台账。

信息发出去、议题定下来之后，还需要一套办法判断沟通究竟是否有效，这正是监督沟通要解决的问题。

四、监督沟通

监督沟通是确保满足项目及其干系人信息需求的过程，其作用在于及时发现沟通偏差并加以纠正。

赛期并发压力集中，开幕式与决赛日的告警和调度指令高度密集，沟通稍有延误便直接影响现场处置。我需要弄清楚：究竟哪些沟通特征真正决定了现场效果。为此我选取演练期与赛期共 43 项保障事项作为样本，以 " 事项提前告知天数 " 为横轴、" 该事项现场发生差错次数 " 为纵轴绘制散点图。图上散点呈现明显的负相关趋势：提前告知不足 1 天的 11 项，平均差错 3.2 次；提前 1 至 3 天的 18 项，平均差错 1.4 次；提前 3 天以上的 14 项，平均差错仅 0.3 次。少数偏离趋势线的离群点经回溯，均因接收人临时变更而未同步所致。

这一结果把 " 早点通知 " 这句常识变成了可执行的规则。我随即把沟通管理计划中保障事项的告知提前量由原定 24 小时统一提高到 72 小时，对确实无法提前的紧急事项增设电话双向确认环节，并要求接收人变更须在 24 小时内更新至干系人登记册。

与此同时，我按月更新干系人参与度评估矩阵，将各部门的当前参与度与期望参与度比对，对持续低于期望的 4 个部门逐一走访了解原因。赛期共处置应急事件 268 起，平均处置时长较演练期缩短一半以上；全程累计形成沟通记录表 193 份，闭环率 100%。

五、沟通管理计划与沟通记录表的制作

沟通管理计划采用七列结构，逐行回答 " 什么信息、给谁、用什么载体、什么时候、谁组织、存到哪里 "，每条均指定唯一责任人，计划本身作为配置项管理，任何调整须走变更流程并通知全部接收方。沟通记录表采用九列结构，固定记录流水号、日期、场合、讨论要点、到场单位、决定意见、后续动作、限期与核销情况；填写规则要求会后当日提交、次日各方线上确认，后续动作自动进入跟踪清单，逐周复核直至核销。两份工作成果均随项目文档一并交付建设单位。

六、结项成效与心得体会

本项目 2023 年 11 月启动，2024 年 6 月完成主体开发与系统测试，2024 年 7 月完成赛前实战演练，2024 年 8 月赛事期间全程保障，2024 年 9 月至 11 月完善优化并试运行三个月，2024 年 12 月通过终验，全程 13 个月，与合同工期一致。核心成效为：场馆设备在线率由 83% 提升至 98.5%；保障经费结算差错连续 12 个月零发生；运维人工巡检投入下降 60%。

三点体会。其一，口径问题表面看是技术问题，实质是沟通问题。那 41 项口径冲突若不在规划阶段被逐项检查出来，必然在赛期以更高代价爆发，届时已无时间从容处理。其二，找沟通问题的根子要往下多追两层。若停在 " 阈值设错了 "，只能改一个参数；追到 " 确认会没请对人 "，才能改掉一项制度。其三，沟通的提前量本身就是质量。散点图揭示的负相关关系，让我第一次把告知时机当作可度量、可写入计划的要素，而不是凭经验掌握的分寸。

表 1 沟通管理计划（节选）

序号	沟通内容	面向对象	载体与格式	时间安排	组织者	归档去向
1	项目晨会	项目组全体	口头，站立会	每日 8:00，20 分钟	项目经理	当日待办清单
2	跨部门联席会	18 个协办部门联络员	沟通记录表	每周二 9:30	项目经理	纪要库
3	数据口径变更通告	提出方、使用方、技术方	对照表修订单	变更批准后 4 小时内	需求组长	配置库
4	保障事项告知	相关场馆与协办部门	事项单，含责任人与时限	事项发生前不少于 72 小时	调度负责人	事项台账
5	月度汇报	建设单位、监理	汇报材料 + 一页表	每月首个工作日上午 10:00	项目经理	项目文档库
6	设备告警推送	场馆值守、指挥层	系统消息 + 短信	触发即时，5 分钟内二次提醒	系统自动	告警日志

表 2 沟通记录表（节选）

流水号	日期	场合	讨论要点	到场单位	决定意见	后续动作	限期	核销情况
SS-2024-036	2024-03-12	口径确认会	" 场馆 " 与 " 在线 " 的判定标准	体育、公安、住建、项目组	统一采用竞赛场馆口径，在线阈值待补	补充阈值定义（物联接入组长）	2024-03-20	已核销
SS-2024-081	2024-04-18	演练复盘会	大屏在线率与现场清点不一致	5 家场馆、指挥中心、项目组	阈值统一为 5 分钟并入基线，确认会加设运维岗	修订对照表与计划（需求组长）	2024-04-26	已核销
SS-2024-117	2024-06-05	一对一沟通	某部门数据报送消极	项目经理、该部门负责人	异常记录仅指挥层可见，不作考核依据	邀其参与告警规则评审（项目经理）	2024-06-14	已核销
SS-2024-165	2024-08-09	赛期调度会	保障事项告知提前量不足	调度组、12 家场馆	告知提前量由 24 小时提高至 72 小时	修订沟通管理计划（项目经理）	2024-08-13	已核销