云影像平台项目涉及的功能特别多，从影像采集到诊断、会诊、质控，还有教学系统、存储系统等等。范围管理做不好，很容易陷入"需求蔓延"的坑。我在这个项目里，通过WBS分解、需求跟踪矩阵、严格的变更控制，把范围管得死死的。最终范围偏差控制在5%以内，没出现那种做到一半发现范围完全失控的情况。
云影像平台要建设四大块：云影像系统（这是核心，有11个子模块）、影像诊断教学系统、云影像前置机系统、业务及存储系统。
技术方面用的是Spring Cloud微服务架构，Nacos做服务注册发现，Gateway做网关，Sentinel做熔断，RabbitMQ做消息队列，MySQL主从做数据库，Redis做缓存，MinIO存DICOM影像文件，Elasticsearch做全文检索。
云影像系统具体要实现的功能包括：影像数据采集和归档（支持DICOM和HL7协议）、检查互认和共享调阅、多终端调阅（PC、手机、Web都能用）、影像咨询问诊、质控分析评价、典型病例管理、读片记录管理、随访管理、互联网写报告、控制台展示、运维监控平台。
功能太多太杂，如果不把范围管好，随时可能失控。
项目启动后，我做的第一件事就是制定范围管理计划。这东西就是"规矩"，告诉团队什么该做、什么不该做、变更该怎么处理。
我定了几个关键规则：需求变更必须经过评审；范围偏差超过5%要预警；WBS分解到2-4周能完成的工作包；每个阶段结束都要做范围确认。
需求收集是个体力活，我用了不少办法：
一对一访谈：找信息科、影像科、临床科室、院领导聊，了解他们到底想要什么。
焦点小组：把医生、护士、技术人员组织起来，大家一起讨论。
原型法：先做个交互原型给用户看，让他们知道系统大概长什么样，比直接写文档更直观。
问卷调查：给全院影像科医生发问卷，收集使用习惯和痛点。
一圈下来，收集到286条需求，建立了需求跟踪矩阵（RTM），确保每条需求都能追踪到设计、开发、测试、验收各阶段。
需求收集完了，我得把这些变成项目范围说明书。简单说就是回答两个问题：做什么？不做什么？
做的：云影像数据采集、存储、诊断、会诊、质控全流程功能；和PACS/RIS/HIS系统接口对接；等保三级安全防护；移动端调阅功能。
不做的：不对原有PACS系统进行改造（只做接口对接）；不改动HIS核心业务模块；硬件基础设施采购不包含在内（医院另外安排）。
把边界说清楚，后面减少了很多扯皮。
我把项目拆成了4个阶段（需求分析、设计开发、测试部署、验收交付）、12个工作包、86个活动。每个工作包都配了WBS词典，写清楚谁负责、要做多久、交付什么。
项目做到第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%。我赶紧启动变更控制流程，避免了范围蔓延。
做范围管理，我的体会是：
需求收集要全面——用多种方式、多角度去了解需求，别只听一家之言。我用访谈、焦点小组、原型、问卷，一圈下来收获不少。
WBS分解要合理——粒度太粗不好管理，粒度太细又太繁琐。我的经验是2-4周能完成的工作包最合适。
变更控制要有弹性——完全不让变不行，什么都让变更不行。我的做法是分级处理：小变更快批，大变更走流程。
不足的地方：有时候开发团队会"镀金"，主动实现一些不在范围里的功能。虽然是出于好意，但确实给管理带来麻烦。后来我强化了需求评审，这情况少多了。