010_江浙某省级国土空间规划一张图信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2022 年 2 月，江浙某省级自然资源主管部门为解决各级各类规划成果分散存放、相互打架、审批时无从套合的问题，投资 920.16 万元建设国土空间规划 " 一张图 " 系统。我方经公开招标承建，我受命担任项目经理。项目工期 13 个月，团队 13 人，需汇聚省、11 个设区市、67 个县区三级共 14 类规划成果，服务约 6800 名注册用户。本项目在建设期内原有审批业务一天都不能停，可用的割接窗口极其有限；基层用户长期使用桌面制图软件，向平台迁移的抵触情绪明显；外业核查终端型号杂乱，兼容适配的工作量在投标阶段被明显低估。本文按试题的两个设问作答：先给出本项目核心范围对应的需求跟踪矩阵，再结合范围与该矩阵给出项目的 WBS，随后说明我借助帕累托图、质量审计与统计抽样控制范围的做法。项目 2023 年 3 月按期通过验收，规划许可事项线上办结率由 51% 升至 93%，违规图斑核查平均处置时长缩短 55%，套合分析由平均 3.5 个工作日压缩至 0.8 个工作日。

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

该省国土空间规划体系改革后，省市县三级需在统一底图上完成规划编制、审批与监督。但改革前，土地利用总体规划存于省厅台账，城乡规划留在住建部门，各类专项规划散落在交通、水利、林业等十余家单位，坐标系不统一、图层精度不一、更新时点各异。2021 年省级审计抽查发现，同一地块在不同规划中定性冲突的情况多达 1372 处，项目选址时须由人工逐份调阅比对，平均耗时 3.5 个工作日。为此，省自然资源主管部门以国土空间基础信息平台专项资金立项，投资 920.16 万元建设 " 一张图 " 系统，目标是让所有规划成果落在同一张底图上，做到底数可查、冲突可判、实施可监督。

项目 2022 年 2 月启动、2023 年 3 月完成终验，周期 13 个月。建设内容为成果汇交与质检、一张图核心应用、监督实施与监测评估、数据服务与接口、系统支撑与安全五大板块，并与不动产登记、耕地保护监管、林草资源管理三个存量系统对接。技术上，平台以服务网格 Istio 承担服务注册、熔断与灰度发布，规划成果批次汇交期访问量陡增，故按两地多活部署，任一节点失效可在分钟级切换而不中断审批；空间库与业务库分离，业务主库选用 GaussDB，图层元数据与权限数据这类高频读取内容置于分布式缓存；矢量切片服务独立成集群并按行政区划分片，保证县区用户加载本辖区图层的速度。

团队按矩阵型组建，共 13 人：需求 2 人、GIS 开发 5 人、测试 2 人、实施 2 人、专职配置管理员 1 人、质量工程师 1 人；省厅信息中心、规划处及 3 个试点市各派 1 名业务骨干全程参与。交付物包括五大板块的可运行软件及源代码、三类存量系统接口服务、汇交入库后的三级规划成果数据库、《范围管理计划》《需求跟踪矩阵》《WBS 字典》《数据质检规则手册》《测试报告》《用户操作手册》等 6 类 18 份文档，以及面向三级共 412 名规划与审批人员的培训和 12 个月运维。我作为项目经理，重点承担范围定义与变更控制、进度管控和跨层级协调。

二、本项目核心范围对应的需求跟踪矩阵

所谓需求跟踪矩阵，指的是把产品需求与其来源相联系、并在整个项目生命周期中对其进行跟踪的一张表格，它把每项需求与业务目标、可交付成果、验收标准和当前状态挂在一起，使需求的来龙去脉全程可查。在本项目中，它的意义尤其突出：三级用户诉求庞杂，若不逐条挂上来源与目标，很难说清哪些属于合同范围、哪些属于额外诉求。

我采取分层方式收集需求：对省厅规划处、用途管制处等业务处室采用结构化访谈，明确政策底线；对 11 个设区市开展 4 场焦点小组；对 67 个县区因无法逐一走访，按平原、丘陵、沿海三类地形各抽取 5 个县共 15 个县上门调研，并回收有效问卷 276 份；同时对省内两个已建成 " 一张图 " 的兄弟省份做了标杆对照。原始诉求汇总 491 条，团队按语义归并后确定核心需求 12 项，逐条录入需求跟踪矩阵，如下表。

需求 ID	需求描述	来源干系人	对应业务目标	优先级	WBS 编号	验收标准	状态
R-01	14 类规划成果按国家标准汇交并自动质检	省厅规划处	底数可查	核心	1.2.1	强制质检项覆盖率 100%，一次汇交通过率≥90%	已验收
R-02	三区三线与各专项规划的多图层套合分析	省厅用途管制处	冲突可判	核心	1.3.1	10 图层套合响应≤8 秒，结果与人工判读一致	已验收
R-03	项目选址合规性一键比对并出具意见书	11 个设区市自然资源局	审批提速	核心	1.3.2	比对项不少于 23 类，意见书自动生成	已验收
R-04	违规图斑自动识别、下发与核查反馈闭环	省厅执法监督处	实施可监督	核心	1.4.1	识别准确率≥92%，下发到核查全程留痕	已验收
R-05	规划实施监测评估指标自动生成	省厅规划处	实施可监督	重要	1.4.2	28 项指标按季自动出数	已验收
R-06	省市县三级权限体系与数据隔离	省厅信息中心	安全合规	核心	1.6.1	越权访问测试用例全部拦截	已验收
R-07	与不动产登记、耕地保护、林草系统数据对接	三家系统主管处室	底数可查	核心	1.5.1	三类接口日增量同步成功率≥99.5%	已验收
R-08	移动端图斑外业核查，适配主流终端	67 个县区执法人员	实施可监督	重要	1.3.3	覆盖 6 类主流终端，弱网可离线作业	已验收
R-09	历史规划成果存量数据迁移与坐标转换	省厅信息中心	底数可查	核心	1.7.1	迁移完整率 100%，坐标转换误差≤0.05 米	已验收
R-10	规划成果公开与公众查询	省政务服务办	阳光政务	一般	1.3.4	公开图层脱密后可查，响应≤3 秒	已验收
R-11	高峰并发不低于 1200，图层加载≤3 秒	省厅信息中心	稳定可用	核心	1.6.2	压力测试达标，可用率≥99.9%	已验收
R-12	规划许可审批全流程线上办理	11 个设区市	审批提速	—	—	经 CCB 评审列入二期，本期不实施	变更受控

矩阵中的 R-12 是本项目范围管理的焦点，后文详述。矩阵建立后，任何一项诉求进来，我都先问三句：它对应哪个业务目标、挂在哪个 WBS 编号下、验收标准是什么。答不上来的，一律不进本期范围。

三、结合范围与需求跟踪矩阵形成的 WBS

有了范围说明书与需求跟踪矩阵，创建 WBS 就有了依据。我组织团队采用自上而下的分解方法，遵循三条规矩：一是 100% 原则，各层分解之和必须等于且仅等于上层范围，既不遗漏也不多做；二是工作包粒度控制在 40 至 80 小时，做到可估算、可指派、可验收；三是每个核心需求必须能在 WBS 中找到落点，矩阵中的 WBS 编号列即为这一映射关系的凭证。分解结果经我方与省厅联合评审通过，形成 4 层结构、共 142 个工作包的 WBS，其上三层如下表。

二级（1.x）	三级	主要工作包（四级）
1.1 项目管理	1.1.1 计划与监控 1.1.2 变更与配置管理	项目计划编制；周例会与绩效报告；风险登记册维护；变更申请受理与 CCB 组织；配置库建立与基线管理
1.2 成果汇交与质检	1.2.1 汇交与质检子系统 1.2.2 质检规则库	汇交任务管理；成果上传与格式校验；空间拓扑检查；属性完备性检查；质检报告生成；14 类成果规则配置
1.3 一张图核心应用	1.3.1 套合分析 1.3.2 选址合规比对 1.3.3 移动端核查 1.3.4 公开查询	图层注册与目录树；多图层叠加与冲突标绘；23 类比对规则引擎；意见书模板与生成；外业采集与离线包；终端兼容适配；脱密发布与公众检索
1.4 监督实施与监测评估	1.4.1 违规图斑闭环 1.4.2 监测评估	遥感影像比对；图斑识别与分级；任务下发与核查反馈；整改销号；28 项指标建模；季度评估报告输出
1.5 数据服务与接口	1.5.1 外部系统对接 1.5.2 统一数据服务	不动产登记接口；耕地保护接口；林草资源接口；服务网关注册与鉴权；数据服务目录与调用监控
1.6 系统支撑与安全	1.6.1 权限与安全 1.6.2 性能与容灾	三级权限模型；数据脱密与水印；等保测评整改；两地多活部署；切片集群调优；压力测试
1.7 部署实施与数据迁移	1.7.1 存量迁移 1.7.2 环境部署与割接	历史成果清洗；坐标系转换与校验；入库比对；生产环境搭建；分批夜间割接；回退预案演练
1.8 培训与运维	1.8.1 培训 1.8.2 试运行与运维	省级师资培训；市县两级分层培训；操作手册编制；试运行值守；缺陷响应与月度运维报告

每个工作包均配有 WBS 字典，注明编号、工作描述、责任人、所需资源、验收标准与前后置依赖。例如工作包 "1.3.1 多图层叠加与冲突标绘 " 的字典中，验收标准直接引用了 R-02 的 "10 图层套合响应≤8 秒，结果与人工判读一致 "，从而使需求、工作包与验收三者严丝合缝。范围说明书、WBS 与 WBS 字典共同构成本项目经批准的范围基准。

四、我是如何控制范围的

控制范围的考验出现在第 7 个月。11 个设区市联名提出，希望把规划许可审批的全流程搬到 " 一张图 " 上办理，理由是 " 既然图都在这里，为什么还要跳到另一个系统 "。诉求听上去合理，但初步评估需新增 31 个工作包、约 360 人日，本期工期与预算都无法承受；若简单拒绝，市级用户的抵触又会直接影响推广。

我先做偏差分析，确认该诉求不在范围基准之内，随后组织团队把建设期内积累的 214 条超范围诉求逐条归类，绘制帕累托图：以各类诉求的预计工作量为纵轴按降序排列并计算累计占比。图形显示，审批流程类占 48.6%、报表定制类占 21.3%、界面个性化占 12.1%，三类合计 82%，其余 9 类合计仅 18%。这张图让我看清两件事：真正的压力集中在审批流程一类，其余多为零散诉求；而审批流程恰恰属于另一个在建项目的建设内容，重复建设并无必要。

据此我提出三条处置：其一，把 R-12 整体列入二期，并牵头与承建审批系统的兄弟单位对接，在本期范围内增做一个跳转与数据回写接口（仅 8 人日），让用户在 " 一张图 " 上点选地块后可直接跳入审批系统并带回结果，用极小代价化解了体验痛点；其二，报表定制类诉求以需求跟踪矩阵为工具逐条核对，凡未挂上业务目标的一律不予受理，确有必要的 4 项通过替换一般级需求的方式吸收，不额外增加工期；其三，请质量工程师对范围执行情况开展一次专项质量审计，核查是否存在未经 CCB 批准即被开发的功能，审计共发现 2 处 " 顺手做 " 的界面改动，均予以回退并追溯了责任人。变更申请经 CCB 批准后，范围基准与进度基准同步更新。

确认范围环节，我按板块分四批组织验收，均以 WBS 字典中的验收标准为依据，由我方、省厅业务处室、试点市用户三方联合核对签字。第三批的存量数据迁移成果涉及三级共 42.8 万个图斑，无法全量核验，我采用统计抽样：按图层类型、行政层级、数据年份三个维度分层，随机抽取样本图斑 3800 个，逐个核对几何精度与属性完整性；同时对涉及永久基本农田与生态保护红线的图斑实行 100% 全检，不做抽样。首轮抽样不符合项 116 个，超过 2% 的容许水平，判定不通过并退回补正；补正后二次抽样不符合项降至 29 个、符合率 99.24%，予以验收，全检的永久基本农田图斑无一差错。

五、心得体会

2023 年 3 月，项目按期通过终验。系统运行后，14 类规划成果全部落图，规划许可事项线上办结率由 51% 提升至 93%，违规图斑核查平均处置时长缩短 55%，选址套合分析由平均 3.5 个工作日压缩至 0.8 个工作日，高峰并发实测 1460、图层加载 2.1 秒，均优于指标。

三点体会。其一，需求跟踪矩阵不是交差用的表格，而是范围控制的作战地图。本项目 214 条超范围诉求之所以能逐条说清 " 收还是不收 "，靠的就是矩阵里那几列——业务目标、WBS 编号、验收标准，答不上来的诉求自然被挡在门外，讨论也就不再靠嗓门。其二，拒绝不是范围控制的唯一手段。面对市级用户的审批诉求，硬顶回去会让平台推广受阻，全盘接受则拖垮项目；用 8 人日做一个跳转与回写接口，既守住了范围基准，又解决了用户的真实痛点，这比单纯说 " 不 " 更考验项目经理。其三，范围管理与其他领域彼此咬合。帕累托图本是质量管理的工具，用在诉求分类上同样奏效；范围执行靠质量审计来兜底；成果验收借助统计抽样才能在有限工期内完成——把范围管理孤立起来做，很容易变成机械挡人。

不足在于，我在定义范围阶段没有把 " 与在建审批系统的边界 " 写进范围说明书的排除项，导致第 7 个月不得不用一次变更评审来澄清。此后我已在公司范围说明书模板中固定增加 " 与相邻在建项目的边界 " 一节，把这类容易含糊的接壤地带提前钉死。