医疗软件开发宜采用“团队作战”模式

　　医疗信息系统永远是理念第一、概念第一、整体设计第一，技术实现永远是为实现理念和目标服务的。近年来，不少IT企业主管深感总师级人物难寻;一些CIO总感觉应用软件研发效率不高。为什么?我心怀这样一些问题走访了几家企业和医院。当我把了解到的情况与前述问题联系起来时发现，我们的软件开发组织模式很值得探讨。

　　“按层分工、逐层传递”模式的弊端

　　目前，一些医疗软件企业普遍采用的研发模式是这样的，面对一个新产品或新系统，将整个研发工作分为三个步骤陆续展开，即：第一步是研发主管提出任务和要求，下达给“产品设计部”;第二步是“产品设计部”拿出一套设计方案下达给“软件开发部”;第三步是“软件开发部”依据下达的设计方案做出产品。

　　“产品设计部”的任务是，依据下达的任务要求，先做需求分析和市场动态分析，然后做出业务模型或概念模型，给出一个方案设计、实现要求以及完成的时间，经过“审核”下达给“软件开发部”。整个过程用下图表示：

　　我把这种组织方式称之为“按层分工、逐层传递”模式，它有点像“生产流水线”。这种模式怎么形成的?是自己创造的，还是从西方学来的?我们不去追究。

　　我认为，这种方式的天生弊病是：

　　处于下层的“软件开发”人员对上层传递下来的设计要求有个理解的过程。理解能力强的、理解快的用时较少，理解能力一般的耗时就会较长。

　　理解和沟通占用时间，因人而异、因任务而异，一般来说，约占开发时间的1/3~1/2。就是说，“沟通成本”相当可观。交付使用之后，如果用户发现问题或提出新的需求，系统需要修改时也还得经历同样的过程，给用户的响应必然很慢。

　　软件设计是有思想的，而思想的传递比起物理东西的传递要难得多，传递过程必然有损失。

　　层层分工，一旦成果出了问题，责任很难说清。也就是说，不利于责任落实。

　　软件生产不像硬件，不同产品的每层工作量会有很大差别，所以时间计划很难拿得准，这就会导致研发组织的“纵向”出现松紧不均。

　　软件产品，特别是管理软件产品是一个系统，而按照《系统工程》理念，系统中的部分和部分之间是有着密切关系的，关联好了会产生1+1>2的效应。而对这些关系，不同的人(或组织)，在理解、在认识上会有很大的差别。这种差别，会导致整个系统的质量和效能出现很大的差异。也就是说，这种模式容易使系统的整体性把控遭受影响。

　　更为重要的是，软件研发，特别是服务于复杂人群的应用软件的研发，处处层层充满“创造”，按照这种“逐层分工”的方式展开，只有处于上层的产品或系统的“设计者”有创造机会，中下层(也称为软件开发层)完全是照着“要求”实现，根本没有创造机会。

　　只做程序实现的人群，因不真正熟悉业务，不真正理解需求，干起事来，只知当然而不知所以然。也就是说，让这些充满活力、极富创造力的年轻工程师总是处在“必然王国”，这就相当于抑制了年轻人的积极性和创造力。

　　有人对上述组织模式作出解释说：任务越来越繁重，环境越来越复杂，研发工作需要更细的分工，需要“专业化”、乃至更“专业化”。这种说法，有一定道理，对某种特殊软件的生产可能合适，但对管理型软件(比如医院里的各类应用软件)不适合。再从认识论的角度看，也有悖于人的认识能力呈“螺旋式”上升的规律。

　　“团队作战”模式分析

　　不管是企业主管还是研发主管都清楚这一点：做信息系统永远是理念第一、概念第一、整体设计第一，技术实现永远是为实现理念和目标服务的。当前最短缺的是既熟悉业务、又技术深湛、能够掌控系统设计整体、具有“全栈”组织指挥能力的人才，只有培育出众多的这类人才，信息系统设计的效率和质量才能得以大幅提升。为培育出更多的这方面人才，我们应该赋予年轻人以更繁重的任务，让其在更复杂的环境中历练，让他们都在“自由王国”里摸爬滚打，给他们更多的历练机会，培育出更多的“全栈式”人才。据我理解，多数年轻人的价值取向是追求个人价值的最大化，我们应该为他们创造环境，给他们提供机会。

　　出于这样的目标考虑，并总结以往的和现实的经验教训，我认为，研发软件产品、特别是研发医院应用系统软件，更适合采用“团队作战”模式。这种模式的特点是：按任务(可能是一个大系统中的子系统，可能是一个独立系统)组织团队，采用类似“大包干”的形式，一个小组(也可能是一个人)，对整个产品(或系统)的功能、质量和进度负全责。如下图所示：

　　这种组织方式的优点，除了减少沟通时间、提高整体工作效率之外，最主要的好处是：

　　能将系统设计的思想一贯到底，不仅不会因传递而损失，而且能够随着认识的提升而不断优化提升;整个团队从始至终在一起，各种思想随时交流，创造能力得以充分发挥，产品质量不仅能够得到保障，还会不断提升，有利于做出“精品”。图示中的“集体审核”环节最能体现“集思广益”。

　　这种组织方式最能历练人才，而练出来的都是“全栈式人才”，也就是企业最缺的“能够把握系统整体的总师型人才”。

　　成果的评价，荣辱共担，这会大大提升参战人员的责任感。软件研发的管理者都有这样的体会：“满心愿意干的效率倍增，责任心强的质量倍增。”

　　产品的现场应用，解决问题快，响应速度快，容易获得更高的满意度。

　　这种方式带来的问题在于：整个团队人员都需要扩展认知能力，有的需要扩展需求分析能力和产品设计能力，有的需要扩展程序开发能力，而这些正是大多数年轻人渴望难求的。对于已经开始进入独立工作阶段的年轻人，大多数愿意承担重任。

　　培养“全栈式”人才

　　有人说，这样做有损专业知识的深入。须知，做信息系统，特别是当下，还是这句话：最短缺的是既熟悉业务又熟悉技术的“全栈式”人才，当下最不缺少是“只有技术”的人;做信息系统，需要人人都有“系统工程”理念。这种“团队作战”方式，最适合保证整体设计的完整性，最适合保持理念和概念的一致性，最适合全面体现“系统工程”的理念。

　　有人对整个研发过程还包含着“试用优化”这一环节不甚同意，甚至不愿参加，认为那是现场实施团队的事。研发人员参与这一环节，不仅是研制“精品”需要，对于个人本领的成长也非常重要。大量实践证明，一个产品研发工作者，如果缺少这一过程将不是一个完整的“全栈式”人才。

　　回顾历史，哪一个初创企业不是这样的“团队作战”呢?“军字一号”医院信息系统，高级版仅是一个班的人力，普及版更是只有几条枪，但他们都在较短时间内完成了一套优质信息系统的研发。据说，谷歌公司最初就是如此，SAP公司也是五个人起家。现在，我们的摊子还不是那么大，研发组织工作的面也没有那么宽，软件研发组织工作，应该依据我们自己的实际，在学习西方经验的基础上，创建出适合自己的模式。至少在当前，在医疗IT行业，“团队作战”模式是一种比较适合的模式。