344_西北某区县级体育场馆智管平台信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

一、项目概述

西北某区县级体育场馆多、赛事活动频，智管长期靠纸质台账与分散系统，设备状态难掌握、预约冲突多。为提升文旅治理能力，该地区文化和旅游主管部门于 2022 年 8 月启动了体育场馆智管平台建设，我公司中标承建，我被任命为该项目的项目经理。项目合同额六百四十五点一六万元，建设周期十六个月，团队共二十四人，由架构师、开发、数据、测试、实施与运维人员构成。系统采用服务网格 Istio、多活容灾架构、GaussDB 与分布式缓存技术栈，建设内容涵盖场馆预约、设备物联、赛事管理与客流分析等模块，目标是把分散在各场馆的资源汇成统一的可运营底图。

本项目范围管理的难点有三：第三方厂商交付质量参差、集成测试反复返工，线下流程长期依赖纸质台账、数据初始化工作量巨大，跨部门业务口径不一致、数据无法直接对齐。在十六个月的长周期里，范围一旦失控便会连锁拖垮进度与验收。下面我围绕范围管理的核心过程，结合流程图、五问法与数据分析三类工具，阐述本项目的范围管理过程并总结心得。

二、范围管理的认识与实践

所谓范围管理，指的是确保项目包含且只包含达成目标所必需工作的过程，其作用是明确包括什么、不包括什么，防止范围蔓延与镀金。它包含规划范围管理、收集需求、定义范围、创建 WBS、确认范围与控制范围六个过程。

在规划与收集需求阶段，我用流程图把 " 场馆—赛事—设备 " 的数据流向画成一张可追踪的图，标出跨部门口径不一致的断点；用数据分析按部门抽取业务口径样本，定位八成以上的不一致集中在赛事与设备两类，遂把它们列为首批对齐对象。所谓收集需求，指的是确定、记录并管理干系人需要的过程，其作用是把业务目标转成可跟踪条目。

定义范围与创建 WBS 是把需求转成可交付成果并分解到工作包的过程。我用五问法追问数据初始化为何繁重：为什么工作量大？因为纸质台账多；为什么多？因为历史未电子化；为什么未电子化？因为低估了存量；为什么低估？因为前期未做盘点；为什么未盘点？因为缺统一标准。根因收敛到标准缺位，我据此把初始化做成分批可验收条目，而非一次性硬上。

控制范围时，一次厂商临时要求新增直播大屏，我用流程图评估其对国产化与割接两道红线的冲击，确认属范围蔓延，遂启动整体变更控制纳入二期而非本期，守住了十六个月的整体节奏。数据分析则持续展示各接口的联调偏差，使范围漂移被及时掐灭。

三、心得体会

回望最吃劲的阶段，第三方厂商交付参差与跨部门口径不一导致范围反复漂移，若不是靠流程图把断点提前标出、靠五问法把根因收敛到标准与初始化、靠数据分析把不一致找准，团队很可能陷入无休止的返工。范围管理给我的启示是：范围不是列清单，而是定边界。体育场馆智管关乎群众的健身体验，唯有把分散的场馆、参差的厂商、不一致的口径真正拧成一股绳，才能在十六个月里给出稳定、可追溯的运营账。从各场馆到文化和旅游主管部门，原本散落的资源第一次汇成了同一张底图，这种汇成的过程，远比系统上线那一刻更值得铭记。范围管理没有终点，唯有把分散的要素持续拧成一股绳，才能在长周期里始终不偏航。

在规划与收集需求的延伸上，我还用流程图按场馆抽取数据流向样本，展示口径不一致的断点分布，使团队把有限精力投向最脆弱的两类场景。数据分析则把各部门的业务口径做成趋势看板，对持续偏离的启动对齐预案。所谓定义范围，指的是制定项目和产品详细描述的过程，其作用是把需求转成可验收的边界；所谓创建 WBS，指的是把可交付成果分解为工作包的过程，其作用是让责任到人。

在定义范围与创建 WBS 的细化上，我尤其重视五层分解的落地：以场馆预约为例，分解为 "1 智管平台 / 1.1 预约域 / 1.1.1 场馆预约 / 1.1.1.1 预约策略 / 1.1.1.1.1 时段优先级策略 "，每一层都对应一个可验收的工作包，底层工作包有且只有一名责任人。这种面向可交付成果的分解，使二十四人的团队对 " 做到什么程度算完成 " 有了共同预期。

在确认范围的延伸上，我用数据分析展示各场馆的验收达成度，对理解不一的条目当场做培训与补测；流程图则把 " 需求—设计—测试 " 的闭环画成标准动作，使验收既守住标准又有温度。控制范围时，五问法还帮我识别厂商交付参差的根因是其内部测试不充分，遂推动其建立统一测试基线并列入流程图的验收门禁。

范围管理于我，从来不只是文档里的一张基准表，而是每天要在现场做的一个判断：哪些功能必须本期做、哪些可以二期、哪些坚决不做。这个判断做对了，托底才托得稳。十六个月里，我把这份判断做成习惯：每次接到新诉求先问它是否越过国产化与割接两道红线，每次厂商变动先问它是否只需改参数而非重构。在收官阶段，我把本项目的接口清单、WBS 词典与跨部门口径对齐表整理为组织过程资产，供该单位后续文体类系统直接复用。当系统上线后稳稳支撑了场馆的预约与设备物联，范围管理便成了可继承的能力，而非一次性的项目动作。回望最吃劲的厂商交付参差那几个月，若不是靠流程图把断点提前标出、靠五问法把根因收敛到标准与初始化、靠数据分析把不一致找准，团队很可能为了赶进度而牺牲质量。范围管理给我的另一重体会是：在多方协同的项目里，对齐比堆砌更重要——正因为有流程图把散点连成线，团队才不至于被海量细节淹没。十六个月的体育场馆智管，是我对范围管理最朴素也最扎实的一课。

在范围管理的推进中，我始终把用户真正会用到的作为功能取舍的锚点。体育场馆的智慧化需求很多，但不少功能只是汇报材料上的亮点，落到日常运营里并无高频使用场景。因此我在收集需求时，坚持每个功能都要对应一个明确的业务角色与触发动作，凡是说不清由谁、在何种情况下使用的需求一律暂不入基线。流程图在需求澄清阶段发挥了关键作用，我把预约、入场、计费、退订四条主链路逐个画出来，流程上的断点就是范围缺口，流程上的冗余就是待裁剪项。五问法用来追因，当某个功能反复被提出又反复被搁置，我连续追问为什么，最终发现根因是场馆与上级平台的票务规则未对齐，而非功能本身的技术难度。数据分析则用于验证范围假设，上线前我用历史客流数据测算各功能的使用频次，把低频却高成本的功能标记为可选，把高频刚需功能列为必交付。范围基线一旦确立，任何新增需求都走正式变更流程，由变更控制委员会评估对工期与预算的影响后再定夺。十一个月的周期让我明白，范围管理不是把客户想要的全都做出来，而是诚实地说清项目的边界在哪里。回望整个项目，最让我满意的不是系统上线那一刻，而是运营三个月后，场馆管理员告诉我那些被我们坚持留下的核心功能确实天天在用，而被我们果断砍掉的花哨模块并没有人想念。

若把这次范围管理的经验沉淀成一句话，那就是先把边界画清楚，再谈功能做多少。边界清晰，团队才知道劲往哪里使，客户也才明白什么是额外诉求。这种看似克制的做法，反而让项目在一轮轮需求涌来时始终没有失焦。

项目收尾时，我把这套范围取舍的方法整理成模板，留给下一任项目经理，希望他也能在面对源源不断的需求时，有底气说清什么做、什么不做。