1前期需求不明

按照软件工程学上的理论，前期的需求分析需要占掉整个软件开发生命周期的三分之一，可是在做了几个大型的日本外包项目之后，并且经历过几个前期需求分析之后，深深的感到需求分析是跟着开发一起做的，盲目草率的提案，客户的模糊确认，在项目开发初期就埋下了一个巨大的隐患。
以最近的一个项目为例，2006.5一个项目开始，需求分析是日方发起，我们推动的，本来需要用一到两个月进行详细的需求分析和提案的，可是在日方提出了，一定要抢占市场的观点下，用了2个星期匆忙提案，设计开始启动，在这2个星期中，本来不该这个时期做的一些工作，为了使日方能够承认我们能力，匆忙做了简要的概要设计，需求可以说基本上没有做什么，这样为以后的开发带来了巨大的麻烦，当最后我们拿着我们开发的东西给客户提交时，客户对我们的东西很是惊讶，感觉上好像完全不是他们要的东西一样，然后开始进行了第二次开发，最终也没有达到提前抢占市场这个目的。

2设计过于理想化

毕竟再好的系统设计方案都不能够绝对完美的，必须对一些东西有取有舍，才能让一个设计变为可行。
以另外开发一套生产管理系统为例，系统想的过于理想化，配置文件到处都是，配置文件的配置文件也随处可见，使得设计陷入了一个无限循环，现在这个系统已经完成，但是由于设计开发过程中理想的东西太多，配置的东西太多，最终导致现在这套系统没有人能让它顺利的转动起来，自然也就更别提应用了。

3变更不断

产生这个问题的原因不用说，也可以想到是由以上的情况导致的，我想这是日本外包项目的一个通病，也是导致最终失败的一个重要原因。
以自身经历的一个日本知名汽车公司的销售系统为例，2005.1项目开发开始，刚开始一切风平浪静，一切按部就班的运作，开发完成，进入单体测试（2005.4），在单体测试快完成之际，设计的变更开始陆续的发过来了，开始没有太在意，都是一些小的变化，简单对应后再次进行单体测试，仍然可以保证2005.8.1的提交。但是没想到的事情是，2005.5开始变更一发不可收拾，像雪花一样纷纷下来，没有办法加班对应吧，但是现在已经完全不能按照计划进行了，只能一边对应开发，一边进行单体测试，一边进行结合测试，最终变更还是把我们堆成雪人，体制完全转为了对应变更，好在这个项目在70多个人的加班加点下，最终完成了提交，
但是回想起来，还是挺危险的。

以上根据表面的现象分析出来的一些原因，如果加强这些地方的控制是不是就能够转变呢？
答案是否定的，当我有机会来到日本工作的这一段日子里，发现出现日本外包项目最终失败的原因中日之间的文化差距太大了。

日本是一个太注重于以人为本的国家了，客户至上的观念在这里表现的淋漓尽致，客户任何需求都要达到的想法也随处可见，当然作为软件开发来讲这是应该的，但是什么都要有一个度，过而不及这个词我在日本的这些日子中有了深刻的体会，由于客户的一个小小的不满，可能会把整个软件设计框架推翻重做的事情也在身边随处可见。

日本也是一个太注重于自动化的国家了，什么东西都想自动实现，当然这不能说不好，但是好像现在还不可能做到吧。一个深刻的感受就是，为了少写几句代码，可能会开发出一个工具，进行相当复杂的设置之后，生成一个还需要再修改的代码。

综上所述，日本外包项目失败的原因显而易见了。

以上只是本人的一些经历和一些肤浅的看法，不过还是想和大家分享。谢谢