083_江苏某县域创新平台绩效评价系统信息系统项目整合管理

ONEPSOFT | 软考学习知识库

---

江苏某县各类创新平台数量众多，孵化器、众创空间、企业研发机构加在一起有上百家，绩效评价长期依赖纸质材料报送，指标口径各平台理解不一，主管部门审核靠人工翻台账，评价结果出得慢、公信力也受影响。为把评价工作标准化、数字化，该科研机构信息中心于 2022 年 11 月发起了县域创新平台绩效评价系统信息系统项目，经公开招标由我司承建，合同额 645.08 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是建立统一的平台档案与评价指标体系，实现申报在线化、评审规范化、结果可追溯。评价指标涉及研发投入、成果转化、孵化绩效等多个维度，指标口径需要与主管部门反复对齐，这成为需求阶段的重点。建设内容包括平台档案与申报管理、指标库与评分规则、材料在线报送、专家评审、结果公示与统计五个模块，并与科技、财政、税务等部门及多家外部评价机构建立数据接口。技术方案采用低代码平台承载表单与流程的快速配置，前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，各微服务经微服务网关统一鉴权与限流，数据存储选用 OceanBase 分布式数据库，跨系统的消息推送由 RocketMQ 承担，应用中间件采用东方通 TongWeb，整体部署在县政务云信创环境，按等级保护三级完成安全建设。项目团队共 16 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 7 人、测试工程师 3 人、实施与数据治理专员 2 人。项目于 2023 年 10 月通过终验，上线后用户满意度测评由 78 分提升至 94 分，人工重复录入工作量下降 68%，运维人工巡检投入下降 60%。

这个项目跨度不长、团队不大，但头绪非常多：评价指标要适配各类平台、材料接口要对接多家外部单位、报送终端型号五花八门。整合管理正是应对这种多头绪的法宝。下面我从理论认识、实践做法、反思改进三个层面，谈谈本项目在整合管理上的思考与作为。

一、对项目整合管理的理论认识

从理论上讲，项目整合管理包含制定项目章程、制订项目管理计划、指导与管理项目工作、管理项目知识、监控项目工作、实施整体变更控制、结束项目或阶段七个过程，其目的是协调项目各要素，使它们彼此咬合而不是各行其是。七个过程覆盖从启动到收尾的全生命周期，任何一个过程缺位，都可能在其他地方产生连锁反应。

从理论上讲，整合管理区别于其他知识领域的要害在于整体性：范围、进度、成本、质量等各管一条线，而整合管理负责把这条线拧成一股绳。章程管授权，计划管路径，执行管落地，知识管沉淀，监控管纠偏，变更管基准，收尾管移交，七个过程各有分工又互相衔接。

从理论上讲，实施整体变更控制是整合管理中最容易出问题的一环。任何对范围、进度、成本基准的改动，都必须经过统一的评审通道，否则项目就会在不知不觉中被各种局部决定带偏方向。整体变更控制的输入是变更请求，输出是批准的变更与更新的基准，中间经过影响分析、委员会评审、实施与验证等环节，环环都要留痕。

二、整合管理的实践做法

制定项目章程阶段，我协同建设单位项目发起人与我司分管领导共同编制章程，由我司分管领导签发，明确了项目要解决的评价工作数字化问题、645.08 万元的预算框架与 11 个月的工期约束，任命我为项目经理并授予资源调配权，同时把多家外部单位联调、终端兼容适配作为高层级风险写入章程，为后续工作立下依据。章程还界定了关键干系人名单与总体里程碑，例如指标库评审、材料报送试运行与终验各节点的时间安排，让各方对项目节奏有了一致预期。

制订项目管理计划阶段，我把各子计划的草案整合成统一的项目管理计划：范围说明书明确了五个模块与外部接口的边界，WBS 分解出六百余个工作包，进度基准与成本基准据此排定，变更管理计划明确变更控制委员会由我、建设单位业务代表与我司技术总监组成，凡涉及基准的变更必须经委员会评审。计划经评审后发布，成为项目执行的统一口径。

指导与管理项目工作阶段，我们按两周一个迭代推进开发，每日站会跟踪进度，跨模块的接口改动提前一个迭代知会相关小组。迭代回顾会也是知识管理的一部分，我们把每个迭代做得好的与需要改进的各列两条，形成行动项跟进，团队能力在一次次回顾中稳步提升。管理项目知识方面，我同步建立经验教训登记册，把外部单位联调中的协作教训及时沉淀：例如与税务部门对接时因数据口径沟通层级不够而反复确认，事后把 " 涉及外部单位的接口须由双方项目经理先行对齐口径 " 记入登记册，后续与财政、科技部门对接时直接套用，效率明显提升。

监控项目工作阶段，我把外部单位联调的进度数据画成散点图，横轴为联调批次，纵轴为每批次的完成天数，图形显示前几批的完成天数波动很大，有的批次三天就完成，有的拖到两周，说明联调节奏不稳定。我组织团队用根本原因分析逐层追问，追到根子是几家外部单位对同一字段的口径理解不一致，联调前缺少统一的接口说明书。找到根因后，我推动编制了一份接口说明模板，联调前先书面确认口径，此后的完成天数迅速收敛，进度回归稳定，散点图上的点也集中在均值附近。

实施整体变更控制阶段，发生过一次涉及基准的变更：评审环节需要新增双盲评审模式，涉及评分规则与流程调整。我按变更流程完整走了一遍——变更申请、影响分析、委员会评审、批准实施、验证关闭，并用逐项检查清单核对变更涉及的范围说明书、进度与相关文档是否同步更新，确保变更不留尾巴。这次变更虽小，却让团队养成了先评估、再评审、后实施的变更习惯，后期零散的界面调整类请求也走了同一通道。

结束项目或阶段阶段，我们组织终验，确认各模块功能、性能与安全测评均达标后签署验收报告，向建设单位移交系统、源码、运维手册与培训记录，并把项目经验整理进《经验教训登记册》。终验前我们完成了两周的材料报送试运行，重点观察报送高峰期的系统表现，收集到的问题在终验前全部闭环。

三、反思与改进

项目顺利通过终验，但回顾仍有值得检讨之处。其一，终端兼容适配工作量在规划期被低估，WBS 中适配工作包的估算偏乐观，导致第四个月开发人力一度紧张，此后我要求同类项目在规划前先做终端普查。其二，散点图暴露联调节奏不稳是在第三批联调之后，若更早建立监测基线，问题还能提前两周暴露。其三，变更的逐项检查清单起初只覆盖了文档，未覆盖配置项的版本核对，后来补齐了这一项。这些经验都已沉淀进公司的经验教训库，也促使公司更新了同类项目的启动检查单，把终端普查与基线监测前置到规划阶段。

综上，整合管理的价值不在于把七个过程走一遍，而在于让项目的各个部分始终处于同频状态：章程定方向、计划立基准、知识有沉淀、监控抓偏差、变更守底线、收尾画句号。散点图让联调节奏变得可见，根本原因分析让问题追到根子，逐项检查让变更不留尾巴，依靠这套机制，项目在数据初始化量大、外部单位多、终端形态杂的多重约束下按期交付，满意度由 78 分提升到 94 分，重复录入下降 68%，运维巡检投入下降 60%，得到了建设单位的认可，也为同类评价类系统的建设积累了可复用的经验。