中国首个坚持原创严肃内容的健康医疗信息化新媒体
最新消息:欢迎您,亲爱的读者!您可以通过QQ号或新浪、腾信微博账号直接在评论处登录,发表评论并选择转发到微博、QQ空间。

【任连仲专栏】医疗软件研发宜采用“团队作战”模式

专栏 HIT金子 1882浏览 评论

来源:HIT专家网   作者:任连仲

解放军总医院计算机室原主任 任连仲教授

近年来,不少IT企业主管深感总师级人物难寻;一些CIO总感觉应用软件研发效率不高。为什么?我心怀这样一些问题走访了几家企业和医院。当我把了解到的情况与前述问题联系起来时发现,我们的软件研发组织模式很值得探讨。

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

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

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

ren1

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

我认为,这种方式的天生弊病是:

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

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

  1. 软件设计是有思想的,而思想的传递比起物理东西的传递要难得多,传递过程必然有损失。
  2. 层层分工,一旦成果出了问题,责任很难说清。也就是说,不利于责任落实。
  3. 软件生产不像硬件,不同产品的每层工作量会有很大差别,所以时间计划很难拿得准,这就会导致研发组织的“纵向”出现松紧不均。
  4. 软件产品,特别是管理软件产品是一个系统,而按照《系统工程》理念,系统中的部分和部分之间是有着密切关系的,关联好了会产生1+1>2的效应。而对这些关系,不同的人(或组织),在理解、在认识上会有很大的差别。这种差别,会导致整个系统的质量和效能出现很大的差异。也就是说,这种模式容易使系统的整体性把控遭受影响。
  5. 更为重要的是,软件研发,特别是服务于复杂人群的应用软件的研发,处处层层充满“创造”,按照这种“逐层分工”的方式展开,只有处于上层的产品或系统的“设计者”有创造机会,中下层(也称为软件开发层)完全是照着“要求”实现,根本没有创造机会。

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

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

“团队作战”模式分析

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

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

ren2

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

  1. 能将系统设计的思想一贯到底,不仅不会因传递而损失,而且能够随着认识的提升而不断优化提升;整个团队从始至终在一起,各种思想随时交流,创造能力得以充分发挥,产品质量不仅能够得到保障,还会不断提升,有利于做出“精品”。图示中的“集体审核”环节最能体现“集思广益”。
  2. 这种组织方式最能历练人才,而练出来的都是“全栈式人才”,也就是企业最缺的“能够把握系统整体的总师型人才”。
  3. 成果的评价,荣辱共担,这会大大提升参战人员的责任感。软件研发的管理者都有这样的体会:“满心愿意干的效率倍增,责任心强的质量倍增。”
  4. 产品的现场应用,解决问题快,响应速度快,容易获得更高的满意度。

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

培养“全栈式”人才

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

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

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

【责任编辑:谭啸】

 

您必须 登录 才能发表评论!