112_华北某省会城市生态环境执法移动平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

华北地区某省会城市的生态环境执法工作量大，巡查记录、处罚台账长期依赖纸质台账与人工填报，数据分散在市区两级生态环境部门手中，数据初始化工作量巨大，一线执法人员信息化基础薄弱，操作习惯迁移阻力大，项目周期紧、法定验收时点刚性，进度压缩明显。执法数据关系行政处罚的严肃性，记录错了、证据丢了都可能影响执法决定，项目的管理压力从立项就存在。现场取证照片、巡查轨迹都是执法证据，范围边界一旦含糊，证据链就可能对不上。为把生态环境执法数字化，该地区生态环境主管部门于 2024 年 6 月发起了省会城市生态环境执法移动平台信息系统项目，经公开招标由我司承建，合同额 480.24 万元，建设周期 9 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合执法数据，实现巡查在线化、处罚流程化、证据数字化。建设内容包括巡查任务管理、现场取证、处罚流程、案卷归档、统计分析与报表五个模块，并与市区两级执法系统及多家外部单位对接。平台以同城双中心多活容灾架构建设，微服务间调用经 Istio 服务网格治理并支持灰度发布，业务数据由 GaussDB 承载，高频访问数据由分布式缓存加速；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发。项目团队共 22 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 12 人、测试工程师 3 人、实施与运维工程师 2 人、质量保证与配置管理各 1 人。团队规模不小，但执法条线多、验收时点刚性，范围确认的链条长，每个人都清楚自己的工作包对应范围说明书的哪一条。项目于 2025 年 3 月通过终验，上线后平均业务办理时长由 3.5 个工作日压缩至 0.8 个工作日，识别准确率达到 94.6%、误报率控制在 3% 以内，月度报表出具时间由 5 天缩短至 4 小时。

范围管理决定项目做且只做哪些工作，这个项目周期紧、数据底子差、用户群体特殊，范围划得清不清，直接决定后面九个月的节奏。范围一旦变化，进度、成本、质量都会跟着连锁反应，范围管理因此必须与整体管理协同推进。执法系统的功能边界直接连着执法程序的合法性，范围管理在这个项目里的分量格外重。下面我按范围管理的六个过程，结合项目实践说明范围管理是如何开展的。

一、规划范围管理

规划范围管理是确定如何定义、验证和控制项目范围的过程，其作用在于为范围工作提供统一的方法与规则。规划定得好，后面的收集、定义、分解才有章可循，这是范围管理的第一道关口。我依据章程与合同，组织骨干团队编制了《范围管理计划》，主要内容包括：以需求分析团队牵头收集需求，以生态环境部执法规范为需求判定依据；WBS 按模块加行政区维度分解，采用列表型结构；范围基准经市区两级主管部门确认后维护，变更一律走整体变更控制流程；可交付成果按里程碑分批确认。计划经主管部门确认后发布，成为后续范围工作的准绳。

二、收集需求

收集需求是为实现项目目标而确定、记录并管理干系人需求的过程，其作用在于把模糊的期望变成可用的需求清单。需求收集得透不透，直接决定后期变更多不多，这个环节省下的功夫，后面都会加倍还回去。我们访谈了市区两级执法人员、法制审核人员与分管领导，整理出原始需求 192 条，其中现场取证与处罚流程的需求占比最高，属于必须保障的核心需求。数据初始化工作量巨大是突出难点，我用散点图辅助梳理：横轴为历史台账的数据类别，纵轴为各类别的预计录入工作量，图形清楚显示，巡查记录与处罚台账两类数据占据初始化工作量的七成以上，属于最需要优先安排的对象。据此我们按数据类别分批初始化，把人力优先投放到关键类别，初始化进度纳入周报跟踪，没有出现平均用力、全面拖延的情况。

三、定义范围

定义范围是制定项目和产品详细描述的过程，其作用在于为后续决策提供清晰的边界。我牵头编制《项目范围说明书》，把边界写得很具体：项目范围即建设五个模块并完成与市区两级执法系统的对接；交付成果包括各子系统、接口联调报告、性能测试报告与运维手册；验收标准写明平均业务办理时限不超过 1 个工作日、识别准确率不低于 94%、报表 4 小时内自动生成等；除外事项列明不包含历史执法数据的全面审计与执法机构内部系统的改造，把话说在明处，避免后期扯皮。说明书经执法人员代表逐条确认后发布，成为范围工作的基准文件。

四、创建 WBS

创建 WBS 是把项目可交付成果分解为更小、更易管理组成部分的过程，其作用在于让做且只做有落点。我们按五个模块加项目管理与集成测试逐层拆解，遵循 100% 规则，形成 WBS 与 WBS 词典，每个工作包都写明负责人、验收标准与依赖关系。例如巡查任务管理模块拆到第三层，就细分为任务派发、轨迹记录、现场取证、结果回传等具体工作包，每个工作包都能量化、可考核，人人有活干、事事有人管。范围说明书、WBS 与词典经主管部门确认后，共同构成范围基准。

五、确认范围

确认范围是正式验收已完成的可交付成果的过程。以巡查任务管理模块的里程碑确认来说，我们把它分成三步走：会前，提前一周与主管部门约定确认时间，备好模块演示环境、功能清单与测试数据，双方先就任务派发响应不超过 2 秒、现场取证照片上传成功率不低于 98% 的接受标准达成一致；会上，逐项演示任务派发、轨迹记录与取证上传流程，对照范围说明书逐条核对功能清单，个别机型适配问题当场登记；会后，问题项限期整改并复核通过，双方签署阶段验收报告，确认结果归档到范围基准文档。整个过程有约定、有核对、有复核、有记录，范围确认不留模糊地带，每一批交付都认账。

六、控制范围

控制范围是监督项目与产品范围状态、管理范围基准变更的过程，其作用在于防止范围蔓延，让做且只做不变成一句空话。9 个月里陆续有部门提出新增功能诉求，我们没有一拒了之，而是先做影响分析再决定。针对需求变动频繁的问题，我用根本原因分析逐层追问：先问为什么变更多，再问为什么需求没说清，追到第二层发现是收集需求阶段对执法一线操作场景了解不够，据此把需求确认前置到原型评审阶段，并安排需求分析师每月驻点一线收集反馈，变更率从前期的高位回落到后期趋于稳定。对确属必要的调整，我们用逐项检查的方式核对变更对现有接口、工期与成本的影响，从接口清单、测试用例到文档版本逐项过一遍，走快速变更通道，评估、审批、更新基准文档一气呵成，变更记录留痕可查，范围始终处于受控状态。

七、心得体会

项目最终按期通过终验，平均业务办理时长压缩到 0.8 个工作日，识别准确率达到 94.6%，月度报表由 5 天压缩到 4 小时，一线执法人员的填报负担明显减轻。回顾整个过程，范围管理给我的体会是：边界要划清、基准要立住、变更要管严。散点图让初始化工作量的分布有了数据，范围说明书让验收标准可量化，逐项检查让变更影响看得清，完整的确认记录让范围不留模糊地带。范围管理不是纸面功夫，而是每天都要对照的标尺，这正是本项目给我最深的启示。这套以范围基准为纲、以数据与清单为工具的做法，后来也被沉淀为公司在执法类项目的范围管理模板，为后续项目提供了参照。