为什么说医院信息系统的需求修改必须要谨慎

2019-02-27 11:24:37 爱德腕带 阅读

QQ截图20190227112040.png

之前网上流传着两个段子:其一是“kill一个程序员不用枪,改三次需求就可以了”;其二是“某产品经理让程序员改需求,结果被对方暴打一顿”。偶尔和厂商的开发人员聊天,他们说最怕的就是改需求,简直让人抓狂。

医院信息科又何尝不是呢?各种需求源源不断,应接不暇。如果是自行开发,开发人员天天被领导催;如果是依靠厂商,那么信息科天天被提出需求的科室催。不管是调侃还是现状,细细琢磨之下,总觉得可以说道说道。

“改需求”,三个简单的汉字,实则重于千斤。尽管这里面是一个环环相扣的过程链,但是皆围绕核心问题:改还是不改?怎么改?多久改好?这些如果掰扯起来,甲方和乙方、信息科和提出科室之间可以讨论甚至激烈争论上三天三夜,各说各的理,互不相让。张艺谋的电影《有话好好说》,马歇尔·卢森堡的《非暴力沟通》都教导我们,吵架无助于任何问题的解决,还是像刑侦人员那样抽丝剥茧吧。

改还是不改?

提出需求分为口述和正式提交两种。口述,还是算了,事后不认账那找谁去,信息科可不愿意做“背锅侠”。保险一点,还是正式提交吧,甭管是纸质还是在线,记得请领导签字(审核)啊。

这样是不是就OK啦?NO、NO、NO!先搜索一下该科室之前曾经提交的需求(这里再次强调信息科的信息化是多么重要),时间久了难免记不清,别做重复劳动。如果是全新的需求,那也要先把需求修改依据搞清楚,是什么部委办局的什么文件中的什么条款对信息提出的什么要求,空口无凭得悠着点儿。

文件清楚了,总得进行需求分析吧,别弄个需求把系统搞崩了、扯慢了,那信息科扛不住。

需求分析通过后,那就按重要性排个轻重缓急吧,毕竟人手、精力就这么多。是领导层直接下达的?没问题,加急优先处理。

这套流程走下来,基本可以确认需求了。

怎么改?

在信息科的日常工作中,花费口舌最多的工作是“怎么改需求”。几乎每个人都有自己的独特想法,到底以谁为准?令人犯了难。

涉及人数太多?没关系,医疗、护理这类大户直接将意见归口到医务处、护理部。

修改效果如何判定?把标准拿来,国际标准、国内标准、行业标准、院内标准都可以,关键是少说一点“我想怎么怎么着”。铁打的营盘流水的兵,科室人员、领导都有可能更换,如果以个人的喜好作为判定依据,难免被“推倒重来”,还是遵循标准比较靠谱。

想变更效果?麻烦在变更确认单上签字,如果修改已经接近尾声,恕无法执行。

嫌界面难看?咱改需求主要是实现业务功能的,至于按钮放左放右、用下拉还是点选这类想法,在不影响使用方便度的前提下还是退回吧。

多久改好?

需求到了信息科没有说不急的,都巴望着今天递交了明天就改好。都认为简单,不就是增加一个小功能嘛,花不了多少功夫。心情能够理解,可是对于程序员来说哪有那么简单哦。写代码、程序测试、试上线,一个节点都不能少。

其实这和烹饪是一个道理,蒸馒头之前还得和面、发面呢;煮饭中途不能开锅,要不夹生咯;番茄炒鸡蛋是快,不过也有胡萝卜炖羊肉这样的功夫菜。久经阵仗的程序员会告诉你预计耗时多久,前提是中途没有需求变更。这就像你要一盘宫保鸡丁,半路和厨师说把花生米换成杏仁,再后来又说别放辣,这不是玩儿呢吗?

需求有风险,提出需谨慎!需求!需求!这是一声叹息,是无奈,是呐喊,更是坚忍。为了信息科各位同仁的小心脏,为了他们脑袋上的发量,请大家把需求想清楚了再提,挨个儿提,有理有据地提。也请大家对信息科多一点理解与支持!


点击这里给我发消息
点击这里给我发消息