在这之后就是最近的版本交付了。在外包公司而言，是系统已经开发完了。至少功能都开发完了，后面可能只是需要更多的测试和Debug。但是，对于定义需求的人来说，这时才发现开发出来的并不是他原来设想的东西。
在我看来，这个项目显示了在离岸外包项目中最大的两个风险：沟通不足，反馈太慢。
由于是离岸外包，用户和开发人员分处不同的国家，距离遥远，往往还存在语言，文化，习惯等方面的差异，这些都会给双方的有效沟通带来阻碍和困难。如果是那种在用户侧完成详细设计，在外包方仅仅进行编程和测试这种方式的话，沟通方面的困难带来的麻烦可能会少一些。但是，如果是象这个项目一样，外包方根据需求完成分析，设计，编程和测试的所有工作，那么所需要沟通的信息是非常多的。在这种情况下，如果过分迷信文档在沟通中的作用，仅仅依赖文档，甚至依赖非常正式的文档进行交流，我认为它带来的结果可能是灾难性的。主要问题，打个比方来说，就是信息沟通的“带宽”不够，“延迟”严重。
解决这个问题的办法是有两个。一是充分利用现有科技能提供的一切沟通手段，包括电子邮件，电话/电视会议，MSN，Skype等等，使开发人员和需求分析人员能进行“准面对面”的沟通，增加信息沟通的“带宽”和响应及时性。使得即时远隔重洋，开发人员的任何疑问都能得到最及时的解答。同时，虽然开发人员和需求分析人员可能属于不同的公司，但应该不再拘泥于沟通方式的正式性，而如同一个团队，一个办公室里的伙伴那样进行交流。在离岸外报项目中，要做到XP要求的“现场用户”是困难的，但通过现代科技手段，做到虚拟的现场用户也并非不可能。
另一方面，要充分发挥BridgeSE的作用。前面说过，BridgeSE对需求的理解应该达到和写需求说明书的人一样的程度。如果做需求分析的人不能到开发现场向开发人员解释需求（这应该是最理想的安排），那么BridgeSE应该做到这一点。而且BridgeSE应该和开发人员共同工作相当长的时间，以在一定程度上起到一个“现场用户”的作用。
当然，现在在离岸外包领域，比如对日外包，即能克服语言障碍，又有扎实的技术功底的人是非常稀缺的。如果有这样的人，一定会被同时用于几个项目。虽然这可能是一种无奈，但却不是正确的做法。
在离岸外报项目中，同样由于距离因素，频繁地向用户演示开发中的软件，反馈开发进度，也要比国内项目更困难一些。但是，仍然要尽力地按照“短迭代，经常发布”的原则去做。因为有前面所说的沟通方面的困难存在，更需要通过尽早地发布版本和向用户演示来及时发现对需求理解上的偏差。如果等到最后交付日才发现对需求完全理解错误，那麻烦就大了。
通过Internet，要做到这一点其实也并不那么困难。比如，对于基于Web的应用，完全可以在开发侧架设演示系统，让用户远程访问。BridgeSE可以在用户现场做演示，并听取用户的意见。
此文章共有3页 上一页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
