软件外包服务失败背后的经验

　　在失败来临之前，其实有不少征兆已然出现。

　　周庆瑜/文

　　在我们刚采用软件外包服务时，合作过的技术厂商只有一两家，且都是规模非常小的作坊式企业，因此这家企业一开始就让我印象深刻——他们派了个老外来跟我们谈业务，带来的资料有他们开发软件的方法论及整体的架构，看起来非常专业。

　　接下来，在项目正式展开之前，我们跟对方的总经理（现任董事长）见面，讨论具体的项目开发方法论以及质量保障体系。不得不承认，他们的方法论让我感觉非常好，对方的经营团队表现出来的专业水准，也令人觉得不错。当时，尽管我觉得有一些地方不是很顺畅，但也只是觉得因为这是新企业在调试阶段必然有的情况，也没怎么放在心上。

　　在确认了对方的资质后，双方进入了实质性项目合作阶段，从签定保密协定、提出系统开发规格给乙方，再到具体排定开发进度以及报价。在报价阶段，对方展现出了极大的弹性。当时，我们认为这是一种诚意的表达，于是习惯考虑性价比的我们几乎是以雀跃的心情跟对方签了约。没想到的是，一场噩梦开端了。

　　在项目前期，一切都还在我们的控制之中，项目启动会议及固定周期的检讨会议也都能按照正常规范进行。我们的项目经理在前期跟我报告对方除了项目经理以外的人员都毕业不超过1年时，我的想法是对方既然有完善的管理制度，项目的质量当然也有一套保障方法，我们只要定期审核项目进度就可以了，所以当时我不在意。

　　然而到了项目后期，问题终于爆发出来了。首先，是我们要求对方做功能性演示，结果发现整个流程甚至不能完整地跑完。我发现对方为了赶进度，居然没有做好内部的质量保证工作，导致质量出现很大问题；然后，项目出现了很大的效能问题，程序的效能慢到无法接受的地步，用户界面的友好性也完全无法接受。此时，他们的反馈居然是这些问题并没有明确定义在甲方提供的规格书中，所以不能算是乙方的问题。依照以往的认知，稍微正规一些的软件开发商肯定有一套自己的编程规范，如果按照规范来做，无论如何也不可能出现这么离谱的问题，我们不得不回头去检查源代码，果然发现他们的5个开发人员完全各自按照自己思路开发，这个项目变成了乙方培训员工的一个项目。此时，我才知道当初他们在价格上的弹性，原来是这么来的。

　　还好，对方的销售人员还算愿意负责，承认是他们的错误，大家开始友好协商如何能够把项目结掉。如果这个时候，对方按照承诺完成项目的话，这个项目只能说是一个比较波折的项目，还可以勉强算是成功，毕竟很多软件项目都经历过这种历程。可惜的是，这个时候又发生了几件事：首先，他们的开发人员产生很大的抵触情绪，认为他们按照规格开发，没有错误，现在要返工，对他们不公平，这个情绪直接导致开发人员效率低下。再者，在我们发现项目质量有问题后，对方的测试人员开始介入项目，结果在质量及进度的双重压力下，导致测试人员与开发人员的对立。于是，对方销售人员答应的进度因此一再拖延，我们的内部用户则不断在内部质疑项目到底何时能上线。让我觉得最离谱的是，乙方的项目经理居然在这个节骨眼上，被抽调到微软的一个项目中，这也是导致我们要求就此终结合作、不付尾款的最后那根稻草。

　　事情的结局是，我们找到原来报价高出甚多的一个供应商，让他们来做收尾工作。这个项目最终还是平安上线了，但是该花的钱却一毛也没少，上线时间则至少推迟了3个月。

　　我对这段被内部业务部门“追杀”的日子记忆犹新，那时几乎每周我都会在内部会议做上检讨。这样的日子差不多整整两个月，现在想来都心有余悸。

　　在经历过这个项目后，我从中汲取了一些经验：

　　1. 价格绝对不是外包中最重要的；

　　2. 在进行大型外包项目之前，与合作伙伴一定要有几个小项目的合作经验；

　　3. 外包服务商的客户名单上如果有大型客户，对一般企业级客户而言，不见得是好事，因为它的资源肯定会优先支持大客户；

　　4. 外包商的员工经验很重要，而我观察到很多外包商在快速成长的同时，稳定度也在被快速稀释；

　　5. CIO在项目外包出去后，对项目经理的要求也要提高，不能像以前那样留有诸多灰色地带；

　　6. 一旦发现外包商有问题，就要当断则断。

　　这几点经验看起来似乎没什么特别出奇的地方，但这可是我们花了大代价才得出的。