您现在的位置： 
最近，记者正面接触到年内所发生的两个不甚成功的案例。案例真实地呈现了ISV在项目管理过程中是如何陷入窘境的。对此感兴趣的读者，也许愿意跟记者一起体验ISV 创业及从业的困难与失误。
案例一：乙方的无奈
3月的某天，华怡合信（北京）科技公司技术总监兼项目经理周利斌总算是松了口气。这次由他经手的软件项目作为公司的第一个开发项目终于有了一点眉目。
华怡合信是一家专注于医疗卫生领域的ISV。“正在做的是深圳某综合医院的一个项目，是做临床移动信息系统。我们就是围绕二维条码技术、无线网络技术和计算机技术，专门为医院解决临床护理方面的业务应用，通过系统自动实现‘三查七对’，有效减少医疗差错的发生，提高医疗质量。”周利斌介绍说。
其实，自2007年4月华怡合信着手这个项目以来，该工程到现在还没有真正完成。而时间已过去了一年多，项目负责人周利斌还没等到客户验收签字的那一刻。
看不到头的30万
华怡合信公司成立不到两年。从一开始起，从事软件技术开发工作多年的周利斌和从事医疗行业多年的杨楚威达成了共识，他们非常看好临床信息移动建设。于是。两人开始着手成立以提升医院医疗质量和管理水平为核心业务的新公司华怡合信。目前，公司拥有多名技术开发工程师及实施工程师。
“我们前期花了近五个月对这个领域的相关业务进行了调研。调研完成之后形成业务流，业务流就是我们软件所实现的功能，整个需求确认以后，再针对这个业务的共性来形成产品内核，以围绕产品开发的思路开发产品；其中，在产品开发的基础上既考虑了用户实际使用习惯的偏好，同时也为后期公司的产品线开发奠定了基础。”周利斌在介绍公司的项目成因时说。
周利斌所说的对国内二十几家三级甲等医院所做的调研，实际上是与接手这家深圳某综合医院的“临床移动信息系统”的项目是同时进行的。
作为甲方的深圳某综合医院，倡导以病人为服务中心提高医疗治疗质量的管理理念。为了解决住院期间药品发放、临床护理过程化等问题，客户投入了资金总额为300万元作移动临床信息化建设。该项目包括无线网络、打印机及一些移动设备如PDA等硬件设施，其次就是软件系统开发，这部分的投入约为30万元。软件开发委托给华怡合信。华怡合信基于该院HIS系统作软件应用开发，软件应用功能通过移动PDA实现患者床旁治疗。
由于医院信息化部门的负责人是做技术出身的，有着很强烈的医疗信息化的建设意识，这使院方与华怡合信的核心理念不谋而合。
但即便如此，项目进程的拖延出乎华怡合信的意料。“我们原定计划是三个月内完成，但拖到现就等于没有赚钱。”周利斌无奈地说。他表示，造成华怡合信这个案子不赚钱的原因主要有两个：一是项目在外地，二是用户需求的不确定性和基础建设缓慢。
不过，华怡合信原本在接手这个项目时还是做了足够的心理准备。“在对整个医疗行业相关的需求进行了调研确认之后，我们才开始着手设计产品。虽然项目并不大，但是我的思路是以产品的理念做项目，以产品主导项目，这与一般作办公OA、ERP等公司基本是以项目主导产品的思路不同。新的尝试来做第一单不赚钱也很正常。”
由于出现医疗问题在制度上没有对护士作出明确的惩罚规定，致使医患关系紧张；二是药品的发放问题。医生有可能在开药单上列出很多未发送到患者手中的药品，产生额外费用的问题，也有可能确实开了药但是护士没有及时发放。
针对相关问题，院方有了信息系统开发需求。即为了保证这个过程内药品的监管，医院提出了通过条码实现药品过程化管理。同时也考虑到临床护理的工作，希望能建设移动临床信息系统，结合HIS系统完成“医生—护士—患者”闭合的环；形成医生下达医嘱，护士执行医嘱，医嘱执行完成后能迅速回到医生处这一严密的规范管理链条。
由于这套系统设计和业务需要，系统的运行需要有无线网络传输平台去支持，所以医院开始需搭建相应的无线网络系统。无线网络系统的搭建也是当前医院实现信息化的一个目标。另外，由于采用“临床移动信息系统”在国内算是先例，客户和软件开发商都处于尝试阶段，其间的需求变更必然非常频繁。
对作为乙方的周利斌说，由于此项目有一个优势，那就是信息中心的负责人思维比较活跃，具有信息建设的前瞻性。他看到临床信息系统是下一个医院信息化建设的目标和方向。
ISV第一单的成本
其实，国内新兴软件开发商基本的业务模式多数与华怡合信类似：开始靠客户关系，其次就是确认业务，然后才开始产品开发。即由项目决定公司的行业范围，从第一单开始确认公司的业务方向。
第一个吃螃蟹的人，付出一定代价在所难免。以该项目为例，客户方的需求看似很简单：普遍的住院问题监管制度不严密。一方面是护士的工作强度，护理病人期间发生的问题不仅频繁且难以问责，推进过程中变更不断的原因，但也正因如此才促成该项目得以实施。
作为开发商的华怡合信，项目的软件开发只花了三个月，但实施却花了一年时间。周利斌说，虽然主要由于客户前期花在无线网络建设太长，致使项目完成时间一拖再拖，基本上没有赚钱。
不过，正是有了这实验性的第一单，华怡合信才有了自己的客户资源。这一单为他们接手后面的案子作好了铺垫，公司的业务发展也才终于有了起色。
“现在我们正在北京做几大医院的项目。已经完成了的客户现有三家。我们终于在一年的时间积累了自己的客户源，这说明我们选对了行业，在技术发展方向上是走对了。”周利斌松了口气似地说。赔钱的总结：有效沟通
要对华怡合信的成败作一个定论，现在还为时尚早。我们实际要探讨的是，ISV 在这个真实的案例之中的得失问题。
关于国内ISV就软件项目管理过程中的核心，华怡合信技术总监周利斌对记者一直在强调的是“技术与市场相结合的产品化思路”。有效及时的沟通是项目实施的第一位。
一个项目做得好与坏，不是单纯的项目经理或者项目团队的事情，前期营销过程中的沟通也非常关键。很多时候，技术开发工程师往往会埋怨项目经理所接的案子过于仓促，给他们进行技术开发及实施带来了很大的困扰。
从项目立项开始，ISV就必须花费大量的时间用在与用户沟通上。经过双方多次的探讨与交流，最终形成项目的技术内容。再根据庞杂的内容进行分解，最终让双方都能从实际需求到技术实现之间完整地了解项目。要让参与双方都能对项目内容、建设步骤、建设目标有清晰的认识。
其次，制定具体详细实施计划和方案。同样强调与用户沟通的重要性，即项目实施前需要准备什么，准备到什么程度。
最后，控制项目实施的进度。必须严格控制，不能随意和轻易改变，任何改变都将使项目的周期延长。这将给ISV带来沉重的成本压力。
“最难的也是，实施过程中项目的变更和需求的变更，以及一些不确定因素。当时，深圳这个项目主要因为前期沟通少，导致在用户没有无线网络环境情况下，就去现场实施移动临床系统。”周利斌说。
其实，需求变更是ISV在任何项目中必然要经历的事情。这正是中国软件项目管理中最为突出的一个难题，即无规范化管理及无标准性的开发。
同样的问题在下面一个来自用户端的案例中得以再现了。
案例二：甲方的烦恼
乙方在项目过程中忧虑重重，但甲方也并非高枕无忧。
第二个案例是出自家用电器行业的一个软件项目管理案例。客户A是一家在家用电器零售领域深耕多年之后，拥有丰富的行业资源及经验的实体企业。公司管理层想把这些经验及资源转到互联网上，通过搭建一个IT系统来为客户提供相关行业信息并且实现交易的平台。
从年初项目正式开始到现在，7个月的时间过去了，这个系统还没有正式上线。为此，客户方负责该项目的IT信息主管刘一民，一直在为自己面对ISV的一系列不规范化管理问题而愤愤不平。合同初步敲定年前，辗转间刘一民通过熟人与某国内知名ISV（以下称为B公司）开始接触。这家ISV拥有近8年时间的历史，其业务包括外包服务、软件开发等。并且有很深的政府行业开发背景。
双方谈定，由B承接A公司平台开发的项目，原定项目周期为三个月，第一期投资额为20万元。按照行规双方就付款商定，在项目开始之前预付50%，项目可以进行到验收的时候，再付30%，正式上线后全部结款。后续还将给予免费的半年服务。
年初，软件开发项目正式启动。先期A把各功能模块原型网站提供给B，比如，新闻发布系统、论坛，甲方都有自己中意的网站。让ISV按照自己所中意的网站功能来做开发的参照⋯⋯刘一民当时认为自己的需求应该是简单明了。
“最初我们在选择哪种开发语言犹豫了很久。最后选定了PHP；主要是因为PHP开发简单，占用系统资源少。JAVA虽然具有跨平台及安全性高的特点，但是项目投资及占用系统资源较大。”刘一民说。由于刘一民作为甲方的主要负责人对于IT技术并不陌生，他认为，双方在沟通上应该更容易达成共识。
合同商定，项目实施期限为两个半月。客户方为此配备了本地服务器、IDC托管、数据库系统和网络系统。与此同时，为了组建这个新的部门，刘一民开始招兵买马。也就是说，从人员到基础设备，客户方都作了充足的准备，各路人马各就各位准备在新业务中大展鸿图，可谓势气充足。剩下的就是等待这个信息平台的正式上线。
第一次出现分歧
在刘一民看来，这是一个并不复杂的项目。按说B公司的速度并不慢，四个软件技术工程师组成的项目组在半个月后就将开发出来的系统平台雏形交到刘一民手中。
结果却出人意料。作为甲方项目负责人，刘一民大为惊异地发现项目原型跟自己当初的设想简直就是南辕北辙：“甚至于他们提供的原型图都有错误，小到图变形偏色，大到逻辑功能都弄错了，连版式都出现错误。第一个版本简直是完全失败的！”
在项目的进一步推进中，刘一民还发现，只要一涉及到修改版式，对方就会以各种借口要求项目延期，“一个小小修改，就要求给出十天时间，虽然对方没有提出要求增加项目的费用，但是对计划中等待上线的我们来说，付出的实际上有超出预算的时间成本。”
其实，刘一民也很清楚，没有一个ISV能把第一个版式顺顺当当拿出来。可是，如果在此时，对方及时将必要的需求文档补上，重新对客户的需求进行分析，则可以将双方的损失减到最低。
但是这家ISV为了节约时间，根本无暇顾及规范文档的问题。他们采取客户提出一个错误就这个错误对着修改，结果却是旧错误派生出更多新错误。
“他们太轻视这个项目了。没有仔细分析客户需求。在正常情况下，需求规格说明书是在项目开发开始前就该做好双方签字的，而且做的过程中就该主动和我们沟通。”刘一民说。时间成本的损益为了加快项目进度，甲方公司其他同事开始参与进来，帮助做测试。但由于甲方大部分人员对专业技术的了解相对有限，他们只能从业务方面根据自己的使用习惯提出相关变更需求。
“此时，实际上需要开发商对他们的这些需求进行甄别，明确哪些功能是可以通过IT技术来实现的，哪些是超出了他们的业务开发的范围的。并且，在这个过程中应该由开发商来建立严谨的确认文档，以明晰双方的责权利，为后期追加项目资金投入作依据。”软件工程师出身的刘一民对此相当熟悉，但他想不到即使在这种情况下，乙方也未采取相关措施。
刘并非不愿说服公司停止该项目，只是他更清楚公司为此要付出代价：“我们必然要付出更长时间。因为不仅所有的需求我们要重新讲一遍，并且即使这样，也无法肯定别家开发公司会比这家更好？”
乙方的项目工程师也抱歉地表示，他们当初低估了这个项目的复杂程度。相关负责人直言不讳：“我们也希望这个项目能快点完工，公司在项目上投入的人员已经超过了项目成本，实在耗不起了。”
7个月下来，这个小型的项目始有眉目。其间，这家软件开发商临时抽调了更多人来参与，大大超过预期投入成本。核算下来，他们基本无利润可言。
客户方同样受损。他们计划在其年会发布该系统，结果因为系统延误而使负责人非常被动。因此，客户不仅不承认超出原定项目的投入额度，还表示应该由开发商来承担因项目延期给他们造成的损失。这次损失达到项目总额的二三倍。由此造成所有人都不希望看到的双输局面。
规范化管理VS时间、成本
上述不成功的案例正是ISV众多失败案例中不起眼的两个。
从项目成功的美好愿望开始，到出它每天都在发生—不同时间，以不同方式发生在不同的ISV身上，给用户信息化建设带来不同程度的危害。
一项来自Gartner的统计显示，全球信息化建设中80%〜90%的项目投资并未达到预定目标，40%的项目是以失败或放弃而告终。在国内，这一情况更不容乐观。
项目周期难以控制、质量不可靠、成本上升、供求不符，几乎是每个“问题项目”的相同表现和甲乙方烦恼的根源。在失败的项目前，甲方和乙方都可以为自己和对方找出太多理由：
“造成ISV在接手案子之后不赚钱的主要原因，正是他们接到项目就匆忙上马，对于项目实施进度评估不到位，管理不规范所致。”
“甲方需求总在变更，太多的需求变更造成了项目延误。”
“一分钱一分货，再说甲方的工期给得太紧，一切按规范化管理进行，时间上肯定来不及，不硬着头皮接这个客户又没了。
多变的软件项目
同为项目管理，软件项目管理与其他项目管理最大的不同之处在于，其难以确定需求及变更充斥其间。
有经验的项目经理都知道，软件项目中最核心的部分不在于开发技术、使用语言或架构，而在于需求不好确定。究其原因，在于开发人员是技术思维，而客户对技术不了解，多数停留在自己业务的思维层面。所以，如何用技术实现用户的业务流程，是需求确认过程中的核心。
现实是，与国外不同的是，国内软件开发面对的是多数用户无规范的业务流程，其间充满随机性。这样一来，帮助客户梳理和规范流程成为开发商重要的额外工作。
在规范业务流程的过程中，由于众所周知的利益分配问题，往往会出现两种情况，一是盲目夸大自己部门的重要性，二是刻意隐蔽部门的重要性。其中的普遍现象是，除了直接部门主管或老总外，多数员工都无法完整描述该部门的主要业务。而前者往往没有时间去跟开发商一一交流，因此项目中因这种信息缩水或需求描述不当，引发的问题层出不穷。因此，业界有个不成文的说法，即老总牵头的项目，成功率会大大提高。一方面在公司资源调配上会更得心应手，另一方面领导层对公司业务需求掌握充分。
需求只是整个软件项目开发过程中的一部分。从需求、开发、测试，到部署上线，变更充斥其间，这也是软件项目一直被视为项目管理中最复杂部分的主因。无奈的人治面对复杂的软件项目，业界并非没有尝试过解决办法。无论HP、IBM还是CA都有相关的项目管理和软件开发规范化工具及解决方案，从软件开发的需求分析、配置管理、变更管理和测试管理各个层面上尝试规范复杂多变的开发进程。从理论上，我们也并不缺乏如CMM、ITIL这样的基础，达到CMM几级标准一度还成为衡量软件企业实力的试金石，甚至还曾出现了专门帮助“过级”的公司和商业组织。
然而，从实际应用上看，“软件开发项目管理大多还停留在人治阶段。”（某资深项目经理言）。也就是说，如果带项目的经理经验丰富，手下的软件工程师也得力，该项目就相对更有保障。这也从另一层面上解释了为什么产生软件行业并不景气，而好的软件工程师和项目经理人永远“一票难求”的现象。
时间与成本的桎梏
把项目的成败放到一个人，还是一个体系上，哪种更可靠？结论不言而喻。但为什么业界无法走出这一步呢？答案还得回到时间和成本上。实现规范化管理，需要采购相关的软件工具，也需要培训程序员去使用，更需要项目过程中项目经理、程序员和甲方的配合实施。
“但多数甲方认为我们付的软件开发费里，已经包括了项目管理成本，”周利斌表示，“甲方并非不愿意乙方的规范化管理，但他们多数不愿为此买单，无论是在时间还是在资金上。”
而作为ISV一方，为了拿单，多数已经因过分承诺而“伤痕累累”，即使想做也有心无力。何况软件业界每年超过20%的人员流动率，使得很多ISV不愿也不敢在培训员工上花费太多。有良好的意愿，而无实现的土壤，这正是国内软件行业独有的“中国特色”。
不依规矩，不成方圆。以作坊应对集团，以家传老店应对连锁，以随意应对体系，这在短时间内也许还可行，劣币驱逐良币的现象在一段时间内也还会发生，也许，这是国内软件行业发展过程中必须经历的阵痛。
