Appearance
范文二：项目的范围与需求管理（原创模拟范文）
本页导读：本篇为原创模拟范文（非真题答案、非考试原文），主题为信息系统项目的范围管理与需求管理。按"摘要 300 字内 + 正文 2200 字以上"考场形态组织，项目背景为虚构模板素材。本篇突出"范围蔓延与镀金"这条最好写的故事线。文末附"本文亮点与可替换素材"。
【模拟考场题目·自编】 论述你参与过的信息系统项目中，作为项目经理是如何进行范围（含需求）管理的。
摘要
2024 年 9 月，我作为项目经理参与了某三甲医院临床信息集成平台项目建设。该项目合同额 1200 万元，工期 9 个月，旨在打通 HIS、LIS、PACS 等 11 套在院系统，实现患者主索引统一、临床数据集中调阅与双向转诊协同，采用微服务架构与院内私有云部署。业务科室需求发散、流程个性化诉求多、政策口径时有调整，范围与需求管理难度大。本文结合项目实践，从规划范围管理、全面收集与确认需求、创建 WBS 与定义范围基准、多手段控制范围蔓延、正式开展范围确认五个方面，论述我在范围与需求管理中的方法与措施。项目于 2025 年 6 月按期验收，需求一次确认通过率达 92%，未发生范围失控事件。相关实践可为同类医院信息化项目借鉴。
一、项目背景
该医院拥有 2200 张床位、日均门诊量约 9000 人次，信息化建设多年形成的 11 套业务系统彼此孤立，医生调阅患者历史检查结果需登录多个系统，双向转诊靠电话与传真。2024 年 9 月，医院立项建设临床信息集成平台，我公司中标，合同额 1200 万元，工期 9 个月，我担任项目经理。
项目建设内容包括：患者主索引（EMPI）管理、集成引擎与标准化接口改造、临床信息统一门户、双向转诊协同模块、数据质量监控大屏。技术路线采用微服务架构、HL7/FHIR 医疗数据标准与院内私有云，涉及与 HIS、LIS、PACS、体检系统等 11 套系统的接口对接。项目组共 26 人：开发 14 人、测试 4 人、实施 4 人、需求与设计 2 人、QA 与配置管理员各 1 人。我采用矩阵式管理，直接对接医院信息科、医务处以及临床科室代表组成的甲方项目组。
医院项目的特殊性在于：需求提出方是几十个临床科室，各自对"好用"的标准不一；同时卫健委互认互通政策在项目期内不断细化，政策性需求会随时插入。这些因素叠加，使范围与需求管理成为本项目最重要的成败变量。
二、规划范围管理，先立规矩
启动会上我就意识到，这个项目最大的风险不是技术，而是"需求长什么样才算数、变了怎么办"。因此我在规划阶段编制了《范围管理计划》与《需求管理计划》，明确三件事：一是需求唯一入口——所有需求必须由甲方信息科汇总后书面提交，开发人员不得直接接受临床科室的口头需求；二是需求分级授权——影响工时 5 人天以内的需求由甲乙双方项目组例会确认，超过 5 人天的必须走变更控制流程提交 CCB 决策；三是文档模板与工具——统一使用需求跟踪矩阵，需求编号、来源、状态全程可溯。规矩立在事前，比事后补救成本低得多，这份计划后来成为整个项目范围秩序的基石。
三、全面收集需求，定义范围并形成基准
需求收集阶段，我组织需求分析师用了三周时间，综合运用访谈、问卷、联合需求计划（JRP）研讨会与原型演示等方法：对医务处与信息科做结构化访谈，摸清政策性合规要求；对 12 个重点科室发放问卷，收集高频调阅场景；组织两场 JRP 研讨会，把医务处、护理部、信息科与各科室代表拉到一起，当场澄清"双向转诊谁发起、病历摘要包含什么"等争议问题；对统一门户界面，用 Axure 做可点击原型，让医生在演示中直接提出修改意见，避免了文字需求的抽象歧义。
收集到的原始需求条目共 386 条，我组织团队做需求分析与优先级排序（采用 MoSCoW 法分为必须有、应该有、可以有、暂不做四类），逐条编写入《需求规格说明书》。对每条功能需求，同时记录其非功能约束（响应时间、并发、数据一致性），防止验收阶段扯皮。11 月中旬召开需求评审会，医务处、信息科、临床科室代表与监理方逐条确认，SRS 正式签字确认，形成需求基准。
随后我组织创建 WBS：以交付物为导向，将项目分解为平台建设、接口改造、门户开发、转诊协同、数据质量、培训与试运行 6 个一级包，再逐层分解到 160 余个工作包，每个工作包明确责任人、工期与验收标准，配套形成范围说明书与 WBS 词典，构成完整的范围基准。
四、多手段控制范围，守住基准
范围基准建立后，真正的考验才开始。执行期我主要通过三个手段控制范围。
第一，需求跟踪矩阵全程贯通。从原始需求到设计、代码、测试用例全部建立追踪关系，每两周核对一次，确保"需求—设计—实现—测试"不脱节，杜绝"做完了才发现漏需求"或"做了没人要的功能"。
第二，坚决对范围蔓延和镀金说"不"。2025 年 2 月，心内科主任在系统演示后直接找到我们的门户开发工程师，要求"顺手"把心电图的波形放大功能做得更炫一些，工程师碍于情面当场答应并额外花两天做了动画效果。我在周例会上发现后立即纠偏：向团队重申"基线外需求一律先走流程"，同时向心内科主任说明——动画效果虽好，但占用联调窗口期，建议其通过信息科提交。该需求经评估为 3 人天工作量，例会确认后排入下个迭代。类似情况项目期间共出现 8 起，全部被引导进入正规渠道，无一例演变为范围失控。
第三，偏差监控常态化。我在挣值监控中同时盯 SPI 与范围指标——已完成工作包数与计划工作包数的对比。3 月月度分析发现接口改造分项"完成 42%、计划 45%"，排查确认是两家厂商系统接口文档过期导致返工，属执行问题而非范围蔓延，随即安排厂商接口澄清会，避免误判为需求失控而错误收紧范围。
五、正式开展范围确认，让交付"步步签字"
许多项目把范围确认留到验收，风险极高。我将范围确认嵌入里程碑：每个阶段交付物（SRS、概要设计、集成平台测试版本、试运行版本）完成时，都组织甲方正式评审并签字。统一门户在 4 月中旬完成首版交付时，医务处提出"病历摘要页签顺序调整"，因处于阶段确认节点、且属 3 人天内小调整，双方例会确认后一周内完成，未影响基准。到 6 月正式验收时，由于每个阶段的范围都已被逐项确认过，验收会仅用半天即通过——正式验收时 92% 的功能点一次确认通过，剩余问题集中在数据历史迁移展示细节，两周内关闭。这种"化整为零、步步确认"的做法，把范围确认从"最后的大考"变成了"平时的小测验"。
六、结束语
项目于 2025 年 6 月按期验收，平台日均调阅 3.2 万次，医生跨系统调阅时间从平均 90 秒缩短到 8 秒，患者重复检查率明显下降，医院授予项目组年度优秀合作团队。回顾全程，范围与需求管理的核心经验有三：规矩先行，需求入口与变更授权在启动阶段就书面化；基准必签，SRS 与 WBS 不签字不开发；蔓延严管，对口头需求与镀金行为零容忍但态度上引导有方。项目也有不足：JRP 研讨会未能覆盖全部 40 余个科室，个别边缘科室（如营养科）的需求在试运行期才浮现，只能列入二期；需求跟踪矩阵前紧后松，后期更新有滞后。今后我将在启动期就完成干系人全覆盖分析，并把跟踪矩阵更新纳入质量审计清单。范围管理的本质，是让所有人对"做什么、不做什么"始终达成一致——这句话是我此项目最深的体会。
本文亮点与可替换素材
亮点：
- 故事线聚焦"范围蔓延/镀金"经典冲突（心内科主任"顺手加需求"），场景真实、对策完整；
- 需求收集方法成体系（访谈/问卷/JRP/原型），方法名全是教材术语，踩给分点；
- WBS 数字具体（6 个一级包、160 余工作包）、需求条目 386 条、一次确认率 92%，量化密集显真实；
- "阶段化范围确认"是本篇差异化亮点：把确认化整为零，验收半天通过；
- MoSCoW 优先级法、需求跟踪矩阵等工具自然嵌入，理论与实践比例得当。
可替换素材：
- 行业替换：三甲医院→银行（手机银行）/高校（教务平台）/物流（TMS）；
- 冲突替换：心内科主任加需求→某业务副总要求"加个大屏好看点"；
- 数据替换：386 条需求/160 工作包按项目规模同比缩放；
- 方法替换：JRP→焦点小组；MoSCoW→权重打分法；
- 结果替换：调阅 90 秒→8 秒→报表生成 30 分钟→3 分钟。