093_鄂西某县域融媒体调度平台信息系统项目综合管理

ONEPSOFT | 软考学习知识库

---

鄂西地区某县域的融媒体中心汇集了电视、广播、网站、微信、短视频等多类媒体渠道，各平台长期分散运营，选题策划靠口头沟通，素材共享靠网盘与 U 盘拷贝，任务派发与进度跟踪靠人工协调，一线采编人员信息化基础薄弱，操作习惯迁移阻力大，多家外部媒体单位联调时进度同步也常出问题。县里要求融媒体平台尽快建成投用，涉及的单位和人员又多，沟通稍有疏忽就会影响整体进度。为把融媒体生产调度统一起来，该传媒集团技术中心于 2022 年 9 月发起了县域融媒体调度平台信息系统项目，经公开招标由我司承建，合同额 480.72 万元，建设周期 14 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合选题、素材、任务与发布流程，实现策划在线化、调度自动化、发布一体化。建设内容包括选题策划与任务派发、素材共享与编目、多平台发布调度、直播协同、统计分析与报表五个模块，并与各媒体平台及多家外部供稿单位对接。终端设备种类繁多、兼容性适配工作量被低估，这些约束在规划阶段就写进了风险清单。技术方案采用低代码平台承载表单与流程的快速配置，前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，各微服务经微服务网关统一鉴权与限流，数据存储选用 OceanBase 分布式数据库，跨系统的消息推送由 RocketMQ 承担，应用中间件采用东方通 TongWeb，整体部署在县政务云信创环境，按等级保护三级完成安全建设。项目团队共 20 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 9 人、测试工程师 3 人、实施与运维工程师 2 人、质量保证与配置管理各 1 人，并设产品经理 1 人负责需求对接。项目于 2023 年 11 月通过终验，上线后资金结算差错实现连续 12 个月零发生，跨部门数据共享接口调用量月均突破 120 万次，业务差错率由 2.7% 下降至 0.3%。

沟通是项目成功的桥梁，这个项目干系人横跨采编、技术、运营与外部供稿单位，各方信息需求差异巨大，沟通不畅必然带来返工与误解。县里对项目进度有明确要求，外部单位又不归我们管，沟通稍不到位，进度就会受影响，一次联调需求没说清，就可能多出一周的返工。下面我从理论认识、实践做法、反思改进三个层面，谈谈本项目在沟通管理上的思考与作为。

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

从理论上讲，项目沟通管理包含规划沟通管理、管理沟通、监督沟通三个过程，其目的是确保信息在干系人之间及时、准确地流动。规划沟通管理回答对谁说什么、怎么说的问题，管理沟通回答怎么把信息发出去的问题，监督沟通回答信息传递是否有效的问题，三者构成完整的闭环。项目沟通的难点往往不在信息量，而在信息差——各方掌握的信息不一致，误解与冲突就会随之而来，这正是沟通管理要消除的核心问题。

从理论上讲，沟通管理的起点是干系人的信息需求差异：领导要的是宏观态势，一线采编要的是任务与素材，外部单位要的是接口与进度，同一份信息对不同的人意义完全不同，因此沟通必须分层分类，不能一套模板打天下。

从理论上讲，沟通渠道与工具的选择同样关键，面对面的互动、定期的书面报告与自助式的信息获取各有适用场景，渠道选错了，再好的内容也传不到位。沟通管理是干系人管理的落地手段，没有沟通，识别再全的干系人也只是一纸名单。分层沟通加上渠道匹配，才构成完整的沟通方案，这也是本项目沟通规划的基本思路。

二、沟通管理的实践做法

规划沟通管理阶段，我依据章程与干系人登记册，组织产品经理与骨干成员召开沟通规划专题会议。先用亲和图把各类干系人的信息需求逐条归类，按内部分成了中心领导、采编一线、技术运维、外部供稿四类，每类需求的侧重点一目了然，例如中心领导关注整体进度与重大风险，采编一线关心任务派发与素材流转，外部单位关心接口联调进度。针对采编人员信息化基础薄弱的现实，我们在沟通管理计划中专门增加了通用术语表章节，把接口、并发这类技术词翻译成业务语言，例如把素材自动编目解释为素材进来自动打标签、按关键词就能找到，让一线人员一听就懂。计划中还明确了沟通的频率与渠道：领导层每月一次专题汇报，采编一线每周一次例会加每日任务推送，外部单位联调期间每周两次进度同步会，并配套了项目周报、会议纪要等固定格式，让沟通有章可循。沟通计划还配套了项目信息流向图，谁向谁报什么、多久一次，一目了然，新加入的成员照着图就能上岗。

管理沟通阶段，我们按计划把信息及时发布到位。每周五的进度周报推送给中心领导与各部门，如实反映进度、风险与下一步安排；联调期间组织外部单位每周两次同步会，把双方进度、接口状态与问题责任当面说清。周报之外，我们在关键节点还组织了专题沟通会，把里程碑达成情况向各方通报，让每一阶段的成果都及时被看见。一次直播协同功能的联调中，外部视频平台反馈接口联调多次失败，双方一度互相推责，我没有纠缠对错，而是组织双方按联调记录逐项核对，把失败集中在素材格式不兼容这一个根因上，随即统一了转码规范，问题当场解决。为了找准沟通中的堵点，我用直方图统计了一段时间内的问题反馈类型，图形显示进度不同步类占比最高，据此把联调例会固定为每周两次并形成会议纪要模板，此后的沟通顺畅了许多，接口联调的返工次数也随之下降。

监督沟通阶段，我们每月评估一次沟通效果：查看周报的反馈率、例会纪要的落实率与干系人满意度，把数据纳入月度例会。一次评估发现外部单位的例会参与率下降，反馈率走低，我用面向 X 设计矩阵对沟通方式做了调整，按面向及时性、面向便捷性、面向可追溯性三个目标对会议、电话、即时消息、邮件四种方式打分，最终把外部单位的日常同步改到即时消息群，会议只保留关键节点，参与率与反馈率明显回升。监督沟通让沟通管理本身也在不断优化，而不是发完文件就不管了。监督沟通的数据还反向指导了计划修订，沟通计划本身不是一成不变的，而是随项目推进滚动更新。

三、反思与改进

项目顺利通过终验，但回顾仍有值得检讨之处。其一，需求阶段的沟通过度依赖会议，采编一线任务繁忙，参与率不高，若改用短平快的访谈加试用反馈，需求挖掘会更充分。其二，通用术语表制定得偏晚，前期已有几次因术语理解不一致导致的返工，若在规划阶段就完成，可以避免。其三，监督沟通的指标偏少，主要看反馈率，对信息理解程度的测量不够，后来补充了抽查回访。其四，与外部单位的沟通一度依赖电话，信息留痕不足，问题追溯困难，改成书面纪要后明显改善。这些经验都已沉淀进公司的经验教训库，为后续同类项目提供了参照。

综上，沟通管理的价值不在于发多少份文件、开多少场会，而在于让对的人在对的时间收到对的信息：亲和图理清了需求分类，直方图暴露了堵点分布，面向 X 设计矩阵让渠道选择有了依据，监督沟通让这套机制不断自我修正。项目在外部单位多、用户基础弱、终端形态杂的多重约束下按期交付，差错率由 2.7% 降到 0.3%，资金结算差错连续 12 个月零发生，沟通在其中功不可没。把话说清楚、把信息传到位，看似朴素，却是项目成功最牢靠的地基。