今日案例分析——项目外包的失败

翔羽

<span class="main"><strong>案例</strong></span> <p class="main">　　<strong>D公司对日软件外包项目失败的故事</strong></p><p class="main">　　这是一个针对日本的软件外包项目。客户是日本的一家著名的大企业，全球500强之一。</p><p class="main">　　客户要求的内容很多，也很严格，不仅要求使用指定的技术和工具，而且还自主开发了一个平台，要求在该平台上进行开发、测试；还有各种文档格式要求和技术要求；最重要的是要保证工期，一定要在2个半月内提供高质量的、完整的产品。</p><p class="main">　　中国数家企业参与了该外包项目。D企业是其中之一，主要负责该项目40本程序（本是实现一个完整功能的程序单位。一本程序也就是一个程序。这与我们国产软件的设定不一样。）的详细设计、编码以及单体测试工作。</p><p class="main">　　<strong><font color="#0000ff">成立项目组</font></strong></p><p class="main">　　项目立项后，D公司成立了项目小组。项目经理是一名在对日软件项目方面有多年开发经验的开发人员，但是，他是第一次带项目。项目经理下设三个小组：负责详细设计的DS小组（6名成员），负责编程的PG小组（5名成员）以及负责测试的PT小组（5名成员）。每一小组设置一名小组长，配备若干组员。（见图1）</p><p class="main">　　同时，D公司在日方派驻了一名SE（高级分析设计人员），主要负责分析、设计以及中日两方的协调工作。DS人员具有丰富编程经验，提前1周进入了项目组工作。</p><p class="main">　　之后，PG和PT小组成员开始进入项目。项目经理安排PG和PT小组1周内熟悉这个复杂的平台。</p><p class="main">　　项目正式开始了。经过分析，项目组决定将40本程序分为A、B、C三类，分别包括10本，12本，18本程序。其中，A类的难度看起来似乎不高，是一些数据库表的维护工作，和业务没有太大关系，工作量也很少。B类和C类难度预计差不多，但是，分别属于不同的业务领域。</p><p class="main">　　一个星期后，部分程序的详细设计出来了。为了保证工期，项目小组决定三个小组同时进行，并行工作。详细设计人员继续做详细设计，编码人员投入编码，而测试组成员同时编制测试设计书，并设计测试数据。</p><p class="main">　　<strong><font color="#0000ff">初试成功</font></strong></p><p class="main">　　项目经理决定PG小组首先从难度最小的A类程序入手，这样不仅可以看到成功的曙光，而且可以鼓舞大家的士气。于是，5名PG小组成员开始分别着手A类程序。一切都很顺利。1本程序差不多在2天内完成了。</p><p class="main">　　一周后，A类程序全部编码完成，PT组开始测试，完成了一半的测试工作。随后，测试修改完毕后的5本程序交给日方确认，顺利通过，客户评价也极高。</p><p class="main">　　于是，项目经理信心百倍，项目组成员也信心十足。经过仔细分析，剩下的B类和C类程序，可以根据处理侧重点的不同划分为入力系、Batch系、账票系三类，比例大致相当。项目经理也更新了进度计划。新的进度计划中，每名PG成员分别负责2本入力系、2本Batch系、2本账票程序。DS小组的工作也进展顺利。</p><p class="main">　　<strong><font color="#0000ff">遭遇难题</font></strong></p><p class="main">　　正当大家怀着胜利的喜悦继续前进的时候，PG小组遇到了很大的难题。日方提供的开发平台太复杂了。此时，项目小组才发现，已经开发完成的A类程序其实只是一种2层结构的程序，而B类、C类程序是复杂的3层结构，要搞清楚如何开发这些程序不只需要时间，更需要充足的经验和高超的技能。PG小组成员纷纷卡壳，不知道该在哪儿赋值，不知道该在哪儿取值，与以前接触的编程截然不同，似乎每本程序都有一个无穷的长链，只有龙头，没有龙尾，无法理清。</p><p class="main">　　一周过去了，原定很顺利就编写完的程序的实际进度却是5%，或者10%，这并不是说，已经开发了5%或者10%，而是为了表明这些程序的开发工作已经开始，而向客户展现一种开发中的姿态（因为每日都要给客户发送进度报告）。于是，项目经理开始要求大家加班。</p><p class="main">　　两周过去了，技术最好、经验最丰富的一名PG人员—小G的进度率达到了40%，而其他成员仍然在原地踏步。大家纷纷去请教小G，小G不耐烦地回答：“去看日方发过来的资料吧”。</p><p class="main">　　烦躁，焦虑，疲劳，一名PG成员病倒了，打了个电话要请假。过了几天，又一名PG成员也来电话请假，说是感冒。三周后，也就是1个月后，除了10本C类程序全部开发完成，通过验证外，只有一本程序的进度率达到了80%。5名PG成员中的2名病倒了。大家都忙着从数百页的日文开发手册中寻找答案。</p><p class="main">　　于是，项目经理开始要求PT组有经验的成员加入PG组以填补空白。</p><p class="main">　　小G的程序完成了，可是运行后什么也没有。又经过一周，小G的程序基本可以运行了，但是还有很多的技术问题，测试结果极不理想。</p><p class="main">　　<strong><font color="#0000ff">紧急救“火”</font></strong></p><p class="main">　　工期已经非常逼近，不能再等了，于是项目小组开始向公司反映情况。公司立即从其他项目组中抽调了2名经验丰富的“技术高手”来协助。鉴于绝大部分程序的详细设计已经完成，召回了在日本的窗口SE—“业务高手”，同时安排大家都加班。</p><p class="main">　　为了很好地运用小组中的知识财富，D公司安排小G不再继续开发工作，而是做技术总把关，做专职的问题解决能手。后来，集中大家的智慧，解决了入力系的入力难题，解决了Batch系的没有界面而有极多数据复杂处理问题，以及账票系的账票出力问题。</p><p class="main">　　快到截止日期时，原有的PG成员中有2名开始长期请病假。</p><p class="main">　　经过大家的齐心协力，加班加点，在预定截止日期的当天，所有程序都开发完毕，测试完毕，只是还有很多问题和错误需要修正。</p><p class="main">　　为了保证工期，项目经理决定暂时将问题和错误隐蔽，将所有的测试报告中的“再确认”一栏填写上“OK”。项目经理提交所有预定提交的成果物。同时，PG和PT人员仍在继续奋战。</p><p class="main">　　一周后，日方发过来大量问题，绝大部分是单本程序的问题。项目小组继续修正。一个月后，项目终于结束了，项目小组才得以解散。</p><p class="main">请详细阅读本案例，然后站在从D公司的角度分析该项目失败的原因。</p><p class="main">[2]从日方的角度分析该项目失败的原因</p><p class="main">[3]假设D公司有足够你需要的技术人员，而你是该项目的管理人员，你会怎么做，请作出详细的项目计划？</p><p class="main">&nbsp;</p><p>&nbsp;</p><p><font color="#dddddd">[案例来源： 作者：周名 左美云　来源：赛迪　http://www.csai.cn　2006年1月20日]</font></p>

[此贴子已经被作者于2006-3-2 21:41:32编辑过]