118_闽南某经济开发区数据交易服务平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

闽南地区某经济开发区内的企业数据交易需求旺盛，但数据交易长期依靠线下撮合与人工核对，交易数据分散在各行业主管部门与企业手中，流通环节多、合规审查难，数据价值难以释放。为把数据交易流程数字化，该单位信息管理部门于 2023 年 1 月发起了经济开发区数据交易服务平台信息系统项目，经公开招标由我司承接建设，合同总价 1520.24 万元，由我担任项目经理统筹全局，建设周期 8 个月。

项目建设目标是整合数据供给与需求两端资源，实现交易撮合在线化、合规审查自动化、流通记录可追溯。建设内容包括数据资源目录、交易撮合、合规审查、交易结算、统计分析与报表五个模块，并与各行业主管部门及多家数据提供方对接。技术方案中，平台按同城双中心多活容灾架构建设，微服务调用经 Istio 服务网格治理并支持灰度发布，交易数据由 GaussDB 承载，热点数据由分布式缓存加速，前端交互基于 Vue3 组件体系实现，后端服务以 Java 17 与 Spring Boot 构建，应用部署在开发区政务云信创环境，按等级保护三级完成安全建设。项目团队按矩阵型组织搭建，全队 17 人，系统架构师、需求分析师、开发工程师、测试工程师、实施运维与数据治理各岗位按模块规模与接口数量配置到位，我作为项目经理统筹全局。项目于 2023 年 9 月通过终验，上线后数据自动核验比例由 42% 提升至 91%，用户满意度测评由 78 分提升至 94 分，关键业务响应时间由 4.2 秒降至 1.1 秒。

我担任项目经理，主持项目从启动到收尾的全部管理工作，范围管理在其中排在首位。项目交付的成果包括可运行的数据交易服务平台、与各主管部门及数据提供方的对接接口、系统源码与全套文档，以及面向交易双方的培训。这个项目涉及多方数据、多级审批、外部依赖多，范围稍有含糊，接口边界就对不上，范围管理从第一天起就是团队的工作主线。本文按题目要求的三个要点依次展开，结合项目实践谈我对范围管理的认识与做法。

一、项目范围管理的过程

所谓范围管理，管的是项目做且只做所需的工作，它由六个过程构成——规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围，每个过程回答一个具体问题：怎么管、要什么、边界在哪、怎么拆、验什么、控什么。所谓范围基准，指的是范围说明书、WBS 与词典三者合一形成的控制依据，范围是否越界、变更是否批准，都以它为准绳。

规划范围管理阶段，我依据章程与合同，组织骨干团队编制了《范围管理计划》，明确以需求分析团队牵头收集需求、以数据交易管理办法为需求判定依据、WBS 按模块加数据类别维度分解、范围变更一律走整体变更控制流程，计划经主管部门确认后发布。收集需求阶段，我们先后走访了主管部门、数据提供方、数据需求方与交易结算机构四类角色，用访谈加问卷的方式逐类摸底，共整理出原始需求 186 条。为避免遗漏，我用亲和图把需求逐条归类，按数据资源、交易流程、合规审查、结算统计、接口对接、运维支持六类聚拢，再逐类细化核对，共补齐遗漏需求 12 条，把模糊的期望变成了可用的需求清单。定义范围阶段，我主持编写了《项目范围说明书》，把边界写到可核对的粒度：项目范围即建设五个模块并完成与各主管部门及数据提供方的对接；交付成果清单里包含了各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明数据自动核验率不低于 90%、关键业务响应时间不超过 2 秒等；除外事项列明不包含交易纠纷仲裁系统的建设与历史交易数据的全面清洗，这两项明确留到二期评估。说明书经主管部门逐条确认后发布，成为范围工作的基准文件。

二、项目的 WBS

创建 WBS 是把项目可交付成果分解为更小、更易管理组成部分的过程。基于已批准的范围说明书，我们把五个模块加上项目管理与集成测试两条横切线逐层拆解，严格遵循 100% 规则，每个工作包只能属于一个上级节点、全部工作包之和等于项目范围，并遵循 8/80 原则控制工作包规模。以交易撮合模块为例，WBS 至少分解至五层：

第 1 层：交易撮合模块；
第 2 层：撮合引擎、需求匹配、订单管理；
第 3 层：撮合引擎拆分为数据定价、算法匹配、结果推送；
第 4 层：算法匹配拆分为规则配置、相似度计算、候选排序；
第 5 层：相似度计算拆分为数据清洗、特征提取、评分计算、结果校验四个工作包。

每个工作包都有唯一编码、负责人与验收标准，全部录入 WBS 词典。整个项目共分解出四个余层级、数百个工作包，范围说明书、WBS 与词典经主管部门确认后，共同构成范围基准，此后范围的一切调整都要先过整体变更控制这一关，基准一旦立住，范围就有了主心骨。这张 WBS 不仅是拆解工具，也是团队排期、成本核算与验收考核的统一参照，各模块负责人都以它为准认领任务，避免了职责交叉与空白。

三、如何避免范围蔓延

范围蔓延是范围管理最大的敌人，这个项目外部单位多、政策调整频繁，我在控制范围上重点用了三招，招招都落在数据与流程上。控制范围的执行贯穿 8 个月全程，配置管理员每周按范围管理计划核对 WBS 与实际工作的对应关系，凡发现计划外工作立即登记追源，从机制上杜绝了范围悄悄膨胀。

第一招，用直方图看住变更来源。我把每月的需求变更按来源分类统计，画成直方图，图形清楚显示外部单位新增接口诉求与政策调整两类变更占七成以上，属于最需要盯住的对象。据此我与主管部门约定，外部单位新增接口一律先经主管部门评估、再进变更流程，把住了蔓延的第一道关口，后期新增接口诉求明显收敛。

第二招，用面向 X 设计矩阵评估变更。面对每项变更诉求，我不直接答应或拒绝，而是组织团队按面向必要性、面向成本、面向工期、面向风险四个目标对变更打分，量化出新增工作量与影响，把结论提交变更控制委员会评审，评审记录全部留痕可查。有一次主管部门提出把交易仲裁功能并入本期建设，经评估需要新增约 180 人天、工期延长近两个月，超出合同范围，我们建议作为二期单独立项，并给出了二期立项的初步边界，委员会采纳后范围基准得以守住，本期范围没有为这个诉求让步。

第三招，用确认范围把好验收关。我们按里程碑组织范围确认，邀请主管部门对照范围说明书逐项清点，用检查表按模块功能、接口清单、文档交付三个维度逐项打钩，凡不属于范围的功能一律不做、不演示、不承诺，凡缺失或不符合的当场登记、限期整改，一周后复核通过，各方签署阶段验收报告；对确属必要的少量调整，走快速变更通道，评估、审批、更新基准文档一气呵成，变更记录全程留痕。8 个月里，范围从规划到收尾始终在册，没有出现一次未走流程的隐性变更，项目最终按期通过终验，自动核验比例提升到 91%，满意度由 78 分提升到 94 分。

回顾整个过程，范围管理给我的体会是：边界要划得清、基准要立得住、变更要管得严。亲和图让需求收集不留遗漏，WBS 让做且只做有了落点，直方图让变更来源一目了然，面向 X 设计矩阵让变更决策有了数据支撑，确认范围把验收关口前移到每个里程碑。范围管理不是纸面功夫，而是每天都要对照的标尺，这正是这个项目留给我最深的启示。这套以范围基准为纲、以数据与矩阵为工具的做法，后来也被沉淀为公司数据类项目的范围管理模板，供后续同类项目直接取用。