264_粤北某区县级智慧药房管理系统信息系统项目范围管理

ONEPSOFT | 软考学习知识库

---

2021 年 11 月，为规范基层医疗机构药品流转、降低人工调剂差错，我所在公司中标粤北某区县级智慧药房管理系统项目。建设单位为该地区卫生健康主管部门，合同额 386.46 万元，工期 7 个月，我任乙方项目经理，团队 17 人，下设需求组 3 人、开发组 8 人、集成组 3 人、测试组 2 人、实施培训 1 人。系统覆盖全区 23 家基层机构，实现处方审核、库存预警、智能调剂、追溯监管闭环，技术栈采用服务网格 Istio 治理微服务、多活容灾保障连续性、GaussDB 承载药械主数据、分布式缓存扛峰值。项目面临三个核心难点：建设期内医保目录与处方审核政策调整带来需求变动风险、存量 HIS 老系统接口文档缺失使改造边界难厘清、并发访问峰值集中在上午取药高峰造成性能压力。三者环环相扣，范围一旦失控就会直接拖垮性能与进度。我做过多个医疗信息化项目，知道药房系统容错率极低，一粒药发错就是事故，所以这次我把 " 范围克制 " 当成第一原则，宁可少做也不冒险多做。

鉴于本项目政策敏感、老系统黑盒、峰值压力大，我深刻认识到：范围管理是防 " 做多、做偏、做垮 " 的护栏，必须直面三个难点逐个化解。以下以难点为纲论述我的做法。

一、直面政策调整：以需求收集锁住变动边界

问题摆在面前：建设第 3 个月，医保局调整门诊慢特病用药目录，药房审核规则需同步变更，若需求收集不到位极易范围蔓延。

所谓收集需求，指的是确定、记录并管理干系人需要的过程，其作用是为定义范围奠定基础。我采用访谈、问卷调查与原型法：对卫健、医保业务骨干访谈锁定顶层规则，向 23 家机构发放问卷收集调剂痛点，对模糊的审核逻辑用原型快速验证。需求收集阶段最棘手的是业务方自己也说不清要什么，一位老药师随口说的 " 特殊药品要双签 " 后来被我们原样写进需求文件，并在原型上跑通了流程，他才拍板确认。这种从模糊到明确的反复，靠的就是原型法把抽象诉求变成可点可看的东西。

向机构发的问卷里，" 希望系统能提示近效期药品 " 被提到最多，我们据此把近效期预警写进需求，后来成了药房最爱用的功能。需求收集不是被动记录，而是从一线声音里挖出真正有价值的东西。访谈时卫健主管反复强调 " 审核不能慢，老人排队等不得 "，这句话成了我们所有性能相关需求的最高优先级来源。我把它记在需求文件扉页，每次有人想加非必需功能，就拿这句话挡。需求收集阶段定下的基调，管住了后面整个项目的范围胃口。

为防政策再变，我建立需求跟踪矩阵（RTM），将每条需求映射到设计元素与测试用例，政策每次调整只需增量更新对应行，避免全量返工。例如目录调整后，仅更新 " 慢特病审核 " 相关 6 行即完成同步，未波及其他模块。需求跟踪矩阵的妙处在于，当目录调整时我们不用通读上百条需求，只需顺着映射行定位到相关项改掉即可，改动范围清清楚楚。需求文件评审那天，卫健、医保、机构三方第一次坐在一张表里对账，过去靠口头传达的隐性要求全被摊开。有两条互相矛盾的规则当场被揪出并消去，避免了上线后的扯皮。需求收集的价值，不止于 " 记下来 "，更在于 " 对清楚 "。最终形成 108 条需求文件并通过评审，从源头框定范围，让 " 该做哪些 " 有据可依，也把政策变动框进了可控的增量里。

二、破解老系统黑盒：以创建 WBS 厘清改造边界

问题摆在面前：存量 HIS 系统接口文档缺失，厂商人员更替，哪些接口要改造、哪些可复用无人说得清，范围极易 " 滚雪球 "。

所谓创建 WBS，指的是将可交付成果分解为更小、更易管理组件的过程，其作用是提供结构化视图、界定工作包边界。我采用分解技术遵循 100% 原则，带领团队把项目拆为 " 处方审核引擎 "" 库存与调剂 "" 追溯监管 "" 系统集成 " 四个一级分支。分解 WBS 时团队曾想把 " 老系统对接 " 做成一个大包，我坚持拆细，因为大包最容易藏边界。拆到接口级别后用亲和图聚类，可复用、需改造、需新建三类一目了然，我们把改造严格锁在 28 个接口，新建的 9 个也写明了输入输出。

亲和图聚类还暴露一个隐患：老系统里有 7 个接口看似可复用，实则是不同厂商各自写的同名异构接口。若不加区分全收，会埋下数据错乱的雷。我们在 WBS 里把这 7 个单独列为 " 异构适配 " 工作包，明确由集成组专人核对，没让它们混进可复用清单。拆分时最大的争论是追溯监管要做到多细，有人想做到每盒药扫码，我认为那会无限扩大范围且拖慢高峰。经与卫健确认，定为 " 批次级追溯 " 即可，既满足监管又守住性能。这个取舍写进 WBS 词典，成了后来拒绝过度细化的依据。

再逐层分解至工作包，并配套 WBS 词典明确每个包的验收标准与负责人。配套词典里连 " 库存同步工作包的验收以三方盘点一致为准 " 这样的细节都写进去，后来确认范围时对照它，谁都没法浑水摸鱼。WBS 让 " 改造到哪为止 " 一目了然，成为范围确认的硬依据，也避免了无边界的接口摸索，把隐性边界变成了显性清单，从源头掐断了 " 顺手多接 " 的蔓延冲动。WBS 词典还约定了 " 集成组与开发组每日对齐接口清单 "，把边界意识变成日常动作。后来老系统又冒出两个隐藏接口，正是因为这道日常核对，才没让它们悄悄混进范围。

三、扛住并发峰值：以范围确认与控制防蔓延保性能

问题摆在面前：上午取药高峰并发可达平峰 8 倍，若随意加功能会进一步压垮性能，必须在确认与控制上扎紧口子。

所谓确认范围，指的是正式验收已完成可交付成果的过程；所谓控制范围，指的是监督范围状态、管理范围基准变更的过程，二者共同防止范围蔓延。我在每个里程碑组织卫健信息中心与机构代表逐项确认，采用检查对照 WBS 词典与需求规格。每个里程碑的确认会我都坚持让机构代表当场点开系统实操，而不是只看演示视频。有次一家机构代表现场录入处方，发现审核提示语有歧义，我们当场改掉，避免了上线后的批量困惑。确认范围贵在 " 真用真验 "，不是签字走形式。对于高峰性能的边界，我在范围说明书中写入 " 核心取药链路响应≤1.5 秒 " 的硬性验收项，任何新增功能若触碰该指标一律走变更。

直方图让我们看清高峰到底卡在哪。处方查询占了六成以上调用，说明性能瓶颈在审核引擎而非库存。我们据此把范围确认的压测重点放在审核链路，并把 " 核心响应不超 1.5 秒 " 写进验收硬指标。第 5 个月，某机构提出 " 取药大厅增设人脸识别取药 "，我评估其会突破性能基线且非必需，经 CCB 评审否决、纳入二期，守住了范围红线。被否后该机构当场表示理解，因为我们在 CCB 上用直方图展示了它会如何挤占高峰算力。范围控制不是冷冰冰的拒绝，而是用数据讲清楚为什么不能加。范围确认会之外，我还要求测试组把 " 高峰压测不达标即不验收 " 写进准出准则，让控制范围有了可执行的硬杠杠，而不是靠我一个人口头把关。准出准则让范围控制从主观判断变成了客观门槛，也让我不必事事亲扛。最终核心响应由 4.2 秒降至 1.1 秒，系统可用率稳定在 99.9% 以上、全年重大故障 0 起。

项目如期交付，关键业务响应由 4.2 秒降至 1.1 秒，业务差错率由 2.7% 下降至 0.3%，可用率稳定 99.9% 以上、全年重大故障 0 起。回顾全程，范围管理是防失控的护栏：需求收集锁变动、WBS 厘边界、确认与控制防蔓延，三管齐下让智慧药房真正兜住了基层用药安全，也让我对 " 做且只做必需的工作 " 有了更切实的体认。下一次面对类似民生系统，我会更早把 " 范围克制 " 写进团队共识，让护栏立在开工第一天。