前言
从2009年开始，国内开展了热热闹闹的医疗改革，本人有幸做了一回排头浪，参与了某市基础医疗卫生服务信息系统的建设。该项目历时三年方结，虽已过八年之久，但屡屡想起，颇多感触。故留言于此，算是个念想。
于今回顾，昔年之项目，破绽多多，吾亦将时时补充。完结之日，标题中断无待续二字。
背景
医改开始的时候，无论是从卫生部还是到各区市卫生局都不是十分清楚，而做这种项目，更多是政绩的角度出发的。而基础医疗卫生服务信息系统也大多是目的不明，如何建设，怎样建设，建设成什么样子都是个疑问，就在大家都打破脑袋要想出个所以然的时候，电子政务系统成了被模仿的对象。
现在看来这就像是个笑话，而当时，我就是这个笑话的一个组成部分。
合同
最初的售前服务，笔者当时作为刚毕业的Fresh Man是不知情的，某一天，PM拿来了一个演示系统，那是某市区的基础医疗卫生服务系统（据说在非典其间发挥了巨大的作用），目的是分析实施和部署的成本。于是大体上在本地环境中配布了一下，基本算是能够正常运行，发现功能大而且全（听说开发单位耗时3个月，人数不详），操作了几次后发现，就是个流水账，联想到医院里面的情况，觉得意义不大。于是三天后，汇报了调查结果。
此后无下文，本以为功德圆满了，忽一日，被问及山寨此物需要几多资源，楞！。
于是，
本着初生牛犊不怕虎的虎逼精神，
本着一穷二白的脑细胞煞有介事的规划了一下午，报给了PM。
几天后，PM发声“合同拿下了，构筑开发环境”
就这样，稀里糊涂的开工了
调研
调查活动持续了很长的时间，大概是3，4个月左右。
第一个星期，全体开发人员都被放到了客户的服务中心（20个左右）里面，一群愣头青在客户现场观摩，问得问题和记录的内容零散，也没有统一的标准格式，更没有确认签字。周末加班汇总的时候才发现，业务都在每一个调研人员的脑海里。
麻烦的事情出现了，客户端需求和那个高大上的系统出入很大，因为侧重点不同。照搬肯定不行。
赶紧报给PM，才发现更大的麻烦出现了
需求还得整理啊，不能停下来
于是，在PM若有若无的几个月里，完成了调研工作，汇集资料摆在了更上两级的领导的办公桌上。
该领导一问三不知，于是找来了该项目的客户方负责人（笔者当时已经窃喜了，以为如此一来可以开展大忽悠运动了），这位负责人我是第一次看到，也正是这一次，知道了PM失联的原因是
辞职了。。。
该负责人业务、系统双精通，并且早已知道我们山寨的系统无法满足他们的建设需要（干嘛不早说）
此时已经过了2个月，客户方似乎也知道前期沟通的不畅是两方面的原因，于是又开展了为期三个月的二次调查。
这一次，我看到了合同，没有具体的功能，仅仅是一个说明不充分的系统说明，比如说至今都记忆犹新的挂号功能，“为客户提供快速的挂号功能，满足客户的需求“。
什么叫快速的挂号功能，什么叫客户需求，如何满足。概无说明。
不能指望改合同了，
硬着头皮上吧
中间有个小插曲，本人此时荣升PM，
当然，这是因为山中无老虎。。。。。。
硬着头皮上吧
开发
按照瀑布模型的标准流程，在一群愣头青的陪伴下开始了分析，设计，开发，测试，部署工作.
这中间经历了许多的困难，也都一个一个的解决了。
分析：没什么可分析的，科室都是现成的，调查也是我们自己做的，脑子里不知道分析过多少次了。
设计：对于架构的设计，功能的划分。其实不用划分功能，人家有现成的科室，我们就按照科室进行划分，主要还是考虑到架构。简单的套用了SH（Struts1.2+hibernate）框架，之所以这么做是因为对Spring不了解，没敢用。
开发：如今回忆起来，开发阶段的管理一塌糊涂。完全凭着本能进行管理，没有任何的方式方法。一个人一个科室，与关联科室协商好接口协议就OK了，那个时候还有一个好习惯，做备忘录。后来演变成了内部操作手册，相当于API文档。至于source管理，负责任的说，没有！
测试：刚开始的时候测试基本是单体手动测试，没有JUnit。这为后来的万年坑打下了坚实的基础
.
部署：尽管初生牛犊不怕虎，可终究还是有思想的。部署划分为本地测试环境、客户验收测试环境和生产环境.本地结合测试出现了许多问题，排除BUG的速度还是很快的，但是测试依然不完善，没有报告，没有标准。
尽管如此的跌跌撞撞，系统上线运行了。我们敢写，客户敢用。好，谢谢客户，谢谢上苍
。
验收
这个环节我没参与，不知道详情。见谅
过失大于贡献，今日今时想来，只此一句。
择日会就此三年中的事情做总结，望期待
