医疗卫生行业中的领域模型

不久前写过一篇关于医疗信息化领域的软件工程的文章，现在回去看，发现确实有点题目太大、内容太少的味道，用现在一个流行词汇，叫做标题党。其实写博客我一向不太重视标题，也常常文不对题，因为主要还是写给未来的自己看的，同时也顺带跟志同道合者交流交流，没必要在内容和形式上推敲这么多。原本这一篇的出发点想以领域模型为主的，但是内容可能比较杂，当作上篇软件工程的续集也是可以的。

几个月前参加了CSDN组织的一个活动，活动的主题是架构设计。课上主办方利用新浪微博让听众和演讲者进行互动，很有意思，但对于包括我在内的大多数与会者来说，大部分的时间还是竖起耳朵在听。其间引发了一个关于领域知识在架构设计中究竟占多大比重的讨论，看得出几位演讲嘉宾（包括听众在内）在这个问题上的看法并不完全一致，却都采用了非常官方的姿态把分歧屏蔽掉了。其中一位嘉宾提到，领域知识确实很重要，但是如何把它整理和表达出来，往往是十分困难的事情。

确实，任何东西在没有表达出来之前，在工程上都是没有实用价值的。你可以写出很好的需求，做出很好的设计，因为你深入理解了你的产品所服务的领域，并利用了这些领域知识来质问、衡量，并最终改进你的方案。但这些领域知识在哪里？没有文档，你就是拍脑袋。只要是拍脑袋，就经不起工程的推敲。好吧，领导发话了，现在进度这么紧，推敲这么多干嘛？确实也是，工程核心就是权衡，权衡下来还是进度要紧，那就开始做吧。没过多久，系统越做越大，这么多需求你实在分析不过来了，很多重要模块也要交给其他人设计，但他们可能刚入行没几年，也可能在互联网或者金融领域做了很久，但对医疗还陌生，你放心吗？你做好了频繁召开评审会议的准备了吗？当你多次评审之后才发现，你在会议上花掉的时间，某些规格说明书和某些设计方案早就可以做出来了，何必需要他们呢？等你慢慢把他们培养起来，哪天人手不够了，需要补充新人，你又要重复这个过程吗？经历过这些磨难之后，你最初承诺的进度得到兑现了吗？

其实在软件工程界不断翻新的时尚潮流中，对领域知识的关注始终处在一个边缘化的位置。其中缘由也是不难理解的。至今为止，软件工程界的主流方法和工具，主要还是几个大厂商推动的，特别是IBM和微软。从无所不包的RUP，到近年火热的敏捷，说白了还是换汤不换药；从COM时代的面向组件到，.Net时代的面向服务，有时候似乎只是用不同的方法把同样的问题重新解决了一遍。他们在这些方面不断地推陈出新，吸引大家的眼球，也许是因为他们只擅长这个，而且他们确实不了解领域。关于这一点，近年来这些公司在医疗行业的艰难处境可以作证；如果你说这可能只是他们商业上运作得不好的话，看看技术上的DSL吧，确实是很有前景也很有难度的一个方向，微软搞了好几年，现在也没怎么提了。

经历过几年前对RUP的热衷，到如今对敏捷的追捧，又让我想起《敏捷迭代开发：管理者指南》书中观点：其实所有软件过程几乎都可以从RUP里面派生出来，不管是多么瀑布还是多么敏捷。记得以前有人曾经被问到：你们项目用的是什么过程方法。我当时告诉他说，不管是什么，你都说是RUP，肯定没错的。其实我要说的是，在真实世界中，就算行业或者组织提供某些统一的指南，但每个项目采用的具体方法都必须是独一无二的。软件项目的差异来源于人的差异，这也意味着项目的控制者应该根据这些差异来选择甚至探索（比如个人喜欢通过一些自适应的方式）最适合的方法。当然，自适应的方式往往需要好的团队决策模式相配合。温博格曾对好几种团队决策模式及其适用的团队特点进行过分析，今天的主题不是管理，所以就不再展开了。

不过关于决策机制，特别有意思的一点是，决策的最佳产生机制未必跟组织结构是一致的。领导要做最终拍板，这是没错的。但如果一群人意见不一的时候，到底该听谁的，才能取得最好的结果，并且保持风险可控？大多数老板都会选择沉默，并仔细分析，最后再表达意见。有些老板也会跟大家一样积极表达意见，并做好了在意见受挫时表扬下属的心理准备；或是没有这个准备，最后只能为了维护自己的权威武断拍板。到底采取哪种方式，才能在团队中产生出最优的决策呢？