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

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

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

改还是不改？

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

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

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

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

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

怎么改？

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

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

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

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

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

多久改好？

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

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

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