我现在在一家日本公司工作。最近委托给国内一家公司开发的软件提交了第一个版本。情况非常不理想。用我日本上司的话来说，开发团队根本没有理解开发这个软件的意图和目的，目前提交的软件与他最初头脑中的想象差别非常大，甚至是方向上的差异。
对这样的结果我并不感到惊讶和奇怪。我认为离岸外包项目中最大的两个风险在这个项目中得到了充分的体现。
这个项目是由日本方面在日本完成式样书的编写，也就是完成需求分析工作。在国内的外包公司完成分析，设计，开发和测试。
这个项目的需求做得并不算好。很多功能只是停留在概念性的描述，缺少细节。需求文档本身并没有能清楚说明开发该系统的目的，以及本系统试图提供给用户的价值，开发人员不能理解这些东西也就很正常了。当然，试图一次性的写出完美的需求说明书是件困难的事情，如果不是不可能的话。需求说明书的作者和开发人员之间有着不同的知识和经验背景。有些东西，可能作者以为开发人员知道，或者以为自己已经讲清楚了，而实际上并不是这么一回事。解决这个问题的办法就是反馈。通过开发人员和需求说明书的作者之间的讨论和沟通，逐渐弥补双方对需求认识上的差距，并不断将需求说明书补充完整。但这个项目中恰恰在这一环节上非常薄弱。
需求的作者在日本，开发人员在中国，双方完全没有直接的沟通。更不用说面对面的沟通了。开发人员拿到并读过需求以后，整理了一份问题列表，然后交给在日本的“BridgeSE”，“BridgeSE”根据自己对需求的理解回答了一部分问题，然后将剩余的问题以及自己的回答一起交给需求说明书的作者。该作者对所有的问题给出回答，或者对BridgeSE的回答予以确认，然后再通过BridgeSE将答案传给在国内的开发团队。这样一个过程化了超过两个星期。
在我看来，这个过程未免过于漫长了。而且在开发以前，只有一轮问答过程是远远不足以使开发人员完全理解需求的。但是，这个项目本身的开发周期就不长（第一版的实际开发时间约两个月），从时间上来说也不可能安排再更多的问答时间。而且即时再安排一轮，也未必有用。
本来，在离岸外包项目中，BridgeSE应该起到非常重要的桥梁作用。他应该和用户以及开发团队都保持密切的沟通。对需求，他应该达到和需求说明书的作者差不多的理解程度。但是不知道为什么，在这个项目中BridgeSE没有起到这方面的作用。
然后，不管怎么样，接下去就是分析，设计和开发阶段了。大约半个多月以后，交付了一个阿尔法版。但其实是一个只有界面，而基本没有功能的版本。因为需求中用户界面部分还是讲的比较详细的，因此在界面开发方面当然也没有太大的问题。但是因为界面后面的功能基本都没有做，因此也无从知道开发人员是否真正理解了需求。
此文章共有3页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
