027_东北某产业园区仪器设备开放共享平台信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

本文以东北某产业园区仪器设备开放共享平台信息系统项目为例，论述我对信息系统项目沟通管理的认识与实践。该项目由该科研机构信息中心发起，合同额 168.72 万元，2023 年 7 月启动，建设周期 8 个月，团队 22 人，采用低代码平台、微服务网关、OceanBase 分布式数据库与 RocketMQ 消息中间件构建，我担任项目经理。项目推进中集中暴露出三个难点：使用群体信息化基础薄弱、多家外部单位联调责任界面复杂、终端设备种类繁多致适配工作量被严重低估。我以规划沟通管理、管理沟通、监督沟通三个过程为主干，分别配合帕累托图、质量审计与统计抽样逐一化解，并制作了沟通管理计划与沟通记录表。项目于 2024 年 2 月一次性通过验收，用户满意度测评由 78 分提升至 94 分，预警事件平均处置时长缩短 55%，人工重复录入工作量下降 68%。

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

该产业园区内聚集高校院所、第三方检测机构与企业实验室共 47 家，在用大型科研仪器 386 台套。长期以来设备信息分散，机时靠电话预约，台账靠人工逐级汇总，闲置与重复购置并存。为盘活存量仪器资源、提高机时利用率，该科研机构信息中心作为建设单位发起本项目，我方中标承建，我任项目经理。

系统建设内容包括设备资源目录、在线预约与机时排程、扫码开机与用能计量采集、共享结算与补贴核算、绩效统计与预警五个子系统。技术实现上，前端采用 Vue 3 与 TypeScript，并借助低代码平台快速搭建表单与统计报表；后端采用 Java 17 与 Spring Cloud 微服务框架，经微服务网关统一完成鉴权、路由与限流；数据层选用 OceanBase 分布式数据库承载设备台账与机时流水；设备状态上报、预约提醒、结算通知等异步链路由 RocketMQ 消息中间件解耦；全部服务以容器方式部署于园区私有云。

交付成果包括：系统源代码与部署包；需求规格说明书、概要设计与详细设计说明书、数据库设计说明书、测试方案与测试报告、上线方案与回退预案；《用户操作手册》《系统运维手册》《设备接入规范》；面向管理方、设备管理员、科研用户三类角色共 6 场、覆盖 214 人次的培训服务；以及 12 个月免费运维支持。

团队 22 人采用矩阵型组织，下设需求组、开发组（含低代码开发小组）、设备接入组、测试组，另配专职配置管理员 1 名，负责配置项标识、基线管理与版本发布控制，配质量保证人员 1 名、文档与培训岗 1 名。在编制项目预算时，我把沟通当作一项需要投入的正式工作单独列支：安排 28 人日用于培训、联席会与现场值守，列支 12.4 万元用于短信平台、培训场地与资料印制，并在 WBS 中单设 " 沟通与培训 " 工作包，明确责任人与交付物。

二、难点一：使用群体基础薄弱，沟通如何真正到达人

47 家单位的设备管理员多为兼职的实验教师和技术员，年龄偏大，长期依赖电话与纸质登记本，对线上预约存在明显抵触。试点第一周即收到咨询 132 条，近半是 " 不会用 "" 不知道从哪点进去 "。

规划沟通管理，是根据干系人的信息需求、可用的组织资产以及项目自身特点，为项目沟通活动制定恰当方法与计划的过程。我先完成识别干系人，即识别能影响项目或受项目影响的个人、群体和组织，并分析记录其利益、参与度与影响力，共登记 7 类干系人、186 名代表，逐一标注其关心的信息、可用渠道与接受能力。

内容与渠道究竟该向哪里使劲，我没有凭经验拍板，而是用帕累托图作了定位。我把试点前两个月累计的 1268 条咨询与投诉工单按问题类型编码归并为 11 类，按频次降序绘图并叠加累计百分比曲线。结果显示 " 操作步骤不清 " 占 32.4%、" 预约规则不明 " 占 27.1%、" 扫码开机失败 " 占 19.1%，三类合计 78.6%，其余 8 类合计仅 21.4%。据此我调整了沟通内容的优先级：把前三类做成三张一页纸图解和三段各不超过 90 秒的短视频，通过设备管理员微信群与登录页弹窗直达；其余低频问题归入帮助中心，不再占用宣贯时间。

此阶段暴露出一个贯穿全程的典型问题——" 预约放空 "。试点第三周，用户预约机时却不到场、设备空转的比例高达 23.6%。对照帕累托图上排第二的 " 预约规则不明 "，我判断这并非用户不守约，而是沟通缺位：平台默认用户会查看系统内消息，而多数设备管理员根本不登录系统。我随即在沟通管理计划中补入 " 预约提醒 " 这一信息条目，明确提醒内容、发送时点（提前 24 小时与 2 小时各一次）、渠道（短信加群机器人）、责任人与失败重发规则。计划补齐了，但落地要靠跨单位协同，这就引出了第二个难点。

三、难点二：多方联调界面复杂，沟通如何说得清责任

本项目需与园区一卡通系统、用能计量平台、科技管理部门补贴申报系统以及 5 家仪器厂商的设备管控软件对接，涉及外部单位 9 家。开工首月，接口联调频现 " 约了没人来、来了没决定权、定了没人认 "，两周内因口头约定反悔导致返工 3 次。

管理沟通，是确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督与最终处置的过程。我做了三件事。其一，建立每周三下午 90 分钟的联席例会机制，并提出 " 定人、定权、定时 " 要求，各方须书面指定一名有技术决策权的代表。其二，制作并强制使用沟通记录表，固定记录编号、时间地点、主题、参与方与代表人、结论、待办事项、责任人、约定完成时间、闭环状态九个字段，会后 4 小时内由记录人整理、24 小时内各方线上确认，逾期未提出异议视同认可。其三，同步开展管理干系人，即与干系人沟通协作以满足其需求与期望、处理问题并促进其合理参与；针对某厂商担心开放接口会削减其售后收益的顾虑，我请建设单位出面明确共享数据的使用边界，并在协议中约定其原有运维服务不受影响，该厂商由观望转为主动配合。

机制立起来后是否被真正执行，需要独立检验。项目进行到第 4 个月，我请公司质量保证人员对沟通过程实施了一次质量审计，即对项目管理过程与规程执行情况开展结构化的独立审查，判断其是否符合既定政策与程序。本次审计抽查沟通记录表 42 份，发现三类偏差：字段填写不全 9 份，占 21.4%，主要缺失 " 约定完成时间 "；结论表述含糊、无法判定是否达成 6 份，占 14.3%；待办事项超期未更新状态 11 份，占 26.2%；外部单位线上确认率仅 61%。

针对审计发现，我采取三条纠正措施：一是将记录表由自由文本改造为低代码平台上的结构化表单，" 责任人 " 与 " 约定完成时间 " 设为必填，不填无法提交；二是待办事项自动同步至项目看板，临期与超期由 RocketMQ 推送提醒；三是与外部单位补充约定 " 记录表确认即视为技术口径确认 "。第 6 个月复审显示，字段完整率升至 98.1%，超期未更新降至 4.8%，外部确认率升至 96%。

预约提醒功能正是在这一机制下落地的。它需要一卡通系统提供人员在岗状态、需要厂商软件回传开机状态，牵涉三方。我将其列为联席会 1 号议题，用记录表逐条写明 " 谁在什么时点提供哪个字段 "，三方代表确认后纳入配置库作为接口基线。此前扯皮两周的事，一次会议即告落定。然而信息发出去了，是否被收到、被理解，仍需持续检验。

四、难点三：适配工作量被低估，沟通如何盯得住偏差

合同清单载明需接入 6 类设备管控终端，实际进场清点却发现在用终端 19 种，其中 4 种已停产、无厂商技术支持，适配工作量较原估算高出一倍以上，排期必须重排。此时最大的风险不在技术，而在 47 家单位对 " 我的设备什么时候能接上 " 的预期失控。

监督沟通，是确保满足项目及其干系人信息需求的过程。我按厂商与协议类型把 386 台套设备划分为 5 批，编制分批接入排期表逐批公布，并承诺排期一经公布不因我方内部原因后移。

排期公布两周后，我用统计抽样检验其触达效果，即从目标总体中随机选取部分样本进行核查，据以推断总体特征。我从 47 家单位的 118 名设备管理员中随机抽取 40 名开展电话回访，核查其对本单位设备所属批次与预计接入时间的知悉情况，结果准确知悉率仅 57.5%。追问后发现，排期表是以 PDF 附件形式发在群里的，不少人在手机上打不开或不愿翻找。我随即改变发布形式：在平台首页按账号生成 " 我的设备接入进度 " 个性化视图，登录即见；每完成一批，向该批次联系人推送一条不超过 70 字的短信完成通知。四周后再次随机抽取 40 名回访，知悉率升至 92.5%。

与之并行，我按月更新干系人参与度评估矩阵，将 9 家外部单位与 47 家用户单位的当前参与度同期望参与度比对，对偏离的 6 家逐一处置，其中 2 家因人事变动联系人失联，经建设单位协调后重新指派。预约放空率也被纳入周报作为沟通有效性的量化指标持续跟踪，自提醒功能上线后逐周下行，第 16 周起稳定在 4.2% 以下。这让我确信，用户并非不配合，而是此前从未被有效告知。

五、结项成效与心得体会

项目于 2024 年 2 月完成终验，交付物一次性通过评审。三项核心指标为：用户满意度测评由 78 分提升至 94 分；依托统一告警与提醒机制，预警事件平均处置时长缩短 55%；台账与机时数据自动归集，人工重复录入工作量下降 68%。全程累计形成沟通记录表 176 份并全部闭环，未发生因信息不对称引发的争议。

回顾整个过程，我有四点体会。第一，沟通问题要用数据定位。帕累托图让我看清 78.6% 的困扰集中在三类问题上，有限的宣贯资源因而用在了刀刃上；若平均用力，多半会消耗在低频问题上。第二，沟通的可靠性来自记录而非记忆。九字段记录表配合必填校验、自动提醒与各方确认，把口头约定固化为可追溯的书面结论，这是外部单位众多时最有效的防扯皮手段。第三，发出不等于收到。57.5% 这个抽样结果提醒我，衡量沟通成效的标尺应当是接收方的知悉率与行为改变，而不是发送方的动作完成率。第四，沟通计划必须允许被修订。" 预约提醒 " 是上线后才补进计划的条目，若固守初版计划，放空率不可能降下来。

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

信息条目	接收方	内容与格式	渠道	频次/时点	责任人
项目周报	建设单位、监理	进度、风险、待决事项，一页表格	邮件 + 项目看板	每周五 17:00 前	项目经理
接口联调纪要	9 家外部单位代表	沟通记录表结构化表单	联席会 + 线上确认	每周三会后 4 小时内	记录人
设备接入排期	47 家单位设备管理员	批次、预计接入时间，个性化视图	平台首页 + 短信	公布后即时，变更即时	设备接入组长
预约提醒	预约用户、设备管理员	设备名称、时段、取消方式，短信文本	短信 + 群机器人	提前 24 小时、2 小时各一次	运营支持岗
操作图解与短视频	全体使用人员	三类高频问题一页纸图解、90 秒短视频	微信群 + 登录页弹窗	首发后按需补发	文档与培训岗
质量审计报告	建设单位、项目组	偏差项、整改要求与期限	邮件 + 专题会	第 4、6 个月各一次	质量保证人员

表 2 沟通记录表（节选）

编号	时间	主题	参与方与代表	主要结论	待办事项与责任人	约定完成	闭环状态
GT-2023-041	2023-09-06	预约提醒三方接口口径	一卡通方、A 厂商、本项目组	在岗状态由一卡通提供，开机状态由厂商回传，字段与时点写入接口基线	出具接口说明书（A 厂商技术负责人）	2023-09-13	已闭环
GT-2023-058	2023-10-11	停产终端适配方案	设备接入组、4 家用户单位	4 种停产终端改由采集网关旁路接入，单独排入第 5 批	补充采购网关 8 台（采购专员）	2023-10-25	已闭环
GT-2023-072	2023-11-08	沟通过程审计整改	质量保证人员、各组长	记录表改为结构化表单，两字段必填，超期自动提醒	表单改造上线（低代码组长）	2023-11-17	已闭环
GT-2023-095	2023-12-20	排期知悉率偏低专项	项目经理、运营支持岗	排期发布由 PDF 附件改为首页个性化视图并加短信通知	视图开发与短信模板报批（开发组长）	2024-01-05	已闭环