作/转载者：中国人民大学信息学院 周名 左美云

　　软件外包已经成为世界软件产业发展的一个重要趋势，中国也在大力发展软件外包。在国内整个软件出口中，对日出口的比例高达70%。这似乎说明了中国的对日软件外包业务已经比较成熟了。但是，事实却不然。尤其是在对日软件外包项目的运作上，还存在着计划失策、预计不准确、任务分配不科学等问题。
　　案例
　　D公司对日软件外包项目失败的故事
　　这是一个针对日本的软件外包项目。客户是日本的一家著名的大企业，全球500强之一。

　　客户要求的内容很多，也很严格，不仅要求使用指定的技术和工具，而且还自主开发了一个平台，要求在该平台上进行开发、测试；还有各种文档格式要求和技术要求；最重要的是要保证工期，一定要在2个半月内提供高质量的、完整的产品。

　　中国数家企业参与了该外包项目。D企业是其中之一，主要负责该项目40本程序（本是实现一个完整功能的程序单位。一本程序也就是一个程序。这与我们国产软件的设定不一样。）的详细设计、编码以及单体测试工作。
　　成立项目组
　　项目立项后，D公司成立了项目小组。项目经理是一名在对日软件项目方面有多年开发经验的开发人员，但是，他是第一次带项目。项目经理下设三个小组：负责详细设计的DS小组（6名成员），负责编程的PG小组（5名成员）以及负责测试的PT小组（5名成员）。每一小组设置一名小组长，配备若干组员。（见图1）

　　同时，D公司在日方派驻了一名SE（高级分析设计人员），主要负责分析、设计以及中日两方的协调工作。DS人员具有丰富编程经验，提前1周进入了项目组工作。

　　之后，PG和PT小组成员开始进入项目。项目经理安排PG和PT小组1周内熟悉这个复杂的平台。

　　项目正式开始了。经过分析，项目组决定将40本程序分为A、B、C三类，分别包括10本，12本，18本程序。其中，A类的难度看起来似乎不高，是一些数据库表的维护工作，和业务没有太大关系，工作量也很少。B类和C类难度预计差不多，但是，分别属于不同的业务领域。

　　一个星期后，部分程序的详细设计出来了。为了保证工期，项目小组决定三个小组同时进行，并行工作。详细设计人员继续做详细设计，编码人员投入编码，而测试组成员同时编制测试设计书，并设计测试数据。
　　初试成功
　　项目经理决定PG小组首先从难度最小的A类程序入手，这样不仅可以看到成功的曙光，而且可以鼓舞大家的士气。于是，5名PG小组成员开始分别着手A类程序。一切都很顺利。1本程序差不多在2天内完成了。

　　一周后，A类程序全部编码完成，PT组开始测试，完成了一半的测试工作。随后，测试修改完毕后的5本程序交给日方确认，顺利通过，客户评价也极高。

　　于是，项目经理信心百倍，项目组成员也信心十足。经过仔细分析，剩下的B类和C类程序，可以根据处理侧重点的不同划分为入力系、Batch系、账票系三类，比例大致相当。项目经理也更新了进度计划。新的进度计划中，每名PG成员分别负责2本入力系、2本Batch系、2本账票程序。DS小组的工作也进展顺利。
　　遭遇难题
　　正当大家怀着胜利的喜悦继续前进的时候，PG小组遇到了很大的难题。日方提供的开发平台太复杂了。此时，项目小组才发现，已经开发完成的A类程序其实只是一种2层结构的程序，而B类、C类程序是复杂的3层结构，要搞清楚如何开发这些程序不只需要时间，更需要充足的经验和高超的技能。PG小组成员纷纷卡壳，不知道该在哪儿赋值，不知道该在哪儿取值，与以前接触的编程截然不同，似乎每本程序都有一个无穷的长链，只有龙头，没有龙尾，无法理清。

　　一周过去了，原定很顺利就编写完的程序的实际进度却是5%，或者10%，这并不是说，已经开发了5%或者10%，而是为了表明这些程序的开发工作已经开始，而向客户展现一种开发中的姿态（因为每日都要给客户发送进度报告）。于是，项目经理开始要求大家加班。

　　两周过去了，技术最好、经验最丰富的一名PG人员—小G的进度率达到了40%，而其他成员仍然在原地踏步。大家纷纷去请教小G，小G不耐烦地回答：“去看日方发过来的资料吧”。

　　烦躁，焦虑，疲劳，一名PG成员病倒了，打了个电话要请假。过了几天，又一名PG成员也来电话请假，说是感冒。三周后，也就是1个月后，除了10本C类程序全部开发完成，通过验证外，只有一本程序的进度率达到了80%。5名PG成员中的2名病倒了。大家都忙着从数百页的日文开发手册中寻找答案。

　　于是，项目经理开始要求PT组有经验的成员加入PG组以填补空白。

　　小G的程序完成了，可是运行后什么也没有。又经过一周，小G的程序基本可以运行了，但是还有很多的技术问题，测试结果极不理想。
　　紧急救“火”
　　工期已经非常逼近，不能再等了，于是项目小组开始向公司反映情况。公司立即从其他项目组中抽调了2名经验丰富的“技术高手”来协助。鉴于绝大部分程序的详细设计已经完成，召回了在日本的窗口SE—“业务高手”，同时安排大家都加班。

　　为了很好地运用小组中的知识财富，D公司安排小G不再继续开发工作，而是做技术总把关，做专职的问题解决能手。后来，集中大家的智慧，解决了入力系的入力难题，解决了Batch系的没有界面而有极多数据复杂处理问题，以及账票系的账票出力问题。

　　快到截止日期时，原有的PG成员中有2名开始长期请病假。

　　经过大家的齐心协力，加班加点，在预定截止日期的当天，所有程序都开发完毕，测试完毕，只是还有很多问题和错误需要修正。

　　为了保证工期，项目经理决定暂时将问题和错误隐蔽，将所有的测试报告中的“再确认”一栏填写上“OK”。项目经理提交所有预定提交的成果物。同时，PG和PT人员仍在继续奋战。

　　一周后，日方发过来大量问题，绝大部分是单本程序的问题。项目小组继续修正。一个月后，项目终于结束了，项目小组才得以解散。
　　分析
　　D公司软件外包项目败在哪儿？
　　目前软件外包业务已经得到了长足的发展，无论欧美，还是日本的一些大企业，为了降低成本或者其他原因，都在将一些软件项目外包给其他国家成本较低的IT企业，印度的软件产业就是依赖于软件外包而成长、成熟。中国也已经举办了几次软件外包国际峰会，期望能够仿照印度，将中国的软件产业通过软件外包打入国际市场。

　　在日本软件外包市场，相对于其他国家，中国在文化上具有得天独厚的优势，语言方面更是远胜于其他国家的从业人员。因此，从日本的软件外包市场入手，是我国打入国际市场的首选，对日软件出口的比例高达70%。但是，很多对日软件外包项目并不是很成功，这个项目就是其中一个。

　　该项目最终在规定的时间内完成了。在一个月后的日本客户的《顾客满意度》调查表里，各项评价都较高，如“工期保证（5分），质量较好（4分）……”。看来，该项目得到了日方的认可。因为日本企业最重视的是工期，只要在预计的工期能够完整地提供产品，那么项目就是成功的。

　　但是，纵观项目的全过程，项目小组先是欢喜异常，觉得所谓的难度也不过如此，后来却感到惊慌失措，无法前进，原本骁勇善战的精兵猛将也只好当逃兵，称病请假。由此可知，虽然项目工期没有延迟，客户评价尚佳，但是，实际问题还有很多。
　　项目的四个隐患
　　仔细分析，可以总结如下：
　　1、项目技术复杂，出现技术瓶颈。在项目初期，项目组成员的技能对于B类、C类程序的技术要求来说，差距过大。以至于需要过多的时间来熟悉掌握。同时，由于时间原因以及这种技术瓶颈，导致本应熟悉业务流程的时间用在了解决技术难题上，从而导致本来不是很难的业务也成了一大难题。
　　2、开发人员信心不足。在项目后期，发生怯场称病请假的情况，这在软件行业里似乎并不多见。他们似乎已经顾不了自己应尽的职责和责任了。不是他们没有责任感、没有职业道德，而是他们实在受不了了。整天坐在计算机前，却无法解决问题，1周、2周都没有一点进展。正是由于责任感，使得他们异常焦虑，而焦虑使得他们实在承受不了这种压力和氛围，与其最后被逼得生病，还不如先请假回家。
　　3、项目管理不严。先是一名成员生病、请假。似乎请假太简单了，一个电话就可以了，不需要医院证明，还能拿到70%的工资，项目经理还和蔼可亲，温和的说“好好在家休息”。对此，其他成员肯定会有猜疑，觉得自己挺亏，最后也要请假，而项目经理也不好意思不批准。
　　4、急功近利，遮掩问题。其实，项目开展三周后，项目的问题就已经很突出了。可是，由于刚刚当上项目经理，为了证明自己的能力，为了掩盖已经发现的问题，项目经理没有向上级汇报问题，而是将自己的责任推给项目组成员，让大家加班加点，完成任务。直到离期限不到三周，实际完成的具备未知难度的B类和C类程序的开发工作量还不到1/30的时候，项目经理才知道不能遮掩了，这时才向高层汇报情况。经过公司高层的协调，才得已抽调人员，及时解决问题。 　　
　　谨防项目计划不切实际
　　以上四个原因，似乎都是很明显的表面问题，那么，最主要的核心问题是什么呢？究其根源可知，问题其实出在项目经理上，最主要的问题是项目计划过于乐观，而且不切实际、不合理。

　　其实，在项目早期，项目小组成员对日方的数百页的开发手册有些敬畏，都感觉到这个项目有些难度，但是，不知道难度具体有多大。

　　项目经理为了稳住军心，先将难度最小的A类程序排在进度计划的最前沿，这本无可厚非。因为按照开发A类程序的进度,他看似客观其实主观而且极为乐观地做了如下推算：1名PG 用2天完成1本程序，加上B类C类程序的难度，保守估计4天时间1本。那么完成40本程序的编程大概需要32天。一名测试人员用1天时间设计一本程序的测试设计书，2天测试完毕。一本程序在PT上大概需要3天时间，保守估计5天。完成40本程序的编程大概需要40天，编程可行。而且，测试不存在较大的难度，只是工作量的问题。总工期是44天。实在时间紧张，还可以安排加班。测试能力足够。测试没有太大的风险。

　　但是，他忽略了一点，为了稳住军心、增强信心的目的似乎有些单纯，以至于在达到这一目标后，在项目组成员从对项目的敬畏和担心中解脱出来后，随后就忘记了难度和复杂性，而和项目组成员一样欢呼雀跃，丧失了危机感，从而制定了较为糟糕的任务分配计划和进度计划，导致后期出现技术瓶颈，而又迫于期限，击垮了项目组成员，吓退了本应神勇的战士。
　　任务分配要科学
　　由于忘却了难度和复杂性的威胁，项目经理的任务分配计划也出现了问题。

　　在他的乐观估计下，项目肯定会异常成功。因此，他在A类程序成功完成的情况下，分配每名PG成员分别负责2本入力系、2本Batch系、2本账票系程序。这样一来，每一名PG成员都需要去学习掌握如何编程入力系程序、Batch系程序、帐票系程序，需要处理这些复杂的程序中潜在的技术难题。

　　但是，所有的入力系程序都是具有相同点的，只要写好了一本，其他的程序就可以仿照，可以说，如果写第一本需要15天时间，那么写第2本可能只需要4天时间。同样，Batch系程序和帐票系程序也具有类似的特点。

　　正是由于项目经理忽略了这种学习能力，导致他安排了大家去做同样的攻关工作，造成智力和时间的浪费，也影响了大家的情绪。直到后来才安排出专门的技术专家，集中解决问题，其他成员在技术专家指导下工作，提高了开发效率。

　　计划失策、预计不准确、缺乏危机感、任务分配不科学，是这个项目的主要问题，也是项目经理的最大问题。正是由于这些问题，导致了项目的差点失败。 　　事实上，这个项目并不是如客户评价的那样极佳，虽然通过种种措施保证了项目的顺利完成，但仍然留下了大量问题。因为，只要每本程序的质量得到保证，而设计书又是经过数次评审的，那么客户方发现的问题应该很少，而且应该只是一些业务流程问题。可是，提交项目产品后，客户发现的大部分问题是单本程序的问题，因此，该项目算不上成功。

　　据笔者所知，该项目在对日外包软件项目中具有一定普遍性。由此可知，规范项目管理流程，使项目小组中每个人包括项目经理和技术能手，对项目的影响缩小化，是中国对日软件外包企业需要关注和重点解决的问题，也是整个软件行业需要解决的重要问题。

　　ISO9001质量体系认证或CMM认证或CMMI认证能够起到一定的作用。同时，公司高层配备足够的质量保证人员或者项目管理办公室成员，应该能够对项目进展情况随时进行了解，也就能够尽早发现项目中的种种问题，从而避免后期的各种不得已的补救措施，引领项目成功。

　　图1　项目组织结构图