2025年7月至2026年6月，我担任某省级三甲医院云影像平台项目的项目经理。该项目投资980万元，工期12个月，需通过等保三级安全测评，团队27人。云影像平台涉及四大系统、11个子模块，功能复杂、需求众多，范围管理难度极大。本文以范围管理为例，叙述了规划范围管理、收集需求、定义范围、创建WBS、确认范围、控制范围六个核心过程。通过WBS分解、需求跟踪矩阵（RTM）、严格的变更控制，项目范围偏差控制在5%以内，未出现范围蔓延。
该医院年门诊量超200万人次，影像科日均检查量约1500例。原有PACS系统老旧，跨院区调阅困难。院方决定建设统一的云影像平台，实现"数据统一存储、跨院区调阅、远程诊断协作"三大目标。
云影像平台项目范围特点：
- 功能模块多：四大系统（云影像核心系统、影像诊断教学系统、云影像前置机系统、业务存储系统），11个子模块
- 接口对接复杂：需对接院内7个现有系统（PACS/RIS/HIS/CIS/手麻等），3个下级医联体单位
- 质量要求高：诊疗系统直接关系患者诊断，等保三级必须通过
- 需求变化多：临床科室多、诉求差异大，需求变更频繁
范围管理是项目管理的"边界线"——告诉团队"做什么"和"不做什么"。范围管理不好，要么"范围蔓延"（做多了）、要么"需求遗漏"（做少了），两者都可能导致项目失败。
项目启动后，我首先制定了范围管理计划，明确范围管理的"规矩"。
我定义了范围管理的关键规则：
| 规则 | 内容 |
|---|---|
| 需求变更流程 | 所有变更必须提交变更申请，CCB评审通过后方可纳入范围 |
| 范围偏差阈值 | 偏差超过5%触发预警，启动变更控制流程 |
| WBS分解粒度 | 分解至2-4周能完成的工作包 |
| 范围确认节点 | 每个阶段结束组织里程碑评审会 |
需求收集是范围管理的基础。我采用多种方式系统性地收集需求。
问题：干系人需求模糊、表述不一致，难以转化为具体可执行的需求条目。有的说"系统要快"，有的说"系统要稳定"，但具体什么是"快"、什么是"稳定"，没有量化标准。
方法：我采用四种方式收集需求：
① 一对一访谈——对信息科、影像科、临床科室、院领导进行一对一深度访谈，了解深层期望
② 焦点小组——把医生、护士、技术人员组织起来讨论
③ 原型法——先做个交互原型给用户看，让他们知道系统大概长什么样
④ 问卷调查——给全院影像科医生发问卷，收集使用习惯和痛点
效果：一圈下来，收集到286条需求，建立了需求跟踪矩阵（RTM），确保每条需求都能追踪到设计、开发、测试、验收各阶段。
需求收集完成后，我需要把这些需求转化为项目范围说明书，明确"做什么"和"不做什么"。
项目范围说明书核心内容：
做的：
- 云影像数据采集、存储、诊断、会诊、质控全流程功能
- 和PACS/RIS/HIS系统接口对接
- 等保三级安全防护
- 移动端调阅功能（PC、手机、Web）
不做的：
- 不对原有PACS系统进行改造（只做接口对接）
- 不改动HIS核心业务模块
- 硬件基础设施采购不包含在内（医院另外安排）
把边界说清楚，后面减少了很多扯皮。
我把项目拆成了4个阶段、12个工作包、86个活动。每个工作包都配了WBS词典，写清楚谁负责、要做多久、交付什么。
问题：项目规模大、功能模块多，如果只做到"工作包"级别，颗粒度仍然太粗，无法准确跟踪进度。
方法：采用自上而下分解法，将工作包进一步分解为活动。例如，将"系统开发—影像诊断模块"分解为：需求梳理（2天）、界面设计（3天）、后端编码（5天）、前端开发（5天）、单元测试（3天）、集成测试（2天）共6项活动。
效果：形成了清晰的WBS与WBS词典，估算精度从±30%提升至±15%。
我每个阶段结束都组织里程碑评审会，让干系人看看交付的东西是否符合预期。别等到最后才验收，那样发现问题就晚了。
确认范围的具体做法：
① 里程碑评审会——每个阶段结束，召集核心干系人评审交付物
② 正式签字确认——评审通过后，干系人签字确认范围基线
③ 问题跟踪——对评审中发现的问题建立跟踪清单，确保整改到位
范围管理的核心是"控制"——确保项目在范围内执行，不做额外的事情。
项目做到第5个月，业务部门一下子提出15项新需求！有的要加影像随访管理，有的要加科研数据导出，还有的要预留AI诊断接口。如果都接了，范围还得了？
我组织了需求评审会，用MoSCoW方法给需求排优先级：
- Must have（必须做）：影像随访管理，3项
- Should have（应该做）：科研数据导出，2项
- Could have（可以做）：AI接口预留，2项
- Won't have（暂不做）：8项低价值需求
然后走变更流程：Must have纳入本期范围，Should have放到下期，Won't have直接砍掉。
效果：既满足了核心业务需求，又没让范围爆炸。最终范围偏差控制在5%以内。
偏差分析：我通过偏差分析和趋势分析监控范围。项目中期发现业务部门加了3项报表定制需求，额外工作2人天，偏差率8%。我赶紧启动变更控制流程，避免了范围蔓延。
范围管理的核心是"取舍"——不是所有需求都要满足。在云影像平台项目中，我深刻体会到：需求是"无限"的，但项目资源是"有限"的。项目经理的重要能力不是"满足所有需求"，而是"在有限资源下做出最优取舍"。MoSCoW优先级分类法帮我做出了理性决策。
第一个体会：需求收集要"多渠道"。不能只听一家之言。我用访谈、焦点小组、原型、问卷四种方式，一圈下来收获不少。特别是原型法特别有效——用户看到原型后，往往会说"这不是我想要的"，从而挖掘出真正的需求。
第二个体会：WBS分解要"合理"。粒度太粗不好管理，粒度太细又太繁琐。我的经验是2-4周能完成的工作包最合适——足够细以便于跟踪，又不至于太碎以至于管理成本过高。
第三个体会：变更控制要"有弹性"。完全不让变不行，什么都让变更不行。我的做法是分级处理：小变更快批，大变更走流程。但无论大小，都必须走正式的变更流程，不能"口头答应"。
当然，范围管理也有不足：项目初期对接口对接的复杂度预估不足；对部分"隐性需求"识别不够充分。这些教训提醒我：范围管理要"前紧后也紧"，不能前期重视、后期松懈。
总而言之，范围管理是项目管理的"边界线"。项目经理要明确告诉团队"做什么"和"不做什么"，同时建立变更控制机制，确保项目在范围内执行。云影像平台项目最终范围偏差控制在5%以内，范围管理功不可没。