偶然看了网友 BirdGu 的一篇文章（ http://blog.csdn.net/BirdGu/archive/2006/04/25/677369.aspx ），文中分析了一个失败的外包项目里面的风险问题。非常感谢 BirdGu 能拿出这么宝贵的经验和大家分享并提出了自己得见解，我自己在这方面也思考了很多，就该文中提出的问题，我自己也假设了一些情况，谈谈自己想法。

     第一个就是需求，作者也认为该项目的需求做的不好，如果再深究下去，不好的原因是什么呢？我自己的看法，该项目需求没做好的原因可能有以下几个原因中的一个或者几个

1．    用户自己都不知道需求是什么，传达给日方公司的需求也就是不明确的。

2．    用户虽然知道需求，但是日方的设计人员没有理解，或者一知半解，也就写不出合格的需求说明书。

3．    日方的设计人员对需求也很明白，但是写出来的文档中方开发者不能很好理解，而他自己却觉得自己表达的很清楚了。

   如果是第一个或者第二个原因，那该项目的失败就不仅仅是沟通上的问题了，起码日方的公司要负大部分责任。原因很简单，能把一个自己都不明确的需求发给别人来做，本身就存在问题，更别想得到符合需求的产品了。而现实中这种情况确实存在，怎么办？首先，日方公司要对这个问题加强认识并改进，改进的办法可以有很多，最根本的就是从管理制度上去解决，对需求是否完备要有相应的审核制度，并且纳入质量管理体系，形成管理制度同时又要严格执行。或许这不够敏捷，但是敏捷并不仅仅追求速度，而是在追求速度的同时保证质量的，也就是又快又好。后面我将阐述我对敏捷的认识。

    至于第三个原因，完全是一种理解上的差异造成的，作者也有所提到，要解决这个问题，需要不断的反馈，我完全同意。但是反馈什么呢？仅仅是告诉对方哪个地方不明白么？我想这种情况下，中方公司可以理直气壮的指出该需求说明中的不足，并提出希望增加相关的内容，这也给日方一个信息，就是告诉他们我们开发者希望看到的需求是什么样的。同时，中方的开发人员也应该加强理解日本文化，商业习惯，业务这方面的意识，经常有这样的情况，一个需求，即使非常明确，我们也常常按照自己的理解想当然的来做，结果作出来的东西，根本不符合对方的要求。如何做呢？我想最基本的要理解日本的会计规则，日语也叫簿记，企业系统无非就是人财物的流动，而这里面最核心的就是财，也就是钱的流动，理解了这个，对很多项目都有帮助。其次，日本人非常重视法律，很多新颁布的法令对业务系统和流程都有影响，这方面也是一个重要方面，例如马上要实行的 SOX 法，就让很多日本企业修改他们的业务系统以应对该法令。

    第二个，作者提到了 BSE 的职责问题。我也想谈谈自己的看法。 BSE 是做什么的？是一个重要的沟通窗口。那么这个窗口摆在日本还是中国就值得好好考虑了，我觉得把 BSE 安排在国内更好一些。理由很简单，离现场最近，最符合敏捷原则，最有利于发现问题，并及时进行沟通。 BSE 没有履行好自己的职责，这个原因也是需要深究的，使能力不足还是职责不明确。 BSE 的能力除了技术之外，更多的是对业务的理解，对开发过程的把握，发现问题，及时沟通及时解决。另外，日本人定义的 SE 和我们理解有所不同，他们要求的更多，更广泛，有时间我会另外写一篇文章介绍的。

    第三个，开发过程运用了迭代开发，并交付了一个阿尔法版，却没有发现其中对需求理解偏差的问题。这里面的问题就是中日双方对什么是软件原型的理解存在了误差，画面仅仅说明了针对用户的接口，并不能证明对需求理解的正确性，画面后面的各种各样的处理才是关键，那个日本上司的抱怨，其实只能怨他们自己。同时，中方的开发人员也没有作出一个合格的阿尔法版，也有一定的责任。阿尔法版里面应该用假数据体现出后台处理的过程，然后日方来判断该过程是不是正确。如何体现呢？我想应该有简单扼要的说明文档，所谓简单扼要就是多用图，少用文字。

    第四个，开发管理我认为也存在问题。这个问题是日方的。也就是日方对中方这边的开发没有进行良好的管理和监督，这个不是沟通和 BSE 能够解决的，而是由该公司的管理制度决定的。不仅日本的外包存在这个问题，日本国内的开发也有这个问题，项目包给合作公司后就不管不问了，结果一交付，什么问题都来了。

    最后说一下我对敏捷的理解。看了 Object Primer 后，我最大的收获就是对敏捷理解更加深入了。我现在的理解就是，敏捷就是用最简单最有效的办法，最快的解决问题，说白了就是不用拘泥于什么是敏捷不敏捷，也不用拘泥于什么形式，只要实用有效就好。谈敏捷的书里面列出的一些最佳实践，固然不错，但是真正的操作起来，不能生搬硬套，需要根据我们的实际情况设计出符合自己的敏捷方法，有时候即使不十分敏捷只要有效也不失为一个好办法。

     以上是我的理解，欢迎大家拍转！