“我们原计划用六个月，花300万，把一个V3.0的医院，升级成V4.0。”
“结果我们用了一年，花了580万，差点把公司搞破产。”
周总在复盘会上，第一句话就把大家逗笑了。
这是软佳内部，关于XX医院V4.0项目的正式复盘。
参与人员：项目全员（实施、开发、运维、测试、产品）30多人。
周总：”我们不谈’成绩’，只谈’学到了什么’。因为只有教训，才能让你进步。”
1. 需求调研：我们踩的第一个坑
“项目开始时，我们以为需求很清晰。”产品经理小王说。
“毕竟V4.0不是全新项目，是在V3.0基础上的升级。V3.0有哪些功能，客户满意哪些、不满意哪些，我们做了调研问卷。”
但问题出在：问卷写得不好。
问卷问题是：”您对V3.0系统满意吗？A.满意 B.不满意 C.一般”
“有多少人选C？”周总问。
“80%。”小王说。
“那’不满意’的具体是什么？”
“问卷后面有开放题，但大家懒得填。我们只能靠猜测。”
周总摇头：”这就好比医生问病人’你舒服吗？’病人说’还行’，然后医生就开药了。”
他们真正搞清楚需求，是用了一招：蹲点观察。
实施团队派出三个人，分别在挂号处、护士站、医生办公室，各待了三天，记录每一个操作，记录每一个抱怨。
“才发现，他们最痛的不是’功能不够’，而是’流程卡顿’——排队两小时，窗口操作三分钟，其中两分钟在等系统。”
“还有，很多功能有，但没人用，因为太复杂。”
“所以需求不是’加功能’，是’减流程’。”
2. 方案设计：我们相信了”标准答案”
“根据需求，我们设计了V4.0方案。”技术负责人老周说。
“方案里有很多’最佳实践’——来自其他医院的经验。比如’医嘱闭环管理’、’移动查房’、’智能分诊’…”
“但XX医院的人，看到方案就摇头。”
“为什么？”
“他们说：’我们要的是’挂号快、收费准、病历好找’，你们这些’高大上’的功能，我们用不着。我们人手不够，没精力学新东西。'”
老周说，他们犯的错是：把其他医院的成功经验，当成标准答案，强加给XX医院。
后来他们改了：不做”标准方案”，做”场景化方案”。
他们和XX医院的医生、护士、收费员，一起梳理了”核心场景”：
– 门诊挂号（平均8分钟，目标5分钟）
– 医生开医嘱（平均3分钟，目标2分钟）
– 护士执行医嘱（平均2分钟，目标1分钟）
– 住院结算（平均15分钟，目标10分钟）
然后，每个场景，单独优化。
比如，”医生开医嘱”场景，他们去掉了一切与开药无关的功能（比如科研数据录入），把常用药放在前面，做成快捷键。
“减功能，比加功能更难。”老周说。
但减完后，医生满意度飙升。
3. 开发阶段：我们低估了”一致性”
“开发过程中，我们犯了一个低级错误——前后端接口，没有统一规范。”后端工程师小李说。
“前端要一个’患者基本信息’接口，后端A同事给了A版本；前端要’医嘱列表’，B同事给了B版本。字段名不统一，分页方式不统一，错误码也不统一。”
“结果联调的时候，前端怨声载道。一个简单的需求，要对接三四次才能通。”
周总问：”为什么没做接口规范？”
“有规范，但没人执行。”小李低头。
“这是管理问题，不是技术问题。”
老周说：”我们后来強制推行了’接口契约先行’——任何接口变更，必须先写契约文档（OpenAPI），前后端一起review，然后才能开发。”
这个制度，救了后期很多时间。
4. 测试阶段：我们发现”数据质量”是魔鬼
“测试阶段，我们用了两周时间，覆盖所有功能。所有用例通过率98%，以为稳了。”
“结果数据迁移一跑，问题全出来了。”
测试环境的数据，是”干净”的——每条记录都完整，编码规范，关联正确。
生产环境的数据，是”脏”的——三年的数据，有重复患者、有缺失字段、有错误编码、有历史遗留的”影子记录”。
“我们迁移第一天，失败率30%。”
“为什么测试环境没事？”
“因为测试环境数据是我们自己造的，我们知道边界。生产数据是历史积累，我们不知道的坑太多了。”
老周说：”这次教训是：数据迁移测试，必须用生产数据的脱敏副本，不能用测试工厂数据。”
他们连夜把生产环境数据脱敏，拷到测试库，重新跑迁移脚本。又发现一堆问题：
– 患者身份证号有重复（历史数据错误）
– 药品编码不匹配（新旧编码转换表有遗漏）
– 医嘱时间格式不统一（有datetime有string）
这些问题，一条条手动清洗，写了50多个清洗脚本。
“数据迁移，占项目总工时的40%。”老周说。
“但这是必须花的。数据是资产，迁移错了，系统再好也白搭。”
5. 上线前：我们差点”栽”在培训上
“上线前一周，我们给全院做了培训。”小张说。
“培训方式是：大礼堂，一次性讲所有功能，然后发手册。”
“结果呢？”
“反馈：’听不懂’、’信息量太大’、’回去就忘了’。”
“培训后考试，及格率40%。”
小张意识到，这种培训方式不行。
他连夜改了方案：
– 分批次培训，按角色：挂号员、收费员、护士、医生、科主任
– 每个角色，只培训他们要用到的功能（平均每人20个功能，而不是200个）
– 培训后，当场实操，每人登录测试环境，完成三个典型任务
– 三天后，再培训一次，这次只讲难点
第二次培训，及格率90%。
“培训不是’灌输’，是’教会使用’。”小张说。
“而且培训要分多次，第一次讲基础，第二次讲进阶，第三次讲问题收集。”
6. 上线日：我们的”双跑”方案
“上线日，我们用了’双跑’方案——新旧系统并行运行。”老周说。
“为什么不用’一刀切’？”
“因为数据迁移没完全做完，有部分模块数据不一致。’一刀切’等于把旧数据锁死在新系统，一旦有问题回不去。”
“双跑方案，是新系统处理新业务，旧系统处理旧业务。等新系统稳定了，再把旧数据逐步迁移过来。”
“但双跑有风险——两个系统数据要同步，不能冲突。”
“比如，病人在旧系统退费，新系统不知道；新系统开医嘱，旧系统查不到。”
他们做了数据同步中间件，每隔5分钟，把双方的变更同步一次。
同步规则很复杂：
– 冲突解决：新系统优先
– 删除操作：双向删除
– 修改操作：后写的覆盖先写的
“这个同步中间件，是我们上线前两周紧急开发的。”小吴说。
“为什么早不做？”
“因为没想到双跑方案要用到同步。我们以为数据迁移能在上线前完成。”
教训：预案要早做，不能临时抱佛脚。
7. 上线后三个月：真正的考验
“上线后第一个月，是’救火月’。”运维工程师小王说。
“每天都有新问题：这个科室不会用，那个功能报错，另一个数据对不上。”
“我们成立了’上线保障组’，七个人，24小时 on-call。”
“最长一次，连续48小时没睡，因为数据同步出bug，导致重复收费。”
但三个月后，系统稳定了。
“怎么稳的？”
“两个原因：一是我们快速响应，问题出现后4小时内解决；二是我们做了’渐进式优化’——不是一次改完，是每周优化一点。”
比如，发现”医嘱开立”慢，我们分析发现是药品搜索慢；优化搜索后，发现是下拉列表加载慢；优化下拉后，发现是缓存穿透…
一个问题，可能要改三四次，才能彻底好。
“但这就是迭代的意义。”小王说。
8. 客户方的变化：从怀疑到信任
“项目刚开始，李主任天天盯着我们，动不动就威胁’要换供应商’。”小张说。
“三个月后，他开始主动提需求，比如’能不能加个慢病管理模块’。”
“六个月后，他在班子会说：’软佳虽然贵，但值。'”
“为什么转变？”
“因为我们兑现了承诺——’上线不是结束’。我们持续优化，持续服务，让他 seeing 我们在乎。”
9. 复盘会的结论：提炼方法论
周总最后说：
“XX医院项目，是我们目前最成功的案例。但成功不是’运气好’，是’把该踩的坑都踩了一遍，然后爬出来了’。
我们总结出(‘三三制’)方法论：
三个阶段：
1. 需求阶段：少说多听——让客户说出’真实需求’，而不是’表面需求’
2. 开发阶段：少做多想——做核心功能，想扩展性
3. 上线阶段：少言多做——用行动建立信任，不是用话术
三个原则：
1. 透明——问题不隐瞒，进度不隐瞒，风险不隐瞒
2. 敏捷——小步快跑，快速迭代，不追求一次完美
3. 客户成功——我的成功=客户成功
三个底线：
1. 数据不能丢
2. 业务不能停
3. 安全不能破
守住了这三个底线，再大的问题，都能解决。
守不住，再好的方案，都是空中楼阁。”
10. 写在最后：项目不是”做完”的，是”养”大的
周总最后说了句话：
“很多人觉得，项目交付了，就结束了。
但我觉得，项目交付，才是真正的开始。
系统上线后，要养——像养孩子一样，发现病灶及时治，定期体检，不断优化。
XX医院V4.0，现在还在’养’的过程中。我们每周去一次，每月优化一次。
(‘服务即产品’)。
我们卖的不是软件，是’持续服务’。
软件会老化，会落后，会出问题。但只要服务在，就能让它一直有用。
这就是我们的护城河。”
互动话题
你经历过最深刻的一次项目复盘是什么？学到了什么？
> 基于真实医院场景改编，人物均为化名
立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html
手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）
支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
