244_川东某省会城市基站资源共享管理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

论川东某省会城市基站资源共享管理系统信息系统项目的范围管理

一、项目概要叙述

广播与通信基站是城市信息基础设施的底座，过去各电台站、运营商基站资源分散在多家单位，重复建设与实际闲置并存，应急调度靠人工台账、跨单位协调慢。我所在的某传媒集团技术中心，长期面临资源共享难、资产盘点乱的困境。为破局，该中心于 2021 年 9 月正式启动 " 川东某省会城市基站资源共享管理系统 " 建设项目，我受委派担任项目经理，统筹需求规划、方案设计、开发实施、集成测试与验收移交全流程。

项目总投资约 168.58 万元，建设周期 12 个月，组建 20 人项目团队，内部含业务分析师 2 人、架构师 1 人、开发工程师 10 人、测试工程师 4 人、质保专员 2 人，外部含集成实施与多家运营商、铁塔公司的联调人员。技术上服务端采用云原生微服务架构，服务间调用由服务网格 Istio 统一治理，数据层以 GaussDB 分布式数据库与分布式缓存构建高可用底座，整体按同城双中心多活容灾部署。建设内容涵盖资源共享门户、接口总线、调度看板、运维管理四大模块，最终交付管理系统、移动端、指挥看板及全套运维文档。项目难点在于：多级组织层级审批链路长，权限模型设计复杂；多家外部单位联调，进度同步与责任界面复杂；历史数据质量参差，清洗与治理规则难以统一。上线后，跨部门数据共享接口调用量月均突破 120 万次，运维人工巡检投入下降 60%，资源识别准确率达到 94.6%，误报率控制在 3% 以内。

二、理论认识：范围管理是 " 做对的事 " 的护栏

范围管理的本质，是确保项目交付物与获批需求严丝合缝，既不缺斤少两也不画蛇添足。从理论上讲，它包含规划范围管理、收集需求、定义范围、创建 WBS、确认范围、控制范围六个相互衔接的过程，前段把 " 要做什么 " 想清楚，后段把 " 做没做对 " 核清楚。对跨单位协同类项目而言，范围管理更是多方诉求的 " 翻译器 " 与 " 仲裁者 "——把各家口头愿望转成可签字的基准，把越界请求挡在门外。本项目既要对接集团内部，又要联调运营商、铁塔公司与广电台站，诉求来源多、责任界面碎，范围一旦失焦，就会陷入 " 谁都提、谁都不认 " 的拉锯，因此我把范围基准当作贯穿全程的主心骨，而不是等项目跑起来再补。范围管理六个过程中，规划范围管理与收集需求决定方向对不对，定义范围与创建 WBS 决定边界清不清，确认范围与控制范围决定结果实不实。我在本项目里把最多精力放在前两段——方向偏了，后面做得越顺错得越远；边界糊了，验收时必然扯皮。这种前置发力的取向，源于早年在跨单位项目里吃过范围不清的亏：曾经一个项目因需求未书面化，上线后各方对共享的理解南辕北辙，返工近一个月。痛定思痛，我把先立基准、再谈实现写进了本项目的管理原则。这也让范围管理在本项目里有了清晰的优先级：先把做什么钉死，再谈怎么做，而不是边做边想。许多跨单位项目烂尾，根子就在本末倒置——还没想清边界就急着写代码，最后在验收时被迫返工。

三、实践做法：围绕三道范围难关破局

难关一在需求杂、难收敛。我用帕累托图统计各干系人提报的需求频次，发现 " 接口标准化 "" 数据实时共享 "" 权限分级 " 三类诉求占全部需求的七成以上，遂把需求重心压到这三条主线上，避免撒胡椒面式铺开。同时用质量审计核对需求文档的完整性，逐项排查是否遗漏非功能约束；用统计抽样抽取历史工单，核实 " 资源闲置预警 "" 跨单位调度 " 等诉求的真实性，挤掉个别单位为争资源多报的水分，让需求文件经得起签字确认。例如资源闲置预警这一诉求，历史工单仅 37 条且分散在五家单位，经统计抽样核对后确认其真实存在但频次不高，我将其列为二期优化而非一期必建，既回应了关切又守住了本期范围的轻量化。这种用数据说话、按频次排优先级的做法，让需求收敛从扯皮变成了算账。

难关二在边界不清、易镀金。我依据需求文件编制《项目范围说明书》，明确交付物包含资源共享门户、接口总线、调度看板等子系统，并把 " 高精度三维漫游 "" 市级平台源码定制 " 等越界诉求列为除外责任，从源头划清红线。创建 WBS 时，我带领团队按 " 一个底座、两类接口、N 个应用 " 的架构自上而下分解，交付物拆到可验收的工作包即止，不为好看而无限细分，让每一份基准都对应真实的验收动作。创建 WBS 时我特意邀请运营商与铁塔公司的技术代表参与评审，因为他们最清楚接口联调的实际颗粒度——工作包拆得过粗，联调责任就悬空；过细则管理成本翻倍。最终我们约定以单个接口能力为最小工作包，既利于验收又便于责任追溯，这个折中后来被证明是关键的一步。

难关三在变更频、基准易动。建设期内，某运营商提出新增 " 视频信号定时轮巡 " 功能，我未直接答应，而是引导其走正式变更流程：先书面申请，再做影响评估，提交变更控制委员会评审，批准后才执行并全过程留痕。对每笔变更我都追问 " 是否动摇范围基准 "，可吸收的归入迭代、越界的坚决挡回，既回应了合理诉求，也守住了基准的严肃性。整个建设期共受理变更 21 笔，其中批准 14 笔、驳回 7 笔，驳回的多是顺手加个功能类的越界请求。我把每笔变更的影响分析表公开在协同看板上，谁提的、改了什么、影响了哪条线一目了然，既减少了猜测与抵触，也倒逼提变更的人先想清楚再开口，变更质量反而更高。

四、反思改进：协同与沉淀

回望全过程，跨单位项目的范围管理，难在 " 翻译 " 而非 " 画图 "——把各方语言译成同一份基准，比画一张漂亮的 WBS 更难也更重要。我也愈发确信，范围管理须与规划绩效域、度量绩效域协同发力：规划绩效域给出路线图原则，我在规划期就把需求优先级嵌进整体计划；度量绩效域提供量化之尺，我用需求采纳率、变更驳回率等指标盯住范围健康度，偏差刚露头就纠偏。范围管理还教会我一件事：基准不是一成不变的铁律，而是需要主动维护的活资产。项目中期政策调整要求新增应急广播接入，我评估后将其纳入范围基准的正式修订，而非偷偷塞进迭代，保证了基准始终与实际交付一致。这种变中有守的平衡，是跨单位项目最考验项目经理功力的地方。回望这一程，范围管理最难的从来不是画一张 WBS，而是让多家单位在同一份基准上达成共识并守住它。基站资源关系应急调度的命脉，任何范围疏漏都会被放大为协同失效，因此我比以往任何项目都更较真每一个边界，也更愿意为基准落地多走一步路。范围从一份承诺变成看得见的边界，靠的正是这一次次看似琐碎的较真。

我还格外关注需求数据的真实性。曾出现某周需求统计异常偏高，核对发现是个别单位为争资源多报而非真诉求，我当即要求需求须带来源戳记、抽样复核，把水分挤干后再入范围基准。范围数据若自己都说谎，基准再漂亮也立不住，这是我始终坚守的底线。正是这份较真，让主管部门在验收时对我们的范围核算格外放心——他们看到的不只是一份签字的说明书，而是一套可追溯、可复核的范围管理证据链。这也让我明白，范围管理的信用，是一次次挤水分挤出来的。未来我将继续完善范围基线，让范围管理从 " 被动接单 " 走向 " 主动立界 "，为城市信息基础设施的资源共享贡献更稳的支撑。这套以帕累托图聚主线、以质量审计与统计抽样核真的范围打法，帮我在多家单位之间立住了同一把尺，也让后续的跨域协同项目少走了许多弯路。