020_湘中某区县级家校互动服务平台信息系统项目沟通管理

ONEPSOFT | 软考学习知识库

---

摘要

湘中某区县级家校互动服务平台由当地教育主管部门发起，2023 年 10 月启动，工期 8 个月，合同额 786.72 万元，团队 14 人，2024 年 6 月通过验收。平台覆盖全区 126 所中小学与幼儿园、8.7 万名在校学生、6200 名教职工和约 14 万名家长。我在项目中担任项目经理。这个项目的干系人数量之大、层级之杂在我经历过的项目中是罕见的，而且其中最重要的一类——家长——既不受项目组管理，也不受学校强制约束，信息能否真正抵达完全取决于沟通设计是否得当。本文分三层展开：先阐述我对项目沟通管理概念体系的理解，再交代本项目中的具体做法及散点图、根本原因分析、逐项检查的运用，随后单列一节说明干系人管理过程与干系人管理计划，最后是反思与改进。

一、项目概况

该区县共有中小学与幼儿园 126 所，其中乡镇及以下学校 82 所。项目启动前，家校沟通完全依赖各校自建的微信群和 QQ 群，全区大小群组超过 4000 个，同一条通知常被多个群重复转发，格式、口径各不相同，家长抱怨 " 消息太多又找不到要紧的 "；学籍、考勤、体质健康、心理测评四类数据分散在四套系统中，教育局要做一次全区统计得让各校填表上报，一轮下来两周，且填报差错率长期在 2.7% 左右；长期缺勤、体质异常等需要及时干预的情况，往往要到月度汇总时才被发现。

2023 年 9 月立项，10 月启动，合同额 786.72 万元，工期 8 个月。交付内容包括：统一家校消息通道、学生成长档案、请假与考勤、心理与安全预警、教育局分析看板五个模块，以及与学籍系统、体质健康上报系统、校园一卡通、区级短信网关四方的对接。

技术上，后端为 Java 微服务，采用服务网格 Istio 实现服务治理与灰度发布；数据库为 GaussDB，配合分布式缓存应对早晚接送时段的考勤打卡高峰；系统按多活容灾架构部署于区教育云与市级备份中心；家长端为微信小程序，教师端为移动应用与网页双端，管理端前端采用 Vue 3。

团队 14 人：我任项目经理；业务组 2 人；开发 7 人；测试 2 人；数据治理与实施 3 人。项目三个难点是：126 所学校的历史数据质量参差不齐，清洗与治理规则难以统一；四家外部单位同时联调，进度同步与责任界面复杂；乡镇学校专线覆盖不全，偏远节点通信稳定性不足。

二、我对项目沟通管理的理解

从理论上讲，项目沟通管理包含规划沟通管理、管理沟通与监督沟通三个过程，分别解决 " 怎么沟通 "" 如何执行 "" 是否有效 " 三个层面的问题。在本项目的实践中，有三组概念对我帮助最大。

其一是沟通模型。基本的发送方与接收方模型包含编码、传递、解码、确认与反馈五个环节，任何一个环节都可能引入噪声。这个模型看似简单，却直接决定了我对本项目的判断：家校沟通失效，未必是学校没发通知（编码与传递环节），更可能是家长手机号过期（传递环节失效）或通知语言过于文件化让家长看不懂（解码环节失效）。找准是哪一环出问题，措施才不会打偏。

其二是沟通的维度划分。沟通可以按内部与外部、正式与非正式、垂直与水平、官方与非官方、书面与口头等维度区分。本项目中教育局对学校属于垂直正式沟通，学校对家长属于外部沟通，教师之间的经验交流属于水平非正式沟通。三类沟通的规则完全不同：垂直正式沟通要留痕、要有回执；对家长的外部沟通要通俗、要分时段；教师之间的非正式沟通则不宜过度管控，反而应当提供便利。把它们混在一套规则里管，一定会出问题。

其三是沟通管理计划与干系人参与计划的区别。前者规定信息的内容、渠道、频率与责任人，属于动作层面；后者规定对每一类干系人期望达到的参与状态和相应策略，属于策略层面。二者共享干系人登记册这一输入，但不能相互替代。

三、在本项目中的具体做法

用逐项检查控制接入质量。 126 所学校分五批接入，每批接入前必须通过《学校接入就绪逐项检查表》，共 14 项：管理员账号是否指定、教职工名册是否核对、班级与学生对应关系是否清理、家长手机号是否更新、校内网络带宽是否达标、一卡通设备是否在线、历史数据是否完成清洗、样例数据是否抽查通过、培训是否完成、应急联系人是否明确等。14 项全部通过才安排接入，不允许 " 先上线后补齐 "。第一批 20 所学校中有 6 所未通过，主要卡在家长手机号更新和历史数据清洗两项，延后两周接入。这个决定当时承受了一些压力，但后面四批的接入返工明显减少，全程未出现接入后回退的情况。

用散点图找出治理重点。 历史数据清洗初期，各校返工次数差别悬殊，有的一次通过，有的返工五六轮。我把 126 所学校的清洗返工次数与该校在用的独立系统套数作散点图，图上呈现清晰的正相关：在用系统在 3 套以上的学校，平均返工 4.2 次，而只用 1 套系统的学校平均仅 1.3 次。原因不难理解——系统越多，同一名学生在不同系统里的编码、姓名写法、班级归属越容易不一致，清洗规则难以统一。据此我调整了资源投放，把 3 名数据治理人员集中派驻到系统套数最多的 18 所学校现场作业，其余学校采用远程指导加模板自助的方式。调整后全区清洗工作提前 9 天完成，整体返工次数下降约四成。

用根本原因分析解决通知到不了的问题。 平台上线首月，消息送达率只有 81%，与预期差距很大。学校的第一反应是 " 家长不看 "，但我认为不能凭印象下结论。项目组抽取了 2000 条未读消息逐条追查，用根本原因分析层层追问：为什么未读？其中 1120 条为未送达而非未读。为什么未送达？短信通道退回与小程序未绑定各占一部分。为什么退回？家长手机号来自学籍系统，部分号码是入学时登记的，多年未更新。为什么小程序未绑定？绑定入口藏在三级菜单里，且需要家长自行输入学号，操作门槛偏高。继续追问退回原因，还发现短信网关对部分携号转网号码的路由存在失败。

四条根因清楚之后，措施就很具体：一是开学季组织一次全区家长联系方式核对，由班主任通过纸质回执确认，共更新号码 2.1 万个；二是把小程序绑定改为班主任生成班级二维码、家长扫码即绑，学号自动带出；三是与网关服务商协同修复携号转网路由问题；四是增加送达失败自动转班主任提醒的兜底机制。三个月后送达率提升至 98.4%。

联调责任界面的书面化。 四家外部单位的对接采取与前述同样的思路：所有跨方接口逐一列明提供方、消费方、字段口径、异常首问责任人，共 18 个接口，经五方签字确认；接口变更须提前 3 个工作日书面通知并收齐回执。整个联调期跨方问题共 41 条，无一条出现责任推诿。

四、干系人管理过程与本项目的干系人管理计划

干系人管理包含识别干系人、规划干系人参与、管理干系人参与、监督干系人参与四个过程。本项目共识别干系人群体 9 类、具名联系人 63 人（家长群体以家委会代表计入）。

管理干系人参与阶段最花力气的是班主任群体。他们初期普遍抵制，理由非常实在：过去在微信群里发条消息就完了，现在要登录系统、选择对象、填写模板，工作量看上去增加了；何况考勤与预警数据一旦进系统，就等于把班级管理暴露在校长和教育局眼皮底下。我请教研室牵头做了三件事：一是把教师端消息发布做成三步以内，并支持常用模板一键复用；二是明确预警数据只用于干预服务、不进教师考核，这一条写进了区教育局的正式通知；三是邀请 12 名班主任担任种子用户，参与界面评审，其提出的 23 条建议采纳了 17 条。第二次参与度评估时该群体由抵制转为中立，上线三个月后转为支持。

干系人	分类	当前/期望参与度	主要诉求	参与与沟通策略
区教育局分管领导	重点管理	支持/领导	按期交付、无舆情	月度汇报，敏感事项当日直报
基教科、教研室	重点管理	中立/支持	业务规范、减负要求	需求评审签字，全程参加调度会
126 所学校校长	重点管理	中立/支持	接入负担、数据安全	分批接入，就绪检查表前置
班主任与任课教师	随时告知	抵制/支持	操作负担、考核顾虑	三步发布，明确不进考核，种子用户参与
家长与家委会	随时告知	不知晓/支持	通知能收到、看得懂	扫码即绑，通俗表述，分时段推送
区数据资源管理部门	令其满意	中立/中立	数据合规、未成年人信息保护	方案联合评审，权限最小化
学籍与体质健康系统运维方	监督	中立/中立	接口边界、改造量	责任界面清单签字，变更回执制
一卡通厂商与短信网关商	监督	中立/支持	排期与结算	周联调例会，问题当场认领

五、反思与改进

2024 年 6 月项目通过验收。四类数据归集后统计口径统一，全区上报数据的业务差错率由 2.7% 降至 0.3%；教师在考勤、请假、健康三类事项上的重复录入工作量下降 68%；长期缺勤与体质异常等预警事件的平均处置时长缩短 55%，一学期内累计推送预警 1340 条，其中经班主任核实需要干预的有 217 条。

反思有三点。第一，我对家长这类 " 无法被管理的干系人 " 的估计仍显不足。上线首月 81% 的送达率暴露的是一个基本事实：面向公众的沟通，渠道可达性必须先于内容设计去验证，否则内容再好也无从谈起。第二，逐项检查表的执行要有硬度。第一批 6 所学校延后接入时，我承受了要求 " 先上再补 " 的压力，如果当时松了口，后面必然连锁返工——沟通规则一旦有例外，就会迅速失效。第三，沟通管理不能与其他知识领域割裂。散点图与根本原因分析都来自质量管理的工具箱，用来诊断沟通问题同样有效；班主任群体从抵制到支持，靠的是干系人管理策略与需求管理的协同，而非反复动员。回过头看，一个项目的沟通做得好不好，最终体现在别人的行为有没有真的改变。这些认识我已经用在了目前正在推进的区级教育资源公共服务平台项目上。