我之前在HIT专家网上看到山东德州好德康复医院信息科沙志文，“信联体”：一名基层医院信息科人员对未来出路的思考,文章中写一个基层医院信息人的现状，信息科可能就是1-2个人，说学斗唱样样都要会，俗称“万金油”。医联体引出提出建立“信联体”想法，希望信息科建立一个扶贫机制。技术力量薄弱，人员又少，特别希望得到别人的帮助，这种心情我很理解，所以我周末和休息的时候花了一些时间写了一个专栏，根据我“半桶水”知识做毫无保留分享给大家。

一、需求分析

    首先要看针对某一类问题，有没有发布相关行业规范或者是政策文件，比方电子病历书写规范、各种医保政策等等。

举例说明：曾经有位兄弟医院咨询我一个问题，实习医生单独值夜班，要开医嘱怎么办，电脑上怎么解决？我问为什么有这个问题，因为医生人手不足，医务科想让实习医生可以开签名医嘱，电脑怎么实现？

我说你这个问题本身就有问题，卫生主管部门制定政策文件明文规定未取得医生执业资格证是不能开签名医嘱。好比你让未取得驾驶证的人去开车，他都可以开，只是违法了。

      当我们遇到一个不合理的需求的时候，首先看是否符合相关的规范或政策文件。

在以住的开发过程当中，我会经常运用以下几个方法来进行：

第一个方法：借鉴法

当你接一个需求的时候，可以参考其他医院成功的解决案例。一般不建议从零开始做需求调研，别人成功的解决方案，可以帮助我们节省大量时间，我只需要跟业务科室敲定成功案例是否符合我们医院的实际需求，或者经过适当改造满足本院的需要，需求分析就这样做完了，剩下就是开发实现相似的功能。

举例说明：我开发的“产程进展图开发启示录”模块，先叫产科去了解其他医院是否有实现这个功能，把相应的软件操作截图，或者小视频，然后“产程进展图“每个部份怎么填，填写什么含义搞清楚，就可以开发了。别人的成功的案例，软件做成什么样子，最终达到什么效果，我们精确找到用户对软件预期，从而可以减少开发失败的风险。

第二个方法：用户需求层次的挖掘

        用户通常只会告诉我要什么，不会告诉我们为什么？首先来普及的一个商业对于一个用户需求经典案例。比如，一个用户想买一个电钻。  他是真的想买一个电钻吗？  不是的，他是想在墙上打个洞。可他真的只是想在墙上打个洞吗？  不是的，他想在墙上挂一幅全家福。  如果，我们挖掘到这一层，知道用户其实是为了想在墙上挂一幅全家福，那么我们就不用一定给用户提供电钻，我们给他提供无痕挂钩就行了。  继续挖。  用户为什么会想在墙上挂一幅全家福？  是不是他想回忆起一些与家人共度的美好时光。那他回忆这些美好时光为了什么？  因为这些美好时光能让他分泌更多的多巴胺，让他感受到快乐、幸福。  再挖？  不用再挖了。到多巴胺，到生理上的需求，我们就结束了，不再挖了，再挖就是生物学、化学等知识了。  所有的产品挖掘用户需求，到最后一定是多巴胺。  那你要画一条线，画一条从产品到多巴胺的线，然后你去寻找你的产品在哪个层次上满足用户的需求。  （以上内容摘自刘润公众号，如何做好一款产品，这6点建议，请笑纳）

举例说明：

第一个例子：手术术后登记簿的开发，某日我接到临床医生的电话：

“能帮我设计一个程序 ，可以录入手术信息的”，（用户通常只会告诉我们要什么，不会告诉我们为什么）

”先给我看一下是什么东西，我先了解一下“，

”你为什么要录入这些手术信息“，（第1次用户需求挖掘）

”因为计算工作量，每个医生填数据上报给主任，主任统一交给质控科“，

”你是根据什么来录入“，（第2次用户需求挖掘）

”手术室手术登记簿会给一张”术后登记簿“根据这个来填“，

。。。。。。

为了更好的理解，我画了一张图放到下面，从下图我们可以看出，最终的需求是指向” 手术术后登记簿“，如果我们能够将” 手术术后登记簿“电子化，就可以同时解决手术室、质控科、临床科室的问题，可谓一箭三雕，这是我以业以来解决问题最痛快的一次。分别与手术室、质控科沟通，叫他们需求提出来。我记得手术室护士长很开心，首先这个问题根本 不是她提出来，我是通过需求挖掘挖出来的，你要是” 手术术后登记簿“电脑登记就好。软件功能不算复杂，经过3个星期开发完成。

需求层次 术后登记

第二个例子，韩春春在群里面向我提出的一个问题：比如收费员发票都日结了，病人过一个月要求作废重新结算，怎么处理。我当时给他的回复先做需求挖掘，再挑选在哪一个层次解决问题，一、二句说不清楚，待写篇文章进行详细探讨，请看以下我的分析过程：

1、为什么不能退费，因为日结了

2、为什么要日结，因为财务科要求，减少账本错误，要求每日核对收费情况。

3、为什么财务科要求，因为财务科说我的账本不能出错，哪怕一分钱也不能出错

    我稍总结一下，”收费员发票都日结了，病人过一个月要求作废重新结算“，背后的实际需求是要如何保证财务账本的准确性和完整性。为什么日结之前，你就允许退费，这个时候就不影响了，日结以后就不行。我们再将问题进一步抽象一下，财务账本的准确性和完整性，相对于一段时间之内说的，可以是一日，也可以是一个月，也可以是一年，分别对应日报，月报，年报。我们再拉回到”病人过一个月要求作废重新结算“的问题，假设上个月收到费用是100元，上个月已经产生了100元，如果下个月退费-100，会不会影响上个月100元，肯定不会的，如果站在1个月时间角度看问题肯定有问题，100元无形消失了，因为下个月在系统生成一张负单-100。站在2个月时间角度来统计，100-100 = 0，这个100元是本来不存在，也就是合计为0，财务账本的准确性和完整性没有问题。比较通俗的理解，上个月100元，下个月-100，本质上就是没有收到钱。如果理解上面意思，收费程序只需要支持退费记录负单功能，然后与原来的正常发票做一个做对应关联对应即可。

第三个例子：我以为信息科工程师为例，做一次需求挖掘。

1、你为什么买2B铅笔?

2、我要去软考考试。

3、你为什么要去软考

4、为了搞职称

5、你为什么要搞职称

6、为什么升职加薪

7、美好生活，实现人生意义

需求层次

接下来我对从“职称”层次开始进行分析 ，仅一家之言：

”职称“层次：要获得职称软考是唯一途径吗？我听说如果有硕士，可以直接聘中级，有博士直接聘高级。

”升职加薪“层次：职称是唯一的途径吗？如果改成每个开发多少个软件，按贡献来计算，也可以，我印象好像武汉市中心医院，有这种制度。当然软考是最保险一个方法。

”美好生活，实现人生意义“层次：”升职加薪“是唯一的途径吗？当然不是，你可以跳出”医院“，去思考怎么样为HIT行业做贡献，比如你做了一款开源软件能降低HIT行业的成本。

你在哪个层次上思考解决自己的问题，就决定我们怎样行动，一般来说层次越深，要实现越难。

  我们遇到一个问题，一定要多问为什么，有什么作用，多进行需求挖掘！有时候，你会发现，提供这个需求的人，未必是最终需求者，你费了好大的力气做完，结果他会告诉某某院领导觉得这个没有满足要求，要求重做，原来他只是一传声筒，不是最终需求者。

第三个方法：从理想到现实

    我知道有个专业叫做”医学信息专业“，我是典型计算机的科班出身，对于一些医疗业务实在不了解，怎么办？然后业务科室的人过来跟你提出一个需求，他也说不清楚 ，以至于两个人，互相看了对方一小时，聊了一小时，最后互相瞅了对方一眼，对方问你这个问题能不能解决，你回答，我还没有懂你的业务需求，瞬间明白了什么是尴尬。

      从理想到现实是什么意思，这个类似我学习数学，数学讨论问题先把你带到理想情况，再逐步现实化，也就是说先把一个问题的情境推至一个理想的情境，然后再从一个理想的情境，逐步回归到现实，我这样说有点抽象，接下看我举例说明。

举例说明：以全部医技申请单统一预约为例，我先假设现在市面上没有相关的案例供你参考，你也不是这个行业的老司机，你脑子里面只有一个简单的概念”预约“。为了更好说明问题，我将模拟你和相关科室人员对话。

开发者(我)：主任，我看这样吧，我们先把医院想像成一个”宇宙医院“，也就是不管来多少申请单，我们都能预约成功。

A主任：那肯定不行，我们的医院资源是有限的。还有很多种情况要考虑。

开发者：对，我们的医院的资源是有限的。我这里只是一个假设我们是”宇宙医院“，也就是不管来多少申请单，我们都能预约成功。我们设计一个这样的软件 ，就可以解决你的问题。

A主任：对。

开发者：您刚才也说，我们的医院的资源是有限的。我们再谈谈哪些资源的是有限的。

A主任：医技人员、医疗设备

开发者：医技人员的上班时间也是限的，既然是有限的，软件就要提供一个“限号”的资源。还有医技人员、医疗设备信息，我们软件会提供一个维护这些信息功能，医技人员额外提供一个排班功能。

开发者：还有谁发起预约了，医生、护士、其他；

A主任：只允许医生。

。。。。。。

开发者：如果一个医生开了多个申请单，会不会有影响

A主任：互斥很多，比如有些胃肠镜和b超，需要隔48小时。打了气不能做b超

。。。。。。

    我相信经过一轮谈话，基本上你已了解业务需求，接下来，是不是可以开发了，按照经验现在还不行。你要学会让“子弹飞一会儿”，你先需求整理，让A主任回去再想，因为A主任潜意识中会带着这个问题过1、2天再会打电话给你，我昨天忘了跟你说这个问题，那个问题。你再整理，你再问他还有没有其他问题，如果没有了，你就可以进行开发了。

第四个方法：借助白板来辅助分析需求

      我们的脑子特别适合单任务、单进程的事情，换一个专业的词”保持专注“，也就是我们同一时间干4、5件事情要比你同一时间只干一件事情，效果会差很多，原因你的大脑负担很重容易疲劳。我们在进行需求分析的时候，其实这一个脑力活，要探讨各种情况 ，还要把整个事件的来龙去脉搞分析的很清楚，如果我们脑子负担过重的活，势必会影响到大家做好需求分析。

    那什么是白板不是word、excel，如果使用word、excel会在脑子潜意识带有约束，让你的大脑不能充分放松。一线大公司的通用做法，借助白板来辅助分析需求，如果身边没有白板，可以拿一张A4纸代替，我经常这么干。

举例说明 ：我再以全部医技申请单统一预约的来说，当你们交流一段时间，你要把聊天的内容，简要的记在白板上，相当于“存盘”，减少脑子心智负担。

HIT软件开发实践（一）

    在交流过程中，注意一个技巧，反复和对方确认是否处于同一个认知频道，隔一段时间做小结，比如，主任，我们刚才谈得是几下几点，一、二、三？他回答是，你再继续下去，这样才是真正有效的沟通。

除了上面的四个方法以外，最后还想与你探讨3个问题。

  第1个问题，数据上报，有哪些数据需要报告上级部门，这个问题容易被忽视，现在数据上报越来越来严格，这需要软件设计之初就要考虑这些问题，以便日后可以提取数据。比如保存诊断时强制使用icd编码、性别字典、药品字典按标准对应等等。

  第2个问题，业务提出的需求，一定要用户需要签字吗？原则上面是需要走流程签字，但是解签名背后是信任，如果一个足够信任的人是可以免签的。如果任何一个小问题，任何一个需求都是走流程签字的话，组织的工作效率将大大降低，你引以为傲管理制度，慢慢形成“制度僵化”，缺乏活力，在未来失去竞争力。我想你一定知道微信红包的故事，几初几个年轻人问客户你微信最希望有什么功能，就是能发红包，他们没有汇报，就直接做了，再发给主管领导，觉得挺好，最后变成微信最重要的功能之一。如果他们当时需要走流程，打申请，去认证一番“红包”必要性，估计“红包”这事就黄了。

第3个问题：我们不要期望把需求一次性全部了解到位，要在上线过程中再去迭代。互联网有句名言，好产品都是迭代出来的，也就是我们不需要一定要把需求全部搞清楚，才开始开发，一个产品需要迭次几次甚至几十次才能真正达到用户要求。

最后小结，之所以花大篇幅叙述”需求分析“，做好”需求分析“往往起到事半功倍的作用，十分重要。