069_华东某县域全民健身场地预约平台信息系统项目整合管理

ONEPSOFT | 软考学习知识库

---

一、我参与管理的项目概况及本人承担的工作

全民健身设施的使用矛盾，在华东某县域表现得相当典型：一边是公共体育场馆时段空置、学校操场节假日闲置，一边是群众找不到场地、约不上时间。设施资源分散在体育、教育、住建和各镇街手里，各管各的、各有各的登记方式，谁也说不清全县到底有多少可开放场地。为把这些资源归拢起来并向社会开放，该地区文化和旅游主管部门于二〇二一年十二月立项建设华东某县域全民健身场地预约平台，由我所在单位承建，合同额八百五十万四千六百元，建设周期十个月，二〇二二年十月通过验收上线。

平台包含场地资源一张图、在线预约与核销、赛事活动报名、场馆运营监管、社会体育指导员服务五个业务模块，以及一套面向多级管理单位的后台。交付成果包括系统软件与部署包、源代码及接口文档、全县场地普查数据集、多端应用（含微信小程序与自助终端）、运维手册与培训材料、等级保护测评与验收资料。技术上，预约规则与审批流程通过低代码平台配置以适应各单位不同的开放政策，服务经统一网关完成鉴权与限流，数据存储采用 OceanBase 分布式数据库，预约成功通知、核销回执等消息通过 RocketMQ 异步投递；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件为东方通 TongWeb，整体运行在政务云信创环境，安全防护按网络安全等级保护第三级建设。项目采用矩阵型组织，团队十九人，我担任项目经理，全面负责项目计划、执行、监控与收尾。系统上线后，跨部门数据共享接口调用量月均突破一百二十万次，运维人工巡检投入下降百分之六十，系统可用率稳定在百分之九十九点九以上，全年重大故障零起。

所谓项目整合管理，指的是识别、定义、组合、统一并协调各项目管理过程组内的过程和活动，其价值恰恰体现在把彼此冲突的目标和方案统一起来。本项目摆在面前的有三道坎：县、镇街、场馆三级组织层级导致审批链路长，权限模型设计异常复杂；建设周期仅十个月且必须赶在全民健身日之前上线，法定验收时点刚性，进度压缩明显；体育、教育、住建三个口子对 " 可开放场地 " 的定义各不相同，数据无法直接对齐。下面我以这三道坎为纲，逐一说明整合管理在其中如何发挥作用。

二、第一道坎：审批链路长、权限复杂，靠一套刚性的变更控制流程稳住基准

权限模型是本项目最容易反复的地方。上线前的需求确认阶段，仅角色定义就改了四轮，镇街希望能代场馆审批，场馆又不愿让镇街看到自己的收入数据，主管部门则要求全县数据可穿透查看。如果每一次口头意见都直接落到代码上，基准很快就会名存实亡。为此我把整体变更控制作为整合管理的抓手先立了起来。所谓实施整体变更控制，指的是审查全部变更请求、批准或否决变更，并对可交付成果、项目文件和项目管理计划进行相应管理的过程，其作用是保证已批准的基准始终是唯一有效的参照。

本项目的变更处理走七个环节：干系人提交书面变更请求，配置管理员登记编号并纳入变更登记册，我牵头组织技术与业务联合评估并量化对进度、成本和质量基准的影响，提交变更控制委员会决策，获批后更新基准并同步通知全部相关方，实施完成后由业务方复核验证，最后归档留痕。为了适配多级组织的现实，我在委员会之下做了分级授权：不涉及基准变化、工作量在两人日以内的界面与文案调整，由我与业务联络人会签后即可执行并事后报备；凡涉及权限模型、接口协议或验收时点的，一律提交委员会审议，成员包含主管部门处室负责人、教育与住建两家协办单位代表、场馆方代表和我方技术负责人共九人。

为了判断变更是否失控，我做了一项定量观察：把每周提出的变更请求件数与该周产生的返工工时绘成散点图。前六周的点位分布散乱，看不出规律；到第九周，图上呈现出明显的正相关趋势带，其中三个远离趋势带的离群点全部来自权限模块。这一发现让我意识到问题不在变更本身，而在权限需求始终没谈拢。我随即暂停该模块开发，组织三方现场演示并当场敲定角色矩阵，此后权限相关变更由每周五六件降至零星一两件。建设期共受理变更请求五十三件，批准三十七件，否决十六件，没有一件绕开流程。

三、第二道坎：周期紧、验收时点刚性，靠知识管理把重复摸索的时间省下来

十个月的工期里要完成全县场地普查、五个模块开发、多端适配和三方联调，留给试错的余地极小。所谓管理项目知识，指的是使用已有知识并生成新知识以实现项目目标、同时帮助组织学习的过程。在进度高压之下，知识管理不是锦上添花，而是实打实的提速手段。我抓了三件事。

一是把已有知识用起来。开工前，我从组织过程资产中调出了本单位近三年三个同类预约类项目的技术方案、接口清单和验收问题台账，逐条比对本项目需求，直接复用了短信通知、身份核验、支付对账三个成熟组件，节省了约三十五个工作日。

二是把新知识记下来。我要求各组在遇到坑之后当场填写经验教训登记册，写清背景、根因和应对，不等项目结束再回忆补记。显性知识方面，接口协议、部署手册、常见故障处置方案统一进入项目知识库，按模块编号管理，并规定变更批准后同步更新，做到文档版本与系统版本对应。隐性知识方面，我安排熟悉低代码配置的工程师与新人结对，每周三下午固定做半小时的实操演示，把个人经验转化为团队可以共享和管理的显性成果。

三是把知识转成决策。第七个月，多端适配的缺陷居高不下，眼看要拖累上线时点。我组织团队做根本原因分析，沿着 " 缺陷为何集中在自助终端 " 这条线连续追问：终端浏览器内核版本老旧；为何未提前发现，因为测试环境只覆盖了主流内核；为何只覆盖主流内核，因为普查阶段未采集终端型号信息。根因清楚后，措施也就明确了：立即补充采集全县四十一台自助终端的型号与内核版本，据此扩充兼容性测试矩阵。此后两周，该类缺陷下降了八成以上，上线时点得以保住。

四、第三道坎：跨部门口径不一致，靠严谨的收尾把账算清、把责任交清

三个部门对 " 可开放场地 " 的定义不同：体育口按场地面积统计，教育口按学校数量统计，住建口把小区配套健身点也算在内。这种口径差异在建设期靠映射规则勉强兜住，但到了收尾环节就必须彻底算清，否则移交之后必然扯皮。所谓结束项目或阶段，指的是终结项目、阶段或合同的全部活动的过程，其作用是把工作正式收口并沉淀经验。我在收尾时重点关注四个方面。

其一，交付物齐不齐。我以范围基准为清单，采用逐项检查的方式，对五个模块、多端应用和六类文档共一百四十七个交付项逐条核销，每项标注检查人、检查日期和结论，请业主方对可交付成果进行评价并签署确认意见。检查中发现社会体育指导员模块的两份操作手册版本滞后，当场登记整改并在三日内补齐。

其二，账清不清。我核查了与两家分包单位的合同履行情况，确认无未决索赔与争议后办理合同收尾，同时把三个部门的场地数据按统一口径完成最终对账，形成一份经三方共同签章的基准数据说明，白纸黑字写明各口径之间的换算关系，从根上消除后续争议。

其三，人和权交没交。我按计划释放团队成员与租用环境，并对主管部门和三家协办单位的运维人员开展两轮培训与实操考核，考核通过后正式移交系统管理权限与账号台账，同时对项目可用资源的后续安排提出调整建议，避免闲置。

其四，教训留没留。我召集全员复盘，把权限模型协商、多端兼容性、跨部门口径统一三方面的经验教训整理归档并更新至组织过程资产，其中口径换算规则后来被主管部门直接引用为全县统计口径。

五、结语

本项目赶在当年全民健身日之前顺利上线，并于二〇二二年十月通过验收。这段经历让我认识到，整合管理并不是抽象的统筹口号，而是要在具体难题上见真章：审批复杂就用刚性的变更控制守住基准，工期紧张就用知识复用换取时间，口径混乱就用严谨的收尾把账算清。把这三件事做扎实，项目才能既跑得快，又收得住。