关于软件开发 

     在实施企业范围的解决方案过程中的某些时候，必须进行差异分析（gap analysis）。 差异分析用于确定软件什么地方不能完全符合企业的业务需求并寻找替代方法。 请注意，我们指的是差距（gap），而非空白或裂痕（chasm）。 替代方法可以是程序上的修改或软件上的小改动。 无论何种情况，全面理解要做的事情，这一点十分重要。

     然而，更为重要的是，在需要对软件进行修改的时候，让这种理解通过三个环节进行完整的传达。 首先，美国客户必须将他们的需求传达给离岸企业位于美国的咨询师。 然后，这些咨询师又要恰如其分地将规范要求转达给进行软件修改的离岸开发中心。 还记得吗？有这么一件关于转述出错的趣闻：第一个人对第二个人说“约翰和玛丽互相深爱，他们预备明年结婚”， 第二人和第三个人转述时，却变成了“约翰和玛丽认为他们现在还互相爱慕，但是想等到明年看看是否还是如此相爱”， 第三个人的理解却是“约翰和玛丽互相喜欢对方，但他们认为这种激情到了明年就会逐渐冷却”。 因此，将概念上的要求翻译成具体的规范和编程也存在同样的沟通问题。

     当软件开发发生这种情况而未被及时发现，那么其后果就是客户不满、销售损失和无休止的相互指责。 如果及时发现了这种情况，那么人们就得不断重复那三个环节的沟通流程。 后果是处理时间延长，目标完工日期受到影响，最终用户失望。 翻译和转述过程中的信息丢失现象不仅限于口头沟通时的误解。 不能全面了解技术方面的要领同样也是灾难性的。 例如，如果不知道企业需要一个独立的服务器专门用于报告，当客户需要同时打印发票和处理仓库拣货单的时候，可能导致企业解决方案崩溃。

     软件开发可能引发混乱的另一处地方是用户文档，包括用户手册和屏幕界面。 这两种形式都各有其负面影响。 比如，Tender（投标）的意思和bid（投标）一样，batch（批次）和lot（批次）同义，day books（日记账）指的是sub-legers（分类账）。 用户必须依靠自己克服这些术语差异的障碍。 但这还不是问题所在。 用户将开始质疑离岸的软件开发者是否真正明瞭他们的需求。 而一旦人们开始产生怀疑，实施团队就不得不付出更多努力来重建人们对开发者和软件的信心。 既然有些工具能直接在屏幕上改变这些误解，难道您还需要等到每次发行新版本的时候再作修改吗？ 您的预算中是否考虑到这些费用？

     软件开发过程中的误解会造成太多的撤销（undo）和重做（redo）操作，整体项目实施的延误和用户群中受挫感和怀疑情绪蔓延。 所有这些，对于公司而言，都是真实的和无形的金钱损失。 您该怎么办？

     关于软件修改，应该作为合同义务并且要求书面形式的概念设计。 概念设计其实不难，并不需要核物理博士才能理解它。 熟悉相关领域的最终用户，应能毫无困难地阅读概念设计文件，只要这些文件中没有3个字母的缩略语和其他IT相关的晦涩词语。 不能将概念设计文件束之高阁，必须坚持直到人们完全理解数据和报告的inflow和outflow。

     作为概念设计的最终验证，应该由离岸企业位于美国的咨询师来作概念设计的预演，以确认客户需求得到全面理解。 因为该咨询师要负责与这个链条上的第三个环节，即软件开发者，进行沟通。 假如概念设计流程没有得到完整的执行，那么您所期望的节省只能是空中楼阁。

     关于屏幕界面，最好能将其改变为本公司的内部语言。 但是，这么做的成本可能会太高，因此没有必要。 不过离岸咨询师应该至少做到，帮助用户做好准备，以度过最初的混乱期。