043_辽南某区县级政务事项标准化管理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

摘要

本文以辽南某区县级政务事项标准化管理系统信息系统项目为例，按 " 理论认识—实践做法—反思改进 " 三层递进论述范围管理。该项目由该地区政务服务管理部门发起，合同额 920.12 万元，2021 年 4 月启动，建设周期 18 个月，团队 16 人，采用低代码平台、微服务网关、OceanBase 与 RocketMQ 构建，前端 Vue3 与 TypeScript、后端 Java 17 与 Spring Boot 开发，我担任项目经理。项目面临存量老系统接口文档缺失、历史数据质量参差、用户信息化基础薄弱三个难点。我运用亲和图、面向 X 设计矩阵与直方图支撑范围管理六个过程，论述了范围管理与规划绩效域、度量绩效域的协同，并完整记录了一次确认范围的全过程。项目于 2022 年 10 月通过终验，用户满意度测评由 78 分提升至 94 分，人工重复录入工作量下降 68%，月度报表出具时间由 5 天缩短至 4 小时。

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

该区县的政务服务事项此前由二十余个业务部门各自维护，同一事项在不同部门的名称、材料清单与办理时限互不相同，群众到窗口常被要求补交口径不一的材料，" 同事不同标 " 的投诉长期居高不下。为把政务事项的要素、流程与材料统一起来，该地区政务服务管理部门作为建设单位发起本项目，我方经公开招标中标承建，我被任命为项目经理，全面负责项目管理工作。

系统建设内容包括事项要素库、标准化配置、材料清单管理、办件流程编排、监督评价五个模块。技术实现上，采用低代码平台承载事项配置与表单编排；后端服务经微服务网关统一接入与鉴权；数据持久化于 OceanBase 分布式数据库；跨部门消息与办件流转由 RocketMQ 异步驱动；前端采用 Vue3 与 TypeScript 开发，后端基于 Java 17 与 Spring Boot 框架。系统部署于区级政务云信创环境，服务器与操作系统均为国产化产品，应用中间件采用东方通 TongWeb。

交付成果包括系统源代码与部署包；项目范围说明书、需求规格、概要与详细设计、数据库与接口规范等文档；工作分解结构与需求跟踪矩阵；测试方案与测试报告；存量事项数据清洗与比对记录；上线与回退预案；面向审批人员、窗口人员、监督人员三类角色共 7 场培训；以及 12 个月免费运维支持。

团队 16 人按矩阵型组织，下设需求组、开发组、集成实施组与测试组，另配专职配置管理员 1 名负责配置项标识与基线管理，质量保证人员 1 名。我作为项目经理承担范围管理总责，负责范围管理计划的批准、范围基线的建立与范围变更的最终裁定。下面先从理论层面阐明我对范围管理的认识。

二、理论认识

从理论上讲，项目范围管理包含规划范围管理、收集需求、定义范围、创建工作分解结构、确认范围与控制范围六个过程。前四个过程属于规划过程组，后两个属于监控过程组，其核心目标是确保项目只做且做完全部必需的工作。

从理论上讲，规划绩效域关注项目工作如何被有组织、有协调、有意图地推进，其成果是彼此协调一致的各项计划；度量绩效域关注对项目绩效的评估与恰当响应，包含建立有效指标、展示绩效信息、及时作出决策等内容。范围管理的规划类过程为规划绩效域提供了范围基线这一最基础的计划依据；而确认范围与控制范围两个监控类过程，则依赖度量绩效域给出的偏差数据判断是否需要纠偏。二者实际上是同一件事的计划面与度量面。

从理论上讲，确认范围是正式验收已完成的可交付成果的过程，其输入包括项目管理计划、需求文件、需求跟踪矩阵、核实的可交付成果与工作绩效数据，输出为验收的可交付成果、变更请求与工作绩效信息。需要强调的是，确认范围侧重可交付成果的正式受理，控制质量侧重成果本身是否符合质量要求，前者由客户或发起人主导，后者由质量团队主导，两者不可混淆。理论既已明确，下面结合本项目说明具体做法。

三、实践做法

（一）六个过程及其主要成果

规划范围管理阶段，我与建设单位共同确定事项要素的定义方式、需求变更的审批层级与确认范围的组织形式，输出《范围管理计划》与《需求管理计划》。

收集需求阶段的困难是存量老系统接口文档缺失、改造边界难以厘清。我带需求组走访二十余个部门，累计收集诉求 387 条，条目零散且互相交叉。为把碎片收敛，我采用亲和图将 387 条诉求按内在亲缘关系逐层归并，形成 " 要素统一、材料精简、流程编排、数据互通、监督评价 "5 个主题、19 个子类。亲和图的价值在于让原本互相矛盾的部门诉求在同一张图上显出结构，哪些属于本项目范围、哪些属于部门内部管理，一目了然。本阶段输出《需求文件》与《需求跟踪矩阵》。

定义范围阶段，围绕 " 哪些存量系统改造纳入本期 " 争议不断。我采用面向 X 设计矩阵进行取舍：以可维护性、可扩展性、可实施性、成本、政策符合度五个维度为列，对 8 个候选存量系统逐一打分排序，最终确定 4 个纳入本期、2 个列入下期、2 个仅做数据同步而不做改造。矩阵把 " 谁嗓门大谁进范围 " 变成了有据可查的评分，评审会一次通过。输出《项目范围说明书》，明确范围边界、假设条件、制约因素与验收标准。

创建工作分解结构阶段，我把范围说明书按模块逐层分解至第五层，最小工作包工期不超过 5 个工作日，形成含 214 个工作包的 WBS 与 WBS 词典，经建设单位签字后与范围说明书共同构成范围基线。

控制范围阶段，用户信息化基础薄弱、操作习惯迁移阻力大，试运行期涌来大量 " 能不能改回原来样子 " 的诉求。我用直方图统计变更请求分布，96 项请求中 " 界面与操作习惯类 " 占 41% 位居首位，" 材料清单口径类 " 占 27%。据此我把界面类诉求集中处理为一次专项优化，避免逐条变更冲击基线，其余按变更控制流程逐项评审，最终批准 31 项、否决 65 项，范围基线共修订 2 次。确认范围的完整记录见本节第三部分。

（二）与规划绩效域、度量绩效域的协同

在规划过程组中，范围管理的四个规划类过程与规划绩效域高度耦合。范围基线一经确定，进度、成本、资源、质量各项计划均以 WBS 的 214 个工作包为共同颗粒度展开，避免了各计划各说各话；反过来，规划绩效域要求各计划彼此协调，也倒逼我在创建 WBS 时补进了原先被忽略的 " 历史数据清洗 " 工作包。

在监控过程组中，确认范围与控制范围同度量绩效域协同。我为范围设定范围偏差率、需求覆盖率、可交付成果一次验收通过率三项指标，每两周在项目例会上以看板展示。度量结果显示第 9 个月需求覆盖率仅 81%，低于 90% 的预警门槛，我据此溯源，发现是历史数据质量参差、清洗规则未统一导致部分事项无法配置，随即补充统一清洗规则并调整排期，两个月后覆盖率回升至 95%。这正体现了度量绩效域 " 建立指标—展示信息—及时响应 " 的闭环。

（三）一次确认范围的全过程记录

以第二阶段 " 材料清单管理模块 " 为例，确认范围的完整过程记录详见表 2。第一步，测试组完成模块测试，质量保证人员出具控制质量输出的《核实的可交付成果》；第二步，我以范围基线、需求文件与需求跟踪矩阵为依据编制《确认范围申请单》，并附上工作绩效数据；第三步，提前 3 个工作日将申请单与演示脚本送达建设单位及 3 个试点部门；第四步，召开范围确认会，由建设单位业务处长主持，我方逐项演示，试点部门对照需求跟踪矩阵的 53 条需求当场勾选；第五步，53 条中 50 条通过、3 条因材料附件格式与新政策不符判为不通过，形成《确认范围会议纪要》与 3 份《变更请求》；第六步，3 条不通过项两周内整改并复验通过，我随即更新需求跟踪矩阵与相关项目文件，出具《验收的可交付成果》清单并归档；第七步，把本次验收的工作绩效信息纳入下一期度量看板。

四、反思改进与心得体会

本项目 2021 年 4 月启动，2022 年 6 月完成全部模块上线，7 至 9 月试运行，2022 年 10 月通过终验，全程 18 个月，与合同工期一致。用户满意度测评由 78 分提升至 94 分；人工重复录入工作量下降 68%；月度报表出具时间由 5 天缩短至 4 小时。

回顾全程，我有三点反思。第一，需求越碎越要先归类再定范围，亲和图把 387 条零散诉求收敛为 5 个主题，范围说明书才写得出清晰边界；如果照单全收，范围蔓延几乎不可避免。第二，纳不纳入范围的争议要靠可量化的取舍工具解决，面向 X 设计矩阵用五个维度给 8 个候选系统打分，把部门间的博弈变成了公开评分，评审效率与公信力同时提升。第三，确认范围必须留下完整过程记录，谁主持、依据什么、逐条勾选结果如何、不通过项怎么闭环，都要有据可查；这次 53 条逐条勾选的做法后来被建设单位固化为区级项目验收的通用模板，也让我体会到项目层面的规范可以沉淀为组织过程资产，反哺后续项目。只有把范围管住管好，政务事项标准化才谈得上真正落地。

表 1 范围基线构成与控制要点

组成部分	本项目内容
项目范围说明书	5 个模块、4 个存量系统改造，明确边界、假设条件、制约因素与验收标准
工作分解结构	逐层分解至第五层，共 214 个工作包，最小工作包工期不超过 5 个工作日
WBS 词典	逐包说明工作描述、责任人、验收标准与所需资源
变更控制	三级审批，界面类诉求集中为一次专项优化，基线累计修订 2 次
度量指标	范围偏差率、需求覆盖率、可交付成果一次验收通过率，每两周看板展示

表 2 材料清单管理模块确认范围过程记录

步骤	时间	主要活动	依据与输出
1	2022-03-08	测试完成，质量保证人员出具核实的可交付成果	控制质量输出
2	2022-03-11	编制确认范围申请单并附工作绩效数据	范围基线、需求文件、需求跟踪矩阵
3	2022-03-15	申请单与演示脚本提前 3 个工作日送达各方	沟通管理计划
4	2022-03-18	召开范围确认会，逐项勾选 53 条需求	建设单位业务处长主持
5	2022-03-18	50 条通过，3 条因附件格式不符判为不通过	会议纪要、3 份变更请求
6	2022-04-01	不通过项整改复验通过，更新项目文件	验收的可交付成果清单
7	2022-04-08	验收绩效信息纳入下一期度量看板	工作绩效信息