108_华南某区县级儿童福利保障系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

华南地区某区县的儿童福利业务涵盖困境儿童认定、孤儿保障、收养登记、家庭寄养等多个环节，业务办理长期依赖人工登记与纸质台账，数据分散在民政、街道与福利机构手中，第三方厂商交付质量参差，集成测试反复返工，福利机构工作人员信息化基础薄弱，操作习惯迁移阻力大，现场施工与在线业务必须并行，不能中断日常办理。儿童福利业务关系民生底线，信息登记错了、保障遗漏了都是大事，项目的管理压力从立项就存在。保障对象的认定标准随政策调整而变，收窄或放宽都会牵动一批人的权益，这决定了范围说明书里的每一项表述都必须经得起推敲。为把儿童福利业务数字化，该地区民政主管部门于 2022 年 11 月发起了区县级儿童福利保障系统信息系统项目，经公开招标由我司承建，合同额 1680.32 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合儿童福利业务数据，实现认定在线化、保障精准化、监管一体化。建设内容包括困境儿童认定、孤儿保障管理、收养登记、寄养家庭管理、统计分析与报表五个模块，并与民政、街道及福利机构对接。系统按同城双中心多活容灾架构运行，服务调用统一经由 Istio 服务网格治理并支持灰度发布，数据层采用 GaussDB 存储业务数据，热点数据借助分布式缓存加速访问；前端框架为 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发。项目团队共 24 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 13 人、测试工程师 4 人、实施与运维工程师 2 人、质量保证与配置管理各 1 人。团队规模不小，但对接的部门与机构多，范围确认的链条长，每个人都清楚自己的工作包对应范围说明书的哪一条。项目于 2023 年 10 月通过终验，上线后运维人工巡检投入下降 60%，并发承载能力由 800 提升至 5000 用户在线，业务差错率由 2.7% 下降至 0.3%。

范围管理决定项目做且只做哪些工作，这个项目涉及民生业务、对接面广、范围极易蔓延，范围划得清不清，直接决定后面十一个月的节奏。范围一变，进度、成本、质量都会跟着变，所以范围管理从来不是孤立的，而是与整体管理联动着走。下面我按前期、中期、后期三个阶段，结合项目实践说明范围管理是如何开展的。

一、前期：规划范围、收集需求、定义范围与创建 WBS

在项目前期，需要先明确范围管理怎么做，这一工作被称为规划范围管理。我依据章程与合同，组织骨干团队编制了《范围管理计划》，明确以需求分析团队牵头收集需求、以合同与标准为需求判定依据、每周与民政部门对齐一次范围状态，并规定范围变更一律走整体变更控制流程。计划还明确了 WBS 的分解粒度与编码规则，让后续的分解有章可循。

在项目前期，还需要把各方诉求收集起来，这一工作被称为收集需求。我们访谈了民政科室、街道经办人、福利机构与儿童家庭代表四类干系人，整理出原始需求 208 条。儿童家庭代表数量虽少，却是保障体验的直接感受者，他们的反馈为认定流程的简化提供了重要参照。为避免遗漏，我用检查表按六个维度逐项排查：认定标准、保障发放、收养登记、寄养管理、接口对接、运维支持，每个维度下细分到具体岗位逐格打钩确认，不能确定的标注待核并限期落实，共补齐漏项 17 条。

在项目前期，需要把收集的需求固化为书面边界，这一工作被称为定义范围。我牵头编制《项目范围说明书》，把边界写得很具体：项目范围即建设五个模块并完成与民政、街道及福利机构的对接；交付成果包括各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明认定审核时限不超过 3 个工作日、并发承载不低于 5000 用户在线等；除外事项列明不包含历史数据的全面清洗与福利机构内部系统的改造，把话说在明处，避免后期扯皮。

创建范围基准是范围管理的核心一环。在定义范围的基础上，我们按五个模块加项目管理与集成测试逐层拆解，遵循 100% 规则，每个工作包只能属于一个上级节点、全部工作包之和等于项目范围，形成 WBS 与 WBS 词典，对每个工作包补充负责人、验收标准与依赖关系。例如困境儿童认定模块拆到第三层，就细分为档案录入、初审、复核、认定结果反馈等具体工作包，每个工作包都能量化、可考核。范围说明书、WBS 与词典经民政部门逐条确认后，共同构成范围基准，此后任何调整都必须走整体变更控制流程，基准一立，范围就有了准绳，团队和建设方都照着一本账干活。

二、中期：确认范围与控制范围

在项目中期，需要阶段性地核实交付成果是否符合约定，这一工作被称为确认范围。我们按里程碑组织范围确认，邀请民政部门对照范围说明书逐项清点，用检查表按模块功能、报表数量、接口清单三个维度逐项打钩，凡缺失或不符合的当场登记、限期整改，一周后复核通过，各方签署阶段验收报告，把范围确认的关口前移到每个里程碑，而不是等到收尾才一次性清算。对交付成果的核验，我们采用分层抽样，按模块类型与街道层级分层抽取样本现场演示核对，用有限的精力覆盖关键风险面，抽到的问题当场记录、当场明确整改时限。

在项目中期，还需要盯住范围不膨胀，这一工作被称为控制范围。11 个月里需求变更频繁出现，我们没有一拒了之，而是先做影响分析再决定。有一次福利机构提出把寄养家庭资质年审并入本期建设，涉及新的审核流程与字段改造，我组织团队用因果图围绕 " 需求变更频繁 " 从业务、流程、人员、沟通四方面分析根因，定位到前期需求收集对福利机构的操作场景了解不够，据此把需求确认前置到设计评审阶段，并安排需求分析师每周驻场半天收集一线反馈，变更率从前期的高位回落到后期趋于稳定。对并入年审的诉求，我们做了影响分析，量化出新增约 150 人天的工作量与工期延长的影响，建议作为二期单独立项，经变更控制委员会评审后采纳，范围基准得以守住。对确实必要的小幅调整，我们走快速变更通道，评估影响、审批、更新基准文档一气呵成，既不误事也不失控，变更记录留痕可查，每一笔改动都说得清来龙去脉。

三、后期：收尾与经验总结

在项目后期，需要做最后的范围核验并总结经验，这一工作对应收尾阶段的范围收口。验收阶段，我们对照范围说明书做最终清点，五个模块与全部接口逐项核对，用统计抽样按业务类型与街道层级分层抽取样本，与试点运行数据逐条比对，核验通过率达到预期标准，没有遗漏也未超范围。对试运行期间发现的个别字段缺失问题，我们按变更流程补充完善后再确认，没有出现未走流程的隐性变更，范围始终在册。

项目最终按期通过终验，运维巡检投入下降 60%，并发承载提升到 5000 用户在线，差错率由 2.7% 降到 0.3%，困境儿童从认定到保障发放的流程全部在线可查。回顾整个过程，范围管理给我的体会是：边界要划清、基准要立住、变更要管严。范围说明书把边界写到可核对的粒度，WBS 让做且只做有了落点，检查表与分层抽样让确认范围有了抓手，因果图让需求变更的根因浮出水面。范围管理不是纸面功夫，而是每天都要对照的标尺，这正是本项目给我最深的启示。这套以范围基准为纲、以检查表与抽样为工具的做法，后来也被沉淀为公司在民生类项目的范围管理模板，为后续项目提供了参照。