郭扬帆：HIS系统上线宝典｜需求分级，紧快赶慢

需求是HIS项目最大的“焦油坑”。十多年前我读了一本好书：《走出软件作坊》，阿朱著，至今还在受益。“焦油坑”，在人类史前时代，没有别的场景比巨兽在“焦油坑”中垂死挣扎的场面更令人震撼。造物者见证着恐龙、猛犸象、剑齿虎在焦油中挣扎，它们挣扎得越猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧去挣脱束缚，到最后它们都沉到了坑底。红军在过草地时，不小心陷入泥沼，若旁边没有战友，或没有足够长且结实的工具协助，最终都慢慢陷入泽地失去生命。人类区别于动物的一点是使用工具和知识传承。

需求分级管理，是一名合格项目经理最重要的任务之一。需求分级有二个层面：一是需求管理层面；二是需求紧急重要程度判定层面。

HIS实施期间，需求满天飞，若没有规范的收集、跟踪、处理流程，信息科与HIS公司都将陷入需求的“焦油坑”。需求产生有一定规律可循，一般有以下几个阶段。

1.进场阶段的怀旧性需求。

此阶段因为对新HIS系统还不太了解，需求不多，矛盾还未出现，主要想把旧HIS系统一些好的功能移植过来。再烂的旧HIS，总有几处可借鉴的好功能，特别是一些实用的小工具，一线人员使用习惯了，这些怀旧性需求，会最早被提出来让新HIS公司修改。还有一些是流程上的习惯，各类外部系统接口等，都是新HIS进场要全盘接收的需求。

2.培训阶段的易用性需求。

如果培训之前，能够改出一版怀旧性需求，再换成自己医院的数据环境，那么培训的效果一定比拿其他医院的备份环境，要好很多很多。但经常时间不允许，能保证流程不出错就算不错了。培训阶段主要还是让一线操作人员熟练掌新HIS的流程、功能特点和注意事项，操作人员总会代入到旧HIS的场景来对新HIS提出一些易用性的要求，甚至会要求改成与旧HIS界面一模一样。这需要培训老师有极强的说服能力，不然就会被扯入需求的泥潭。同时，信息科也要发挥行政管理的作用，合理的需求还是要收集采纳，不合理要进行制止，不要陷入是非对错之争，保留意见，先学习新HIS的功能，然后考试，不合格全院通报。此阶段开始了解新HIS系统，需求不会太多，仍有怀旧情结，会产生一定冲突，但还在控制范围之内。

3.上线阶段的各类爆发性需求。

此阶段是需求和矛盾最集中的时期，严重到可以导致上线失败。因为在正式医疗环境中运行，以前隐藏的BUG、未测试到的波及范围、接口不稳定不完善、数据报错、高峰期阻塞、更新一个功能点引发更多的错误等等。一天上百个需求都算正常，此阶段不能按常规来填申请表走流程审批修改。特别是出错性需求，要立即马上进行修改，所以一天发布N个版本都是正常的。首先要保证诊疗流程能走得下去，医嘱不要出错，费用不能出错，每天晚上一定要集中开会，花时间进行需求清理和归类，根据轻重缓急统筹安排修改顺序，可以用最简便的EXCEL表格进行记录。

4.运维阶段的优化性需求。

此阶段是解决HIS系统从“能用”到“好用”的需求，持续的过程一直到被下一个新HIS换掉。验收前会有几波需求集中收集整改，验收后需求会逐步减少，此阶段都需要按照需求申请单的格式和流程执行。

理解需求产生的各阶段规律，对我们管理需求有很大帮助，这是一名HIS熟手或项目经理应具备的职业素养。

“需求唯一接口人”，这是我在2012年《医疗卫生信息化项目管理实务》一书中提出来的理念，我们不但要有规范的需求单格式和流程，还要具体到由谁来管理需求。三甲医院的员工2、3千人，每个人一口唾沫都可以把你淹死，何况咱们的HIS系统哪天不是一堆待处理的问题？“需求唯一接口人”并非只有一个人，原则上要求每个科室由一个人负责收集整理本科室的需求，然后汇总上报给主管部门指定的一个人来进行综合研判，通过后再提交给信息科进行技术分析，细化需求，转换成HIS公司能够理解的语言，这时才是真正的信息化需求修改单，HIS公司项目经理再将需求提交给研发。真正执行时，主管部门的需求接口人，会过滤掉大部分无效的需求，将真正有用的需求，会与信息科和HIS公司的工程师，先商议出解决的方案后，才开始填写需求申请单，复杂的需求会由信息科的工程师代为填写。出错性的需求，相对简单，贴上出错的原图，再标出改进的意见，即是一张完美的需求申请单；涉及多部门的需求，可能会召开多次专题会来理清流程和功能点。

在需求管理这件事上，信息科不能来者不拒。如果实现难度特别大，又非紧急重要的需求，还会给系统造成性能或安全上的压力，还不好拒绝时，信息科可以退后一步，将需求描述得很复杂，把相关科室拉得多多的，让需求主管部门来组织会议，美其名曰集体讨论决策，由他们先把流程、功能吵清楚后，再让他们提供需求申请单，相关科室必须会签意见，那么信息科就可以在旁边看热闹，这样的需求基本上就会缓好长一段时间，甚至不了了之。

我院HIS项目实施过程中，所有的需求必须经过我签字后，才提交给HIS公司的项目经理，HIS项目经理也只认我的签字或口头交待，才会将需求单分配给研发人员。把握好这个关口，医院再多再复杂的需求，都不会出现大的差错。

临床人员提出的每一个需求，他们认为都是最重要紧急的，恨不得上午提的下午就能搞好，今天提的明天就能实现，若二、三天还没有动静就会打电话来催你了，一周没有动静就投诉到领导那了，多几次不回复，临床就不愿意再提需求了。

解决这个问题其实很简单，主要是沟通不到位。一是要告知按正规流程提需求，微信上的图文语音一律不算；二是在接收确认需求时，请告知他一个开发大概完成的时间，若条件允许最好邀请他来参与测试，最后再告诉他软件版本发布的时间。

需求很多时，让他们挑出自认为最紧急重要的需求排个顺序，先做二、三个，就像在饭馆吃饭，先上两个菜客人就不会老催了。

同一个功能模块，可能有不同部门提出多个修改需求，最好统一在一次完成，做好综合研判，减少重复修改。即便时间上有所耽误，但总的时间和出错机率会大大减少。

常规情况下，数据出错性的需求最好插队安排在下一个版本就修改好，逻辑性错误可以通过行政命令先人为避免，后继尽快完善。独立明确的需求，与其他模块交互不多，可以优先安排。临床特别关注的、影响使用体验的需求，可以优先安排。

医保和主管部门政策性需求，往往来得急、有明确的完成时间节点，是最强需求，其他需求都要暂时让步。所以我们在安排其他需求时，要适当预留出一定时间，实在做不完时，要做好解释工作。

我院HIS项目自2020年2月进场实施，截止到2021年9月底即国庆前。约2500个有效需求紧快赶慢，终于全部清空，我一直紧绷的弦终于放松下来，虽然后面一直有新的需求产生，但已非重要紧急或者我们已有余力很快完成。这种心理的放松是妙不可言的，每天都睡得比较踏实了。

紧快赶慢，综合研判，时间预留，进度公告。目前我们没有在院内部署一套需求修改进度查询的系统，建议有条件的医院可以开放这个功能，可以减少很多误会，可以提升临床人员的参与感和获得感。

未完待续

作者简介

郭扬帆，软件工程硕士，高级工程师，南方医科大学顺德医院信息科主任。广东省首席信息官协会医疗分会副会长，广东省卫生经济学会信息分会副会长，广东省医疗信息安全专业委员会副主委，顺德医学会医学信息学分会主委等。主编著作二部《医疗卫生信息化项目管理实务》、《医院网络安全建设指引》，担任多部著作编委。1997年从事医院信息化工作，先后经历过多次甲方、乙方角色换位，积累了丰富的项目管理经验。