022_华北某区县级城市体检评估平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2024 年 7 月，我作为承建方项目经理主持了华北某区县级城市体检评估平台建设项目。建设单位为该地区城市管理主管部门，合同额 536.46 万元，建设周期 8 个月，团队 22 人。系统采用服务网格 Istio、多活容灾架构、GaussDB 与分布式缓存，前端使用 Vue3、ECharts 与二维 GIS 组件，通过 Kafka 对接住建、自然资源、生态环境等六个部门数据源，建成指标采集与治理、体检诊断分析、问题整改闭环、社区满意度调查、综合展示五个子系统。项目面临验收时点刚性、三级审批链路长导致权限模型复杂、用户信息化基础薄弱三大难点，矛盾集中在指标范围的界定与控制上。本文按前期、中期、后期三个阶段，围绕 " 指标范围如何界定、如何追溯、如何守住 " 这条贯穿全程的线索，阐述范围管理六个过程的做法，给出核心范围对应的需求跟踪矩阵与分解至五层的 WBS，并运用标杆对照、因果图与控制图支撑决策。项目于 2025 年 3 月按期验收，运维人工巡检投入下降 60%，线上办理率由 51% 提升至 93%，资金结算差错实现连续 12 个月零发生。

一、项目背景与我的职责

城市体检是上级主管部门推行的常态化制度，要求区县每年围绕生态宜居、健康舒适、安全韧性、交通便捷等维度采集指标、诊断问题、下达整改任务并评估成效。该区此前依靠各部门报送表格、人工汇总成册，指标口径不一、数据无法溯源、整改落地难以跟踪、资金拨付与形象进度脱节。建设单位据此立项，要求建成贯通 " 指标采集—诊断分析—问题派单—整改闭环—成效评估 " 的区级平台。我方于 2024 年 6 月中标，我被任命为项目经理，团队由需求组 4 人、开发组 12 人、测试组 3 人、实施组 3 人构成。

本项目最大的特点是范围极易失控：指标体系由上级规定基础项、同时允许区县增补特色项；六个数据源部门各有既有系统与口径；街道、社区两级填报人员信息化基础薄弱，界面稍复杂就要求 " 再改一版 "。而验收时点受上级年度成果报送时间刚性约束，不具备顺延空间。范围管理因此成为能否按期交付的前提。

二、前期阶段：确立规则与收集需求

在项目前期，需要编制一份说明将如何定义、确认和控制项目范围与产品范围的文件，这一工作被称为规划范围管理。2024 年 7 月项目启动会后，我依据项目章程、招标文件与已批准的项目管理计划，组织建设单位信息科科长、两位业务科室负责人、我方需求组长与架构师召开专题会议，并采用标杆对照的方法，调取了我方此前承建的两个同类区县城市体检平台的范围说明书、WBS 与变更台账，逐项比对其范围边界与变更集中区。比对结果显示，同类项目变更的七成集中在指标增补与填报表单调整两类，据此我在范围管理计划中作出针对性规定：产品范围以经双方签字确认的《指标目录基线》为准，指标增补一律走正式变更流程；范围管理计划与需求管理计划同步发布，明确需求跟踪矩阵为需求全生命周期的唯一追溯载体；确认范围采用按子系统分批预验收加整体终验的方式；范围蔓延的判定标准与升级路径写入计划并经评审通过。这份计划为后续所有范围决策提供了依据。

在项目前期，还需要为实现项目目标而确定、记录并管理干系人的需要和需求，这一工作被称为收集需求。我采取三种方式并行：一是文件分析，梳理上级下发的体检指标规范与该区近三年的体检报告；二是访谈与引导式研讨会，分别与六个数据源部门、四个街道、八个社区的代表座谈；三是问卷调查，向 112 名潜在填报人发放问卷并回收 103 份。收集过程中出现了一个关键发现：我带需求组下沉到某社区实地观察填报流程时看到，社区工作人员为完成一次月度上报，需要在三张表格中重复填写同一批基础数据，其中十七个字段完全重复，仅表头名称不同。这一现象暴露出真正的业务痛点不是 " 表格不够用 "，而是 " 同一数据被多次索取 "。我当即组织建设单位与三个业务科室召开原型评审会，确立了 " 一次采集、多口径复用 " 的产品设计主线：由平台维护一套指标原子项，各类报表从原子项派生。这条主线随后成为定义范围与创建 WBS 的核心依据，也把潜在的表单类变更需求从源头上消解了大半。收集需求阶段最终形成需求文件与需求跟踪矩阵，共登记需求 186 条，其中核心范围需求 42 条。

三、中期阶段：定义范围与创建 WBS

在项目中期，需要制定项目和产品的详细描述，这一工作被称为定义范围。我依据项目章程与需求文件，与建设单位召开了三轮引导式研讨会，运用多准则决策分析对 186 条需求按 " 上级强制要求、业务价值、实现成本、工期占用 " 四个准则加权打分，最终形成项目范围说明书。说明书明确了产品范围描述，即五个子系统与《指标目录基线》所列的 65 项基础指标和 11 项本地特色指标；明确了可交付成果，包括平台软件、六个数据源接口、指标目录基线、用户操作手册、运维手册与培训服务；明确了验收标准，包括功能符合基线、页面平均响应不超过 2 秒、支持 500 并发、指标自动采集覆盖率不低于 70%、数据溯源链路完整；并特别列明除外责任，包括数据源部门既有系统改造、第三方测绘数据采购、超出基线的指标增补与硬件采购。这一书面化在后续多次拦住了口头提出的额外要求。

在项目中期，还需要把可交付成果与项目工作分解为较小、更易于管理的组件，这一工作被称为创建 WBS。我采用自上而下的分解方法分五步完成：一是依据范围说明书与需求文件识别全部可交付成果；二是确定采用表格型结构编排；三是逐层细化，第二层按项目管理与五个子系统划分，第三层按功能模块划分，第四层按可独立交付的功能单元划分，第五层落到可估算工期、可分配责任人的工作包；四是分配唯一编码；五是核实分解程度。分解中，开发组长主张分到第四层即可，理由是层级过深增加管理成本；测试组长主张必须分到第五层，理由是工期仅 8 个月，粒度不细无法准确排期。我依据 100% 原则与 " 工作包应能在 8 至 80 小时内完成、可估算可分配可验证 " 的判据裁定：管理类与文档类分至第四层，开发与联调类分至第五层。最终 WBS 共五层、含工作包 217 个，并配套编制 WBS 词典，作为进度计划与成本估算的共同输入。

四、后期阶段：确认范围与控制范围

在项目后期，需要正式验收已完成的项目可交付成果，这一工作被称为确认范围。我按范围管理计划采取分批预验收方式，每个子系统开发完成并通过内部测试后，即组织建设单位业务人员依据需求跟踪矩阵逐条核对，采用检查与投票决策的方式确认。在指标采集子系统预验收时，街道用户对填报界面提出了 23 条意见，我逐条对照需求跟踪矩阵判定：其中 18 条属于已确认需求的实现偏差，纳入缺陷修复；5 条属于新增需求，转入变更流程处理。以矩阵为准绳的判定方式，避免了预验收现场演变为需求扩张现场。五个子系统全部通过后，2025 年 3 月整体终验一次性通过。

在项目后期，还需要监督项目和产品的范围状态、管理范围基准变更，这一工作被称为控制范围。我建立了两项机制。其一是用控制图对范围偏差做趋势监控：以 " 每周新增变更请求数 " 为监控指标，依据前六周数据计算中心线为每周 3.2 件、上控制限为每周 8.1 件，一旦单点超限或连续七点上行即触发专项分析。2024 年 11 月第二周变更请求数达 11 件，超出上控制限，我立即召集需求组、开发组与建设单位业务科室绘制因果图，从人员、方法、数据、环境四个方面分析根因：人员方面为新到岗的街道联络员未参加过需求确认会；方法方面为原型评审仅覆盖社区层级、未覆盖街道层级；数据方面为部分特色指标的口径在基线中表述含糊；环境方面为上级临时下发了指标口径补充通知。经排序确认主因是原型评审层级覆盖不全与基线口径表述含糊两项。据此我们补做了一轮面向街道的原型确认，并对基线中 11 项表述含糊的指标逐条书面澄清，两周后变更请求数回落至每周 2 至 4 件的受控区间。其二是严格执行变更流程，全程受理变更请求 37 件，经变更控制委员会批准 19 件、拒绝 12 件、合并 6 件，获批变更同步更新范围基准、需求跟踪矩阵、WBS 与进度计划，保持基准一致。

五、结项成效与体会

项目于 2025 年 3 月按期验收，未发生逾期，范围基准变更幅度控制在合同额的 4.1% 以内。上线后运维人工巡检投入下降 60%，线上办理率由 51% 提升至 93%，整改资金结算差错连续 12 个月零发生。

回顾全程，我有三点体会。第一，范围管理必须有一条贯穿始终的业务主线。本项目从收集需求阶段确立的 " 一次采集、多口径复用 "，一直贯穿到定义范围的产品描述、WBS 的模块划分、需求跟踪矩阵的追溯链路与控制范围的判定依据，正因为有这条主线，各阶段的决策才不至于各说各话。第二，需求跟踪矩阵不是交差用的文档，而是确认范围与控制范围阶段最有力的裁定工具；预验收现场之所以能把 18 条与 5 条区分清楚，靠的正是矩阵中 " 需求—设计—开发—测试—验收 " 的完整链路。第三，范围管理无法孤立开展：WBS 是进度与成本管理的共同输入；变更评估必须联合进度管理判断关键路径影响、联合风险管理评估二次风险；街道用户的抵触则要靠干系人管理提前介入化解。本项目在多级审批权限模型上之所以未出现大面积返工，正是因为在定义范围阶段就把三级权限的角色矩阵写进了范围说明书。

不足之处在于，前期原型确认只覆盖社区层级、遗漏了街道这一关键使用层级，导致中期出现一轮变更高峰。今后我会在收集需求阶段依据干系人登记册核对使用层级的完整性，确保每类最终用户都参与过原型确认。

表 1 核心范围需求跟踪矩阵（摘录）

序号	需求描述	业务需求／目标	项目目标	WBS 可交付成果	产品设计	产品开发	测试用例	验收状态
R-01	指标原子项统一维护	消除同一数据被多表重复索取	一次采集、多口径复用	1.2 指标采集与治理子系统	原子项定义、口径说明、版本管理	指标中心服务	原子项增改删、口径版本回溯	通过
R-02	六部门数据自动汇聚	提高自动采集覆盖率	自动采集覆盖率≥70%	1.2.3 数据汇聚模块	Kafka 接入、清洗规则、异常告警	汇聚服务与适配器	断点续传、脏数据拦截	通过
R-03	体检问题自动诊断	由人工判读转为规则判读	诊断结果可溯源	1.3 体检诊断分析子系统	阈值规则库、诊断报告模板	规则引擎	阈值边界、报告生成正确性	通过
R-04	整改任务派单闭环	整改落地情况可跟踪	线上办理率≥90%	1.4 问题整改闭环子系统	派单、督办、销号、回访	工作流引擎	超期督办、越级派单拦截	通过
R-05	三级权限角色矩阵	区、街道、社区权限隔离	越权访问零发生	1.1.4 权限模型设计	角色—数据—功能三维授权	统一鉴权服务	越权访问、数据行级隔离	通过
R-06	社区满意度调查	主观感受纳入体检结论	问卷回收率≥80%	1.5 满意度调查子系统	问卷设计器、抽样规则	问卷服务	重复提交拦截、抽样均衡性	通过

表 2 WBS 分解（五层，摘录）

层级	编码	名称
第 1 层	1	华北某区县级城市体检评估平台项目
第 2 层	1.2	指标采集与治理子系统
第 3 层	1.2.1	指标体系管理
第 4 层	1.2.1.1	指标原子项管理
第 5 层	1.2.1.1.1	原子项数据结构设计与建表
第 5 层	1.2.1.1.2	原子项增删改查功能开发
第 5 层	1.2.1.1.3	口径版本管理功能开发
第 5 层	1.2.1.1.4	原子项模块单元测试
第 4 层	1.2.1.2	报表派生规则管理
第 5 层	1.2.1.2.1	派生规则配置界面开发
第 5 层	1.2.1.2.2	派生计算引擎开发
第 5 层	1.2.1.2.3	派生结果比对测试
第 3 层	1.2.3	数据汇聚模块
第 4 层	1.2.3.1	六部门接口适配
第 5 层	1.2.3.1.1	住建数据源适配器开发与联调
第 5 层	1.2.3.1.2	自然资源数据源适配器开发与联调
第 5 层	1.2.3.1.3	生态环境数据源适配器开发与联调

表 3 范围变更处置统计

变更来源	提出件数	批准	拒绝	合并	主要处置依据
街道／社区填报侧	16	8	5	3	是否属基线内实现偏差
数据源部门	9	5	2	2	是否属除外责任
上级口径调整	7	6	0	1	强制性要求优先
我方内部优化	5	0	5	0	不影响验收标准者不予变更