131_闽北某县域退役军人服务保障平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

闽北地区某县域的退役军人服务长期依赖纸质台账与人工登记，优抚申请、安置报到、政策兑现等业务分散在各乡镇服务站与县局科室手中，涉密与敏感数据较多、须按等保三级同步建设，现场施工与在线业务必须并行、不能中断日常办理，网络专线覆盖不全、偏远乡镇通信稳定性不足。为把退役军人服务保障数字化，该单位信息管理部门于 2024 年 8 月发起了县域退役军人服务保障平台信息系统项目，经公开招标由我司承建，合同额 720.04 万元，建设周期 16 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合退役军人服务数据，实现申请在线化、办理流程化、政策兑现可追溯。建设内容包括优抚申请、安置报到、政策兑现、帮扶援助、统计分析与报表五个模块，并与县局科室及各乡镇服务站对接。技术方案中，业务表单与流程依托低代码平台快速搭建，申请办理与政策计算逻辑由自研服务承载，前端交互基于 Vue3 组件体系实现，后端服务以 Java 17 与 Spring Boot 构建，各微服务经网关统一鉴权与限流，业务数据存储选用 OceanBase 分布式数据库，跨系统消息由 RocketMQ 推送，整体部署在县政务云信创环境，并按等级保护三级完成安全建设。项目团队按矩阵型组织搭建，全队 13 人，除我之外设系统架构师 1 人、需求分析师 2 人、开发工程师 5 人、测试工程师 2 人、实施与运维工程师 2 人、数据治理专员 1 人。项目于 2025 年 12 月通过终验，上线后数据自动核验比例由 42% 提升至 91%，人工重复录入工作量下降 68%，资金结算差错实现连续 12 个月零发生。

范围管理回答的是 " 项目到底做什么、不做什么 " 的问题，对退役军人服务这类政策性强、涉及面广的业务，边界一旦含糊，接口对不上、政策兑现错位，后续返工代价极高。回顾 16 个月的实践，范围管理并不是把六个子过程逐一背一遍，而是围绕三个最棘手的现实问题展开：范围边界如何定得准、范围管理如何与规划与度量绩效协同、确认范围如何留下完整可信的过程记录。下面我结合这三个问题，谈谈本项目范围管理的落地过程。

一、边界定不准：需求底数不清、政策口径多变，如何把范围基准立起来

项目启动时，摆在我面前的第一道难题是需求底数不清。退役军人业务的专业性强，优抚政策条款细碎，乡镇服务站与县局科室对政策的理解并不一致，加上涉密数据多、沟通渠道受限，需求收集阶段就出现了口径打架、边收边改的现象。如果基准立不稳，后面的分解、验收、变更全都跟着飘。

针对口径不一致，我没有急于固化需求，而是先花时间把需求底数摸清。我们组建了由需求分析师、乡镇专干与县局业务骨干组成的联合小组，分三批走遍全部乡镇服务站，逐项核对优抚政策条款与办理场景，把口头约定全部书面化、签字确认，形成《需求规格说明书》。需求梳理过程中，我发现部分乡镇把 " 走访慰问记录 " 也误纳入本期范围，与政策兑现、帮扶援助存在业务交叉，若不剔除，功能边界会无限膨胀。我组织逐条比对政策依据，明确走访类业务属于乡镇日常管理范畴、不在本期建设边界内，据此在需求清单中予以排除，并请县局书面确认，从源头堵住了边界蔓延的口子。

边界底数清楚后，我主持编制《项目范围说明书》，把范围写到可核对的粒度：项目范围即建设五个模块并完成与县局科室及各乡镇服务站的对接；交付物清单里包含了各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明数据自动核验率不低于 90%、申请办理时限不超过 2 个工作日等；除外事项列明不包含历史优抚数据的全面审计与乡镇内部系统的改造。随后按 100% 规则创建 WBS，把五个模块加项目管理与集成测试两条横切线逐层拆解，每个工作包写明负责人、验收标准与依赖关系，范围说明书、WBS 与词典经县局逐条确认后共同构成范围基准。基准一立，团队与县局都照着一本账干活，此后的调整全部纳入变更控制，边界问题没有再反复。

二、协同不到位：范围管理如何与规划绩效域、度量绩效域拧成一股绳

范围管理不是孤立的一摊事，它与规划绩效域、度量绩效域天然咬合。我的第二道难题是：如何让范围基准真正驱动计划编制，又让范围状态通过度量数据被持续看见，而不是各管各的、两张皮。

与规划绩效域的协同，我把范围基准当作计划编制的起点。16 个月工期、720.04 万元预算，进度与成本计划都以 WBS 工作包为分解依据：每个工作包的工期估算、资源投入、成本测算都挂在对应的工作包上，范围说明书里 " 不包含历史优抚数据全面审计 " 的排除条款，也同步反映到计划中不安排相关资源。反过来，计划又约束范围调整的空间：任何新增需求，先看是否突破既定工期与预算，再决定是否受理。范围基准与计划一前一后，把项目框在既定的边界内。

与度量绩效域的协同，我把范围状态转化为可度量的指标。我们设定了四项范围度量指标：范围基准达成率不低于 98%、需求实现率不低于 99%、变更受控率（已受理变更占全部变更的比例）不低于 70%、验收一次通过率不低于 95%。每周例会上，数据分析工具把实际完成工作包与范围基准逐项比对，生成偏差清单；发现偏差即启动根因分析，用帕累托图按发生频次对偏差来源排序，把占比最高的少数几类（如接口联调缺失、政策调整引发的需求增补）作为重点纠偏对象。度量数据显示，政策调整引发的变更占了全部变更的六成以上，我们据此把政策口径核对前置到每季度政策发布时点，变更率从前期高位回落到后期趋于稳定。范围划边界、规划定路线、度量看偏差，三者协同让项目始终沿着既定边界推进，这也是本项目范围管理最见成效的一段。

三、记录不可信：确认范围如何留下完整、可复核的全过程记录

第三个子题要求写一个确认范围的全部过程记录，这也是我在实践中刻意打磨的一环。项目的第三道难题是：范围确认如果只是 " 走个过场签个字 "，验收时拿不出完整依据，终验就会扯皮。确认范围必须留下从核对、登记、整改到复验的完整痕迹。

以优抚申请模块的阶段确认为例，完整过程记录如下：确认依据是《项目范围说明书》中该模块的验收标准与 WBS 词典对应的工作包定义；参与人员包括县局优抚科业务骨干、乡镇服务站代表、我方需求分析师与我；核对步骤上，用检查表按功能清单、字段口径、接口清单、文档交付四个维度逐项打钩，共核对功能点 126 项；核对结果中 119 项一次通过，7 项存在缺陷——包括两处字段校验逻辑与政策条款不一致、三处页面文案表述不准确、两处接口超时未达标；缺陷当场登记入册，明确责任人、整改时限与复验方式，一周后逐项复核，7 项全部销号；随后各方签署阶段验收报告，确认记录与缺陷整改台账一并归档，全程可查。

针对偏远乡镇网络专线覆盖不全的问题，确认过程还纳入了分批接入安排：把各乡镇的接入进度单独建账，每完成一个批次就组织一次现场演示核对，逐批验收、逐批放行，确认记录按乡镇归档，没有让外部依赖拖住整体节奏。整个确认过程有依据、有清单、有整改、有复验、有签署，环节清晰、记录完整，最终验收一次通过，县局对确认流程的规范性给予肯定，这套确认记录后来还被县局当作内部经验在其他项目中推广。

项目最终按期通过终验，数据自动核验比例提升到 91%，人工重复录入下降 68%，资金结算差错连续 12 个月零发生。回顾整个过程，范围管理给我的体会是：基准要立在需求底数之上，协同要落在指标数据之中，确认要留下完整可信的记录。联合摸底让需求底数清楚，范围说明书与 WBS 让边界可核对，帕累托图与度量指标让偏差被及时看见，检查表与缺陷台账让确认过程经得起复核。范围管理不是纸面功夫，而是每天都要对照的标尺，这正是本项目留给我最深的启示。这套以基准为纲、以协同为要、以记录为凭的做法，后来也被固化进公司在民生类项目的范围管理模板，供后续同类项目直接取用，为团队沉淀了可复用的组织资产。