048_华南某省会城市土壤污染风险管控平台信息系统项目交付绩效域

ONEPSOFT | 软考学习知识库

---

摘要

本文以华南某省会城市土壤污染风险管控平台信息系统项目为例，按规划、执行、监控的过程主线论述交付绩效域。该项目由该地区生态环境主管部门发起，合同额 592.32 万元，2024 年 2 月启动，建设周期 11 个月，团队 20 人，采用服务网格 Istio、多活容灾架构、GaussDB 与分布式缓存构建，前端 Vue3 与 TypeScript、后端 Java 17 与 Spring Boot 开发，我担任项目经理。针对终端设备种类繁多、多级审批链路长、跨部门业务口径不一致三个难点，我以检查表、分层抽样与因果图为支撑，说明了项目经理在交付绩效域应重点关注的方面、五大过程组中各绩效域与交付绩效域的协同目标，并制定了分过程组的测量指标。项目于 2024 年 12 月通过终验，业务差错率由 2.7% 下降至 0.3%，人工重复录入工作量下降 68%，用户满意度测评由 78 分提升至 94 分。

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

该市工业遗留地块与农用地土壤环境状况长期缺乏统一台账，调查报告、监测数据、风险评估结论分散在生态环境、自然资源、农业农村等部门，一块地要不要管控、由谁管控，常常需要来回函询数周才能定论，个别地块甚至因信息不同步而重复调查。为把土壤环境数据汇到一处、把风险管控流程串起来，该地区生态环境主管部门作为建设单位发起本项目，我方经公开招标中标承建，我被任命为项目经理。

系统建设内容包括地块档案、调查监测数据归集、风险评估、管控措施跟踪与成效分析五个模块。技术实现上，采用服务网格 Istio 承担服务治理、灰度发布与服务间加密；多活容灾架构在两个机房之间互备；监测与地块数据持久化于 GaussDB 分布式数据库；分布式缓存承载地块图层与评估结果的高频查询；前端采用 Vue3 与 TypeScript 开发，后端基于 Java 17 与 Spring Boot 框架。系统部署于市级政务云信创环境，服务器与操作系统均为国产化产品，应用中间件采用东方通 TongWeb。

交付成果包括系统源代码与部署包；需求规格、概要与详细设计、数据库与接口规范等文档；测试方案与测试报告；历史地块与监测数据清洗比对记录；上线与回退预案；面向管理人员、监测人员、区级联络员三类角色共 7 场培训；以及 12 个月免费运维支持。

项目团队 20 人按矩阵型组织，下设需求组、开发组、集成实施组、测试组与实施推广组，另配专职配置管理员 1 名负责配置项标识与版本基线，质量保证人员 1 名。我作为项目经理，全面负责可交付物的定义、产出与验收，即对交付绩效域承担总责。

二、项目经理在交付绩效域需重点关注的方面

交付绩效域关注的是项目交付什么、如何满足需求与质量要求、最终能否兑现预期业务价值，其核心要点包括价值交付、可交付物、需求与范围、质量以及对次优结果的应对。需要明确的是，可交付物是交付绩效域的核心要点，不应把它混入开发方法与生命周期绩效域，后者关注的是用什么方法、以什么节奏去产出，两者一个管 " 交什么 "，一个管 " 怎么交 "。

规划层面：把价值转化为清晰的可交付物与验收标准。 定义可交付物是把业务目标层层拆解为具体成果的过程，其作用在于让各方对 " 做完是什么样 " 有一致预期。本项目最先要解决的是跨部门业务口径不一致：三个部门对 " 重点监管地块 "" 风险等级 "" 管控完成 " 的判定标准各不相同，若口径不统一，交付物做出来也无法被共同接受。我采用检查表，把需要统一的口径拆成地块识别、数据要素、评估规则、流程节点四大类共 46 项，逐项列出各部门现行定义与拟采用的统一定义，组织三个部门的业务处室逐条确认并签字。46 项中有 11 项存在实质分歧，经两轮专题会全部收口。检查表的结果直接转化为需求规格中的验收标准，可交付物清单也据此定稿。

执行层面：确保可交付物的质量与需求覆盖。 终端设备种类繁多、兼容性适配工作量被低估，是执行期最大的质量隐患：区级联络员使用的采集终端有九种型号。我采用分层抽样开展交付物核验，按终端型号分层，每类随机抽取 20% 的设备实测数据采集、离线暂存与坐标定位三项功能。首轮抽样合格率仅 74%，暴露出两类终端的定位漂移问题；经两轮修复后合格率提升至 98%。抽样把 " 适配大概做完了 " 这种模糊判断变成了可量化的质量结论。

监控层面：盯住验收链路本身。 多级组织层级审批链路长、权限模型复杂，导致交付物完成后迟迟走不完验收流程。我绘制因果图，从人、机、料、法、环五方面排查验收缓慢的原因：人——各区联络员兼职多、响应慢；机——验收表单仍走线下纸质；料——验收所需的比对报告出具滞后；法——未规定各级验收的时限；环——季度考核期各部门集中忙碌。根因判定为 " 法 " 与 " 机 "，即缺少时限约定、验收未线上化。对策是把验收流程配置进系统、明确每级 5 个工作日的时限并自动催办，验收平均周期由 19 天压缩至 6 天。

三、五大过程组中与交付绩效域协同的绩效域及协同目标

交付绩效域并非孤立运转，它在五大过程组中分别与不同绩效域协同，详见表 1。

在启动过程组，交付绩效域主要与干系人绩效域协同，协同目标是识别出可交付物的最终验收方与受益方，就项目要交付的业务价值和成功标准达成共识，并写入项目章程。本项目在启动阶段即明确由生态环境主管部门业务处室担任验收主体，自然资源与农业农村部门为会签方。

在规划过程组，交付绩效域与规划绩效域、开发方法与生命周期绩效域协同，协同目标是把价值分解为可交付物清单与验收标准，纳入范围、进度、成本基线，并确定与之匹配的交付节奏。上述 46 项口径检查表正是这一协同的产物。

在执行过程组，交付绩效域与项目工作绩效域、团队绩效域协同，协同目标是以稳定的过程和有能力的团队高效产出符合质量要求的可交付物，减少返工。

在监控过程组，交付绩效域与度量绩效域、不确定性绩效域协同，协同目标是及时发现需求覆盖不足、质量不达标与验收滞后等偏差，识别并应对可能导致次优结果的风险。

在收尾过程组，交付绩效域再次与干系人绩效域、度量绩效域协同，协同目标是完成可交付物的正式验收与移交，并对业务效益的实现情况作出评价。

四、分过程组的交付绩效域测量指标

为使交付绩效域可度量，我按过程组制定了一套指标，每两周在项目看板上展示，详见表 2。启动过程组度量高层级需求条目确认率与成功标准签认率；规划过程组度量需求覆盖率、验收标准明确率与范围基线签署率；执行过程组度量可交付物按期完成率、缺陷密度与返工工时占比；监控过程组度量一次验收通过率、变更影响件数与质量问题闭环率；收尾过程组度量终验一次通过率、用户满意度与效益指标达成率。第 7 个月看板显示一次验收通过率仅 68%，低于 85% 的门槛，这正是促使我用因果图溯源验收链路的直接触发点。

五、结项成效与心得体会

本项目 2024 年 2 月启动，8 月完成地块档案与数据归集模块上线，9 至 11 月试运行并完成三部门联调，2024 年 12 月通过终验，全程 11 个月，与合同工期一致。核心成效为：业务差错率由 2.7% 下降至 0.3%；人工重复录入工作量下降 68%；用户满意度测评由 78 分提升至 94 分。

回顾全程，我有三点体会。第一，交付绩效域的起点不是写代码而是统一口径，46 项检查表把三个部门的分歧在开工前就摆平，可交付物才有共同认可的验收标准。第二，质量结论要靠抽样得出而非靠汇报，分层抽样的 74% 与 98% 两个数字，比任何一次 " 适配基本完成 " 的口头汇报都更有说服力。第三，交付不只是做出来，还要交出去，因果图让我意识到验收链路本身也是交付的一部分，把时限与线上化补上，19 天压到 6 天，效益才真正兑现。只有把价值、可交付物、需求与质量四者贯通起来管理，土壤风险管控的数据底座才能真正支撑起监管决策。

表 1 五大过程组中与交付绩效域协同的绩效域及协同目标

过程组	协同绩效域	协同目标
启动	干系人绩效域	明确验收方与受益方，就交付价值与成功标准达成共识
规划	规划绩效域、开发方法与生命周期绩效域	形成可交付物清单与验收标准，纳入基线并匹配交付节奏
执行	项目工作绩效域、团队绩效域	以稳定过程与有能力团队产出合格可交付物，减少返工
监控	度量绩效域、不确定性绩效域	及时发现需求、质量与验收偏差，应对次优结果风险
收尾	干系人绩效域、度量绩效域	完成正式验收与移交，评价业务效益实现情况

表 2 分过程组的交付绩效域测量指标

过程组	测量指标	本项目目标值
启动	高层级需求条目确认率、成功标准签认率	均为 100%
规划	需求覆盖率、验收标准明确率、范围基线签署率	≥95%、100%、100%
执行	可交付物按期完成率、缺陷密度、返工工时占比	≥90%、≤0.8 个/千行、≤8%
监控	一次验收通过率、变更影响件数、质量问题闭环率	≥85%、≤5 件/月、100%
收尾	终验一次通过率、用户满意度、效益指标达成率	100%、≥90 分、≥90%