247_粤西某省级运维审计堡垒机系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

论粤西某省级运维审计堡垒机系统信息系统项目的范围管理

一、项目概要叙述

运维审计是守住政务信息系统安全底线的关键，过去各单位设备账号分散、操作行为难追溯，一旦出现越权或误删，定责无据。我所在的该单位信息管理部门，长期受困于资产底数不清、审计覆盖不全。为破局，该部门于 2024 年 5 月正式启动 " 粤西某省级运维审计堡垒机系统 " 建设项目，我受单位委派出任项目经理，牵头从需求规划、方案设计到开发实施、集成测试与验收移交的全过程。

项目总投资约 536.04 万元，建设周期 15 个月，组建 12 人项目团队，内部含业务分析师 2 人、架构师 1 人、开发工程师 7 人、测试工程师 1 人、质保专员 1 人，外部含集成实施与多家被纳管单位的联调人员。技术路线上以低代码平台承载业务表单与流程的快速搭建，通过微服务网关做统一鉴权与路由，数据层用 OceanBase 分布式库配合 RocketMQ 消息队列，扛住高并发事务与异步解耦。系统最终以管理系统、移动端与指挥看板的形式交付，并附全套运维文档。建设内容则拆为统一纳管门户、审计日志中心、权限管控、告警中心四块。项目难点在于：网络专线覆盖不全，偏远节点通信稳定性不足；算法识别在复杂光照与天气条件下准确率不稳定；多家外部单位联调，进度同步与责任界面复杂。上线后，用户满意度测评由 78 分提升至 94 分，数据自动核验比例由 42% 提升至 91%，业务差错率由 2.7% 下降至 0.3%。

二、所谓范围管理，指的是为交付符合需求成果而开展的一系列边界管控活动

所谓范围管理，指的是为确保项目做且只做获准工作、保障可交付物与需求严丝合缝而开展的全过程管控活动。结合本项目，我围绕六个子过程推进范围管理，各过程的主要成果成为范围基准的支柱。

所谓规划范围管理，指的是制定范围管理计划与需求管理计划、明确范围管控制度的过程。我组织核心成员与被纳管单位代表召开规划研讨会，依据项目章程制定两份计划，规定纳管资产完整率、操作审计覆盖率等核心标准及变更审批流程，为后续管控奠定制度基础。

收集需求时，所谓收集需求，指的是记录干系人需要并编制需求文件的过程。我用散点图分析 " 外部单位联调工时 " 与 " 接口数量 " 的相关性，发现接口越多、联调越易超期，据此把接口标准化列为需求重心；用逐项检查对照需求清单，逐条确认功能与非功能约束是否齐备，避免遗漏。例如某单位提出 " 操作行为 AI 预测 " 诉求，经逐项检查核对发现其超出本期纳管范围且依赖未建设的训练数据，我将其列为二期而非强行纳入，既回应关切又守住了本期轻量化。定义范围阶段，我编制《项目范围说明书》，明确交付物包含统一纳管门户、审计日志中心、权限管控、告警中心四个子系统，同时将 " 硬件服务器采购 "" 机房装修 " 等越界诉求列为除外责任，从源头划清红线。创建 WBS 时，我把四大模块自上而下拆成可独立交付的单元，最底层定位工作包并逐一编号，而活动作为进度管理定义活动的产物不进入 WBS 层级；分解时我邀请被纳管单位的技术代表参与评审，约定以单个纳管能力为最小工作包，既利于验收也便于责任追溯。控制范围阶段，建设期内某单位提出新增 " 录像智能摘要 " 功能，我引导其走正式变更流程，经影响评估与变更控制委员会评审、批准后才执行并全过程留痕，守住了基准严肃性。为穿透范围蔓延的根因，我用根本原因分析回溯早期需求，定位到口头诉求未书面化、无除外责任清单是主因，遂把需求书面化与除外责任作为硬性门槛，从根源减少越界请求。整个建设期共受理变更 19 笔，批准 13 笔、驳回 6 笔，驳回的多是顺手加功能的越界诉求，我把每笔变更影响分析表公开在协同看板，倒逼提变更的人先想清楚再开口。

三、范围管理与规划绩效域、度量绩效域的协同

范围管理不能单打独斗，它和规划绩效域、度量绩效域是绑在一起用的。在规划侧，规划绩效域给范围管理定的是路线原则，本项目拆 WBS 时我按系统架构把模块落成一个个粒度合适的工作包，让计划能真正落地；在监控侧，度量绩效域给的是量化尺子，我用需求采纳率、变更驳回率这些指标盯着范围健康度，中期发现变更频率往上走就立刻开澄清会把无效变更压下去。两边一个管方向、一个管尺度，把范围基准稳稳托住，边界始终清清楚楚。这种把方向和尺度捏在一起的做法，让我在后来的安全类项目里直接复用，少绕了不少弯路，也成了我跟团队讲范围时最爱举的例子。

四、确认范围的全过程记录

所谓确认范围，指的是正式验收已完成可交付成果、对照基准确保账实相符的过程。本项目确认范围的全过程记录如下：开发测试完成后，我组织质保团队内部预验收，修复 3 个缺陷；随后提交 39 份交付文档给主管部门。2025 年 8 月召开正式验收会，12 人参会，对照范围基准从功能、性能、文档三方面核查：功能上四个子系统全部就绪，纳管资产完整率实测 96.2% 达标；性能上操作审计覆盖率达 99%、平均查询响应 1.1 秒优于标准；文档齐全且签署规范。最终形成经 6 方签字盖章的《项目验收报告》，确认范围工作闭环。整个确认过程留有会议纪要、测试报告、签字页三类痕迹，做到全程可追溯。预验收阶段曾发现审计日志中心的 " 操作回放 " 在极端并发下出现卡顿，我立即退回开发组优化索引、补回归用例，复测通过后才进入正式验收，避免了带病交付，也验算了确认范围这道关的真正价值。

五、心得体会

项目于 2025 年 8 月顺利验收。范围管理真正的价值，是让该守的边界在每个环节都不掉链子。本项目以散点图看清联调风险、以逐项检查核全需求、以根本原因分析穿透蔓延根因，形成了可复用的范围管理资产。当然，项目在创建 WBS 初期对活动与工作包层级边界把握偏晚，导致中期一度返工。回头看，范围管理最怕的就是 " 重功能、轻边界 "——把六个过程拧成闭环，比堆功能管用得多。这一认知，已成为我后续政务安全类项目的默认动作。我越来越信一句话：范围不是管出来的，是规划出来的，这句话在我手上反复得到印证。往后我会继续把范围基线磨细，推动范围管理从 " 被动接需求 " 转向 " 主动划边界 "，给政务运维审计更稳的兜底。我还格外关注需求数据的真实性，曾出现某周需求统计异常偏高，核对是个别单位争资源多报，我当即要求需求带来源戳记、抽样复核，把水分挤干再入基准。范围数据若自己都说谎，基准再漂亮也立不住，这是我始终坚守的底线。做这个项目的另一点体会是，范围确认不能只盯交付物清单，更要盯一线使用者的真实场景。预验收时我特意让运维人员实操堡垒机，他们提出的几条检索习惯直接改掉了三处交互，否则验收过了也会在真实环境里被吐槽。确认范围这道关，守的是账面，更是体验。我也认清一个事实：边界划得再漂亮，若不被使用方认领，就等于没划。因此我把确认范围提前到开发中期，让使用单位早介入、早签字，把分歧消灭在交付前而不是验收时。这套以散点图、根本原因分析、逐项检查为主线的范围打法，已在同批次的安全管控类项目里复用，效果同样扎实可信。回望这一程，范围管理最难的从来不只是把功能做对，更是把多家单位的诉求翻译成同一份基准。堡垒机关系政务系统的操作安全，任何范围疏漏都可能变成审计盲区，因此我比以往任何项目都更较真每一条边界，也更愿意为基准落地多走一步路。