100_江浙某省会城市财政直达资金监控系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

江浙地区某省会城市的财政直达资金规模大、拨付链条长，资金从市财政到区县、再到用款单位，中间涉及多个环节，监控数据分散在财政、国库、银行与用款单位手中，历史数据质量参差，资金拨付高峰时段系统并发压力大，多家外部单位联调进度同步复杂。资金流向看不全，出了问题难以及时追责，监管效率受到明显制约。为把直达资金的流向监管起来，该地区财政税务主管部门于 2021 年 5 月发起了省会城市财政直达资金监控系统信息系统项目，经公开招标由我司承建，合同额 168.04 万元，建设周期 8 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是建立直达资金的全程监控链条，实现资金拨付在线化、流向可追踪、异常可预警。建设内容包括资金指标管理、拨付流程监控、用款单位档案、预警与处置、统计分析与报表五个模块，并与财政、国库、银行及用款单位对接。技术方案采用服务网格 Istio 统一治理微服务调用与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件采用东方通 TongWeb，系统运行在市政务云信创环境，按等级保护三级完成安全建设。项目团队共 16 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 8 人、测试工程师 2 人、实施与运维工程师 2 人。资金数据敏感、口径要求高，历史数据清洗规则难以统一，多家外部单位联调进度同步复杂，这些约束在规划阶段就写进了风险清单。项目于 2022 年 1 月通过终验，上线后运维人工巡检投入下降 60%，资金结算差错实现连续 12 个月零发生，跨部门数据共享接口调用量月均突破 120 万次。

范围管理决定项目做且只做哪些工作，资金监控系统涉及多部门、多系统对接，范围稍一含糊，接口边界就对不上。资金数据一旦出错，直接影响财政监管的严肃性，所以范围管理在这个项目里容不得半点马虎。8 个月的工期也不允许范围反复摇摆，划定的边界必须守住，多干的不算功劳，漏干的才是事故。下面我围绕题目要求的三个方面，结合项目实践说明范围管理是如何开展的。

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

我作为本项目的项目经理，负责从启动到收尾的全过程管理，其中范围管理是第一位的。项目交付的成果包括可运行的直达资金监控系统、与财政国库银行等部门的对接接口、系统源码与全套文档，以及面向业务人员的培训。项目对接的部门多、资金数据敏感，范围管理的好坏直接决定接口能不能对上、边界会不会蔓延。范围划得清楚，后面的进度、成本、质量才有基础，这是我在项目一开始就定下的基调。

二、对范围管理的认识与范围基准的创建

所谓范围管理，指的是确保项目做且只做所需全部工作的管理活动，包含规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围六个过程。所谓规划范围管理，指的是为范围工作制定方法与规则的过程；所谓收集需求，指的是识别并记录干系人需要的过程；所谓定义范围，指的是编制项目范围说明书、明确边界与验收标准的过程；所谓创建 WBS，指的是把可交付成果逐层分解为工作包的过程；所谓确认范围，指的是请干系人正式验收可交付成果的过程；所谓控制范围，指的是监督范围状态、管理变更的过程。所谓范围基准，指的是经批准的《项目范围说明书》、工作分解结构与 WBS 词典的组合，是范围控制与整体变更控制的准绳。

范围基准的创建。 六个过程中，我重点说说范围基准的创建。收集需求阶段，我们访谈了财政、国库、银行与用款单位四类干系人，整理出原始需求 198 条，用数据分析按需求类别统计分布，发现拨付流程监控与预警处置两类需求占比最高，属于必须保障的核心需求。定义范围阶段，我牵头编制《项目范围说明书》，把边界写得很具体：项目范围即建设五个模块并完成与财政、国库、银行及用款单位的对接；交付成果包括各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明资金拨付数据当日到位、预警信息 5 分钟内送达、报表 4 小时内自动生成等；除外事项列明不包含历史资金数据的全面清洗与用款单位内部系统的改造。创建 WBS 阶段，我们把范围说明书按五个模块加项目管理与集成测试逐层拆解，遵循 100% 规则，形成 WBS 与 WBS 词典，对每个工作包补充负责人、验收标准与依赖关系。范围说明书、WBS 与词典经干系人确认后，共同构成范围基准，此后任何调整都必须走整体变更控制流程，基准一立，范围就有了准绳。

三、范围管理遇到的问题及解决

本项目范围管理上遇到过两个典型问题，一个关于边界，一个关于变更，恰好对应了控制范围过程中最容易失守的两类风险。

其一，接口边界反复摇摆。项目中期，国库部门提出把对账功能也并入本期建设，涉及新的对账规则与接口改造，工作量不小。我没有直接答应，而是先做影响分析：用流程图画出新增功能对现有接口与流程的影响路径，把涉及的工作包、工期与成本增量量化出来。流程图把对账功能与既有模块的耦合关系画得清清楚楚，哪些环节要动、哪些接口要改，一目了然。影响分析显示，并入该功能需要新增约 200 人天、工期延长一个月以上，超出合同范围。我把分析结论整理成变更申请提交变更控制委员会，同时建议作为二期单独立项，委员会采纳后，范围基准得以守住。流程图在这里把模糊的诉求变成了清晰的路径，让评审有了依据，也让国库部门理解了我们的判断不是推诿。

其二，需求变更频率偏高。项目前期，各部门陆续提出各类调整诉求，我组织团队用五问法追根因：先问为什么变更多，再问为什么需求没说清，追到第二层发现是需求收集阶段对用款单位的操作场景了解不够。找准根因后，我们把需求确认前置到设计评审阶段，每个需求在进入开发前都要经过业务方与开发方的双向确认，用数据分析持续统计需求变更率，指标从前期的高位回落到后期趋于稳定，变更数量在第四个月后明显下降。同时配置管理员按范围管理计划每周核对 WBS 与实际工作的对应，凡发现计划外工作立即登记追源，范围始终处于受控状态，没有出现范围悄悄膨胀的情况。这两个问题一前一后解决，也让我们积累了处理范围类问题的经验：凡是边界之争，先量化影响再谈取舍；凡是变更之潮，先查根因再堵源头。

四、心得体会

项目最终按期通过终验，运维巡检投入下降 60%，资金结算差错连续 12 个月零发生，接口调用量月均突破 120 万次，资金流向从拨付到使用全程可查，监管部门第一次在系统里看全了直达资金的全链条。回顾整个过程，范围管理给我的体会是：边界要划清、基准要立住、变更要管严。范围说明书把边界写到可核对的粒度，WBS 让做且只做有了落点，流程图让变更影响一目了然，五问法让需求变更的根因浮出水面，数据分析让范围状态始终可量。范围管理不是纸面功夫，而是每天都要对照的标尺，这正是本项目给我最深的启示。把边界划清、把基准立住、把变更管严，看似朴素，却是资金监控这类敏感系统最要紧的功课。这套以范围基准为纲、以流程图与五问法为工具的做法，后来也被沉淀为公司在政务数据类项目的范围管理模板，为后续项目提供了参照。