由一个失败的项目看离岸外包项目中的风险。

我现在在一家日本公司工作。最近委托给国内一家公司开发的软件提交了第一个版本。情况非常不理想。用我日本上司的话来说，开发团队根本没有理解开发这个软件的意图和目的，目前提交的软件与他最初头脑中的想象差别非常大，甚至是方向上的差异。

对这样的结果我并不感到惊讶和奇怪。我认为离岸外包项目中最大的两个风险在这个项目中得到了充分的体现。

这个项目是由日本方面在日本完成式样书的编写，也就是完成需求分析工作。在国内的外包公司完成分析，设计，开发和测试。

这个项目的需求做得并不算好。很多功能只是停留在概念性的描述，缺少细节。需求文档本身并没有能清楚说明开发该系统的目的，以及本系统试图提供给用户的价值，开发人员不能理解这些东西也就很正常了。当然，试图一次性的写出完美的需求说明书是件困难的事情，如果不是不可能的话。需求说明书的作者和开发人员之间有着不同的知识和经验背景。有些东西，可能作者以为开发人员知道，或者以为自己已经讲清楚了，而实际上并不是这么一回事。解决这个问题的办法就是反馈。通过开发人员和需求说明书的作者之间的讨论和沟通，逐渐弥补双方对需求认识上的差距，并不断将需求说明书补充完整。但这个项目中恰恰在这一环节上非常薄弱。

需求的作者在日本，开发人员在中国，双方完全没有直接的沟通。更不用说面对面的沟通了。开发人员拿到并读过需求以后，整理了一份问题列表，然后交给在日本的“BridgeSE”，“BridgeSE”根据自己对需求的理解回答了一部分问题，然后将剩余的问题以及自己的回答一起交给需求说明书的作者。该作者对所有的问题给出回答，或者对Bridge SE的回答予以确认，然后再通过BridgeSE将答案传给在国内的开发团队。这样一个过程化了超过两个星期。

在我看来，这个过程未免过于漫长了。而且在开发以前，只有一轮问答过程是远远不足以使开发人员完全理解需求的。但是，这个项目本身的开发周期就不长（第一版的实际开发时间约两个月），从时间上来说也不可能安排再更多的问答时间。而且即时再安排一轮，也未必有用。

本来，在离岸外包项目中，BridgeSE应该起到非常重要的桥梁作用。他应该和用户以及开发团队都保持密切的沟通。对需求，他应该达到和需求说明书的作者差不多的理解程度。但是不知道为什么，在这个项目中Bridge SE没有起到这方面的作用。

然后，不管怎么样，接下去就是分析，设计和开发阶段了。大约半个多月以后，交付了一个阿尔法版。但其实是一个只有界面，而基本没有功能的版本。因为需求中用户界面部分还是讲的比较详细的，因此在界面开发方面当然也没有太大的问题。但是因为界面后面的功能基本都没有做，因此也无从知道开发人员是否真正理解了需求。

在这之后就是最近的版本交付了。在外包公司而言，是系统已经开发完了。至少功能都开发完了，后面可能只是需要更多的测试和Debug。但是，对于定义需求的人来说，这时才发现开发出来的并不是他原来设想的东西。

在我看来，这个项目显示了在离岸外包项目中最大的两个风险：沟通不足，反馈太慢。

由于是离岸外包，用户和开发人员分处不同的国家，距离遥远，往往还存在语言，文化，习惯等方面的差异，这些都会给双方的有效沟通带来阻碍和困难。如果是那种在用户侧完成详细设计，在外包方仅仅进行编程和测试这种方式的话，沟通方面的困难带来的麻烦可能会少一些。但是，如果是象这个项目一样，外包方根据需求完成分析，设计，编程和测试的所有工作，那么所需要沟通的信息是非常多的。在这种情况下，如果过分迷信文档在沟通中的作用，仅仅依赖文档，甚至依赖非常正式的文档进行交流，我认为它带来的结果可能是灾难性的。主要问题，打个比方来说，就是信息沟通的“带宽”不够，“延迟”严重。

解决这个问题的办法是有两个。一是充分利用现有科技能提供的一切沟通手段，包括电子邮件，电话/电视会议，MSN，Skype等等，使开发人员和需求分析人员能进行“准面对面”的沟通，增加信息沟通的“带宽”和响应及时性。使得即时远隔重洋，开发人员的任何疑问都能得到最及时的解答。同时，虽然开发人员和需求分析人员可能属于不同的公司，但应该不再拘泥于沟通方式的正式性，而如同一个团队，一个办公室里的伙伴那样进行交流。在离岸外报项目中，要做到XP要求的“现场用户”是困难的，但通过现代科技手段，做到虚拟的现场用户也并非不可能。

另一方面，要充分发挥Bridge SE的作用。前面说过，BridgeSE对需求的理解应该达到和写需求说明书的人一样的程度。如果做需求分析的人不能到开发现场向开发人员解释需求（这应该是最理想的安排），那么Bridge SE应该做到这一点。而且BridgeSE应该和开发人员共同工作相当长的时间，以在一定程度上起到一个“现场用户”的作用。

当然，现在在离岸外包领域，比如对日外包，即能克服语言障碍，又有扎实的技术功底的人是非常稀缺的。如果有这样的人，一定会被同时用于几个项目。虽然这可能是一种无奈，但却不是正确的做法。

在离岸外报项目中，同样由于距离因素，频繁地向用户演示开发中的软件，反馈开发进度，也要比国内项目更困难一些。但是，仍然要尽力地按照“短迭代，经常发布”的原则去做。因为有前面所说的沟通方面的困难存在，更需要通过尽早地发布版本和向用户演示来及时发现对需求理解上的偏差。如果等到最后交付日才发现对需求完全理解错误，那麻烦就大了。

通过Internet，要做到这一点其实也并不那么困难。比如，对于基于Web的应用，完全可以在开发侧架设演示系统，让用户远程访问。BridgeSE可以在用户现场做演示，并听取用户的意见。

离岸软件外包项目的初衷是降低开发成本，但它同时也带来了新的风险。所幸，敏捷软件开发方法的很多原则和实践还是能帮助我们克服其中的困难和减少风险。