一个有惊无险的医疗卡项目

转 ： http://www.programmer.com.cn/3253/

 

文/董轶

 

在软件项目的整个生命周期中，风险伴随始终。项目经理就像一名船长，在危险的海面上指挥着航船，可能会面临波涛汹涌，可能会跌入急流旋涡，还可能会遇到很多未知危险的困扰，项目经理的职责就是不论遇到什么危险，都要坚守岗位，带领这艘航船（项目）顺利平安地到达目的地，这对项目经理是一个不小的挑战。

项目经理不仅要按部就班地做好项目的日常管理工作，还要时刻睁大眼睛，观察周围的环境，从看似正常的环境中及早洞察到危险的存在，以便提前做出应对措施，变被动为主动。如何识别、控制和管理风险对项目成败至关重要，也是每个项目经理必须面对的考验，下面将结合项目实战中的具体情况，以我负责的某市医疗卡应用系统（简称卡应用系统）建设项目为背景，从软件项目风险管理的角度谈一些个人的思考和体会，希望对大家有所借鉴。

该项目由市卡管理和运营中心（简称卡中心）发起，由其它政府部门如劳社局、卫生局、民政局等应用单位提出需求，参与共建与管理。卡应用系统在建设初期主要面向市民在全市范围内提供医疗保险服务，实现持卡就医，在此基础之上逐步提供多项方便快捷的公共服务和商业便民服务。该项目的用户群庞大、社会影响较大，某些业务流程和业务规则未定，需求变化频繁，不易掌控，牵涉多个政府部门、开发商的利益，系统的内、外部接口很多，合作方较多，项目充满了复杂的未知、不确定因素，在技术、需求、工程组织管理方面有很多风险，需要有很强的风险意识和风险控制能力。

 

开发刚完成，需求大变更

在公司的支持下，我从其它两个部门抽调了技术骨干，组建起了由精兵强将组成的项目开发团队，制订了项目总体计划，并严格执行公司的项目管理规范，一切都已经步入正轨。在架构师的带领下，经过紧张的工作，团队如期完成了需求分析和系统设计，并得到卡中心和卫生局的认可，顺利进入到系统开发阶段。然而在我们开发基本完成的时候，卫生局突然提出需求的重大变更，即允许患者不用提供有效证件也可以办卡，这与目前的业务规则是完全对立的，必将导致系统设计遵循的基本原则的重大变更。

出现这样的需求变更是在我的意料之中的，我曾经负责和参与过很多大型软件项目的实施，没有需求变更的软件项目是基本不存在的，而这个项目涉及政府部门的业务，该业务如何开展仍在探索阶段，有不少未定因素。因此我在项目的策划阶段，就根据软件项目这种特征和实际情况选择了合适的项目生命周期模型——迭代模型。首先根据初期了解的需求开发第一个软件版本，对于客户方提出的需求变更在第二次迭代中实现，该版本软件在上线试用一段时间后，根据各方的反馈意见，还会进行第三次迭代开发。这三次迭代开发的成本是在项目计划内考虑到的，这样在遇到需求变更时就会比较从容。

 

 

公众利益和业务目标，孰轻孰重

我组织项目团队对需求变更进行了充分的讨论，在会议上，架构师提出一个关键的问题：医疗卡相当于患者在医院就医的身份证明，在整个就医过程中都需要使用，目前还不能通过其他渠道发卡，如果患者不能在就诊前实名办卡，后续业务的处理将出现“病案信息无法统一”的问题，而通过实名制实现病案统一是我们原定的业务目标之一。是否实施变更在团队内部也引起了激烈的争议。

架构师的意见是有道理的，实现卫生医疗领域梦寐以求的“病案信息统一”是系统原定的业务目标之一，而客户方的变更则更多地考虑到患者就医是否方便，对于患者这样一个特殊群体，不能不考虑其心理承受能力，我想这也是客户方提出这个变更的充分理由所在。两种意见都有硬道理，那么就要权衡哪个优先级更高。决策权在于客户方，我们需要做的是提交一份报告，针对两种业务规则分别简述我们的解决方案，比较两种方案的优缺点，并深入分析变更后的方案对实现客户方业务目标的影响。这样做的目的不仅是为客户方的最终决策提供充分的信息，更重要的是把变更可能会带来的原定业务目标受损这个风险提前摆到桌面上，让客户方充分意识到这一点，保证客户方是在充分考虑到变更带来的影响的前提下做出决策。客户方经过慎重考虑和多方论证，最终仍然确定进行变更，我向客户方表示项目团队会通过优化设计方案使变更对原定业务目标的影响降到最低，即最大限度地保证原定业务目标的实现。

 

不变的只有变化

我们按照计划开始做第二个版本的需求分析工作，然而这时又遇到了一个更棘手的问题：卡中心接到上级主管单位的指示，要求卡系统提供“断网模式下的分布式解决方案”，即网络断了，卡服务不能受任何影响。目前卡系统是采用“联网模式下的集中式解决方案”，这是一个重大的设计变更。

架构师对此提出了几点意见：第一，由于卡服务要在全市范围内提供，只有集中式解决方案才能实现持卡人任何时间在任何一家医院都能够享有相同的卡服务，这是我们需要实现的业务目标。断网情况下，持卡人的卡服务信息在不同医院之间不能互通，持卡人在一定时间内只能在一家医院享有卡服务，在其它医院的某些卡服务会受到一定程度的限制。第二，卡服务一次业务操作所传输的数据是有限的字节数，对于网络的压力较小，目前各家医院的网络现状能够满足卡服务系统的要求。第三，断网服务比联网服务实现的复杂度要高很多，因为卡服务请求实际发生的时间与传到中心处理的时间不同，需要中心的处理程序考虑到各种不一致的情况，业务逻辑非常复杂，而且断网会造成某些业务很难处理。

架构师非常有经验，一下子就抓住了问题的关键，分析得也很有道理，但是主管单位已经做出了决定，我内心也在考虑是否还有一线希望说服主管单位不做变更。这件事的关键点是提出断网方案的主管单位同时是网络维护和运营的主管方，而使用卡服务的患者又是一个特殊的心理承受能力较低的人群，主管单位不能不考虑一旦由于网络故障而发生卡服务中断，将会带来什么负面影响，这是天平的一端。与此相比，天平的另一端是什么？架构师提出的部分卡服务业务受到限制，这种情况发生的概率、影响面相对较小；网络压力小也不是不进行变更的充分理由；主管单位是要避免一切风险的发生，虽然这个风险的可能性不是很高，但是这个风险的严重程度很高，关系到国计民生的项目社会影响力大，不能不慎重，必须做到万无一失。

 

失之东隅，收之桑榆

在权衡了天平两边的分量后，就知道如何去做了，于是进一步思考又发现其实多一套断网解决方案，也是给项目多上了个保险。万一中心服务器不能正常处理业务请求，可以启动断网方案以解燃眉之急。要知道即使经过严格测试的系统，上线后也可能发生意外情况，因为真实系统的运行环境非常复杂，与其它公司的应用接口又很多，不能不考虑网络、路由器、防火墙、交换机和存储设备的异常，这些又都不在我们的控制范围内，系统不能正常处理业务的原因也许是由于外围设备以及其他公司的应用系统（与我们有接口）的异常和故障造成的。我已经习惯了悲观式的思考方式，经常问自己如果最不愿意发生的事情发生了，如何应对？在安全的时候就考虑好应急措施，因为一旦事情发生，项目经理的大部分时间将用于沟通和协调，主管单位、公司领导、客户、医院和实施人员的电话都会涌进来，项目经理根本没有时间冷静思考如何解决问题，因此一定要防患于未然。这样，权衡了天平两边的轻重，理清了利害关系，也看到了有利方面，我的思路清晰了，于是我心平气和、有理有据地说服架构师和项目团队，我们可以在第二次迭代中实现这个设计的变更。

 

系统的神经网络

在设计方案完成后，我按计划召开了设计评审会议。评审制度是非常好的避免风险的手段，俗话说：“三个臭皮匠顶个诸葛亮”，做项目要通过流程、制度保证我们的软件成果体现出组织的智慧和能力。

针对断网模式下的分布式架构，设计组做了这样的方案：在每家医院部署代理服务器，断网情况下的卡服务数据暂存于此，网络连通后按照预定的传输策略把卡服务数据自动上传到中心服务器。我对系统全面铺开后的维护工作量及成本投入比较关心，因此在听取了设计的详细讲解后，我提出了几点注意事项：

1. 部署在各个医院的上传程序能在多长时间内保证稳定运行？

2. 如果上传程序发生故障关闭，是否有措施在不惊扰用户的情况下及时发现并解决问题？

3. 中心管理人员是否能方便快捷地掌握每家医院上传程序的运行情况？

这个项目目前虽然是试点阶段，但是我们的系统设计指标要按照大规模发卡的要求来设计，推广后系统将部署到地理位置分散的各级医院，且数量会很大，从初期的几十家到成百上千家，部署在医院端的程序必须足够健壮、稳定，否则会给系统维护工作带来很大的困难。例如假定我们在1000家医院推广，上传程序一个月失效一次，一年下来我们就要现场维护12000次。

设计人员根据我的意见完善了系统功能，增加了远程监控和维护、上传程序自我诊断、自我恢复等功能，这些功能如同给系统建立了发达的神经网络，一切动态尽在中心掌控之下，从而大大减少了系统上线后的运维工作，显著降低了项目的运营服务费用。

 

总结

以上内容从风险管理的角度，谈了一些个人的思考和体会，下面将根据管理实践总结出一些指导性原则与大家分享。

软件项目的需求在调研阶段很难确定，需求随着项目的进展逐渐明确，但是还可能不断演化、扩展甚至推翻，这种现象在国内软件行业尤其突出，因此软件项目的风险很大一部分来自于需求，把这个问题解决好了，项目的半壁江山就算打下了。项目经理可以采用增量模型、迭代模型组织项目，这需要项目经理有丰富的项目管理经验，把握好迭代的次数和迭代任务的规划。另外，在需求变化不定的过程中，要关注需求变更是否偏离和影响了原定业务目标的实现，在此问题上要与客户方达成共识，避免发生不能满足客户需求的后果。

项目经理在遇到困难时要有乐观精神以鼓舞团队士气，但是在面对项目所处的复杂莫测的大环境时，要习惯于采用悲观的思考方式。有些风险是可以识别和控制的，还有些风险是较难预测的，项目经理就像在悬崖边上，要多给自己准备几根救命的绳子，在系统上线前要考虑紧急情况下的处理措施，必要时制定完备、有效和切实可行的应急方案。

对于大型软件项目，尤其是实施地点分散、客户端数量庞大的情况，要给予足够重视，这本身就是一个不可忽视的风险，在设计方案中一定要考虑到实施维护的可行性、方便性，否则会增加项目维护成本，降低客户满意度。

项目管理的基本要求是管理项目的质量、进度和费用，而项目管理的更高境界应是使利益相关者都满意。每一个项目的实施，都需要多方面的组织和个人参与，例如项目投资方、承包商、客户、供应商、项目经理、具体工作人员等，还可能会涉及当地政府和公众等，他们在项目中都有切身利益。我们在分析项目风险时不妨以利益为导向，在项目的不同阶段，检查一下，对于所有的利益相关者，他们的利益是否会因为项目的进展而受到威胁，这种威胁往往是项目风险的来源，也是项目经理必须面对和解决的。当各方的利益与项目的利益发生冲突时，项目经理应努力使各方利益保持平衡，并分别给予各方一定程度的满足。本项目中的两次变更正是为了满足患者群体、客户方主管单位的利益。这些利益从微观看是与项目的商业利益相矛盾的，但是从项目应承担的社会责任的宏观层面看，实际上是统一的。只有这样才能为项目铺平道路，减少阻力，否则项目实施起来会困难重重，项目成功的重要标志就是使利益相关者都满意，希望项目经理带领项目团队为项目的成功不懈努力和奋斗，同时也要表现出高度的社会责任感，为社会做出应有的贡献。

 

作者简介：

董轶，IPMP B级国际高级项目经理，IBM 360°精英讲师团成员，自1996年起从事软件开发，曾任软件架构师、售前咨询顾问、项目经理、项目总负责人，具有多年大型复杂项目的管理经验。

 

（本文来自《程序员》杂志10年05期）