目前国内的从事外包服务的IT企业大部分都是在给日本公司作项目，给一些欧美的公司作IT项目还处在初级起步阶段。

  笔者目前在一家美国公司工作，这几年也为公司的一些IT项目和国内的外包公司合作过，但是总体感觉上并不是太满意。反过来想想，如果我是一名国内IT外包公司的项目经理，现在要承接一些欧美企业的外包项目，又该怎么样避免一些问题，达到双赢的结果呢？

  在选派人员的问题上，在项目团队的技术人员中一定要有一名英语好的技术人员。

  他不一定要是主力研发人员，但是他的英文一定要好，要能用英语很清楚的表达一些技术问题还可以流利的撰写英文文档，比如说写出客户的真实需求，分析设计文档。

  在项目团队中配备这样一名人员是非常必要的。就我所接触的一些外包公司，他们负责招揽项目的人员在这方面都还可以，但是技术人员中几乎就没有这样英文稍好的人员。

  的确，他们的开发水平都还不错，但是欧美企业自己一般都有自己标准的文档模版和要求，而且对这部分要求比较严格。如果一篇技术文档中语法，拼写的错误层出不穷，也会让人感觉此公司整体水平很差。国内的大部分技术人员一般都重视代码的编写而从思想上就轻视或者忽略文档的编写，更不要说写出英文文档。提交出来的文档连拼写检查都不做，语法错误更是层出不穷。有些项目经理或者老总解释说这是因为他们的人员英文水平不高。

  Office软件本身带了拼写检查的功能。只需要多下点功夫仔细检查一下，应该是能够尽可能的防止95%以上的错误的。至于技术人员的说英文的能力，如果的确困难，可以在开会之前列出一个要讨论的问题发给相关的人员或者自己先练习一下，开会后再及时地把自己的理解写出来发给对方来确认。总之，解决这一个问题不是很难的，需要的是认真的态度和从上层领导的重视。

  首先，要很清楚地了解该公司的IT项目管理的流程等等。有必要了解的内容应该包括：

  1）此公司以前有没有和国内的IT企业合作过？如果有，都是属于什么样的项目？以前的项目成功的地方有哪些？不太完美的地方（注意绝对不可以用失败的字眼）有什么？

  2）公司的项目管理流程是怎样的？关键是了解目前的流程是否和软件开发流程一致，如果不一致是存在啥地方的偏差？是否严格的遵守这个流程。在哪个流程上需要特别的注意？

  3）进行服务器或者软件采购的流程是什么？一般的周期有多长？有没有时间上的要求？对于项目会产生的影响有哪些。

  其次，要注意和客户方保持联系。这种联系并不意味着说就是要每天要打一个电话。而是要体现在做项目报告上。不仅每天要写日记，每周要做周报告，每一个月还要写月报告。在每个报告上都要注明：已完成了哪些任务，还有哪些任务是需要明天，下周或者下个月完成的。此阶段有哪些风险，报告中还要包括人员的流动，假期安排等等。对于发现或者预测到的任意的毛病都要及时和客户保持联系。

  第三，项目付款问题。从开始就确定好通过谁来进行项目的收款工作，是和外企的财务部门直接联系还是和对方的项目经理联系，这点要在签订合同的时候就搞清楚。

  第四，态度问题。绝对不可以流露出对对方的技术或者管理上的水准的鄙视，即使你的水平很高而对方的水平的确很低。要保持积极的沟通和配合的态度。

  要仔细了解：为何需要做这一个项目？是否在这一个项目中存在着某些其他因素？项目进行到了什么阶段才决定找外包公司合作？是不是已经有了详细的需求文档后还是仅仅有了一个大概的需求？此项目的优先级别是怎样的？是否是核心业务的项目？

  因为不一定你要接受的项目就是从头开始的项目，有时候恰恰是因为内部没有了资源或进行不下去了，才决定找个外包公司接受这个烫山芋。

  因为是和欧美公司的IT部门打交道而不是和客户方直接联系，最大有可能就是项目的交付时间是IT部门自己制定的时间，而不是用户想要的（事实上，大部分最终用户根本就不确定这一段时间），在没有充分了解所有的需求和项目背景的时候，莫轻易同意这个被要求的项目交付时间。

  因为考虑到报价的问题，有时候客户方只会把项目的一个大概需求介绍给你，这时候常常造成一种错觉，认为这个项目很简单。其实，项目真正复杂的需求还没有暴露出来。一定要在得到需求规格说明书或者需求文档之后再确定项目的交付时间。

  对这些任务时间的分配一定要充分而且要在合同中指出：对于因为客户自己的原因耽误了项目的交付时间，不能作为项目延误的惩罚等等。因为用户有可能恰好就在这个时间内出差，（当然，在一开始制定项目计划的时候他自己也不知道情况有变）。或者用户忙于其他任务，不能把这一个项目的优先级排成第一。因为欧美公司的员工绝不会因为这些项目的原因在周末帮你们加班干活的。

  4）项目经理手里应该有一个任务表格，列出了每个任务的内容，执行人，如果任务被耽误了的原因，特别是对于由客户方延误任务的原因, 这样做的目的也是为便于保护自己。

  5）要格外的注意用户那里测试环境的问题。有时候用户的测试环境和自己的开发环境的配置不太一样。常常是到了用户测试的这一地步进行不下去才发现是由于系统测试环境配置有问题。所以要尽量在项目一开始的时候搞清楚用户那里的测试环境是怎样的。另外，是否测试环境可以允许外包商进行访问。权限的设置等等。

  6）每个项目都可能会发生变化，特别是需求方面的变化。做外包项目，不能盲目的同意用户的需求变动请求，特别是在用户第一次提出这种需求变动的时候。当然从实际考虑，国内的外包公司都是想要和用户建立长期的合作伙伴关系，不能强硬的说肯定不可以，但是也不能让对方感觉所有的需求变动都是无条件的可接受的。所以，当客户第一次提出这种变动的时候，就要明确做出需求变动说明书，指出这种需求的变动对于整体项目进度以及费用方面的影响。得到用户确认签字后才能进行改动。

  7）在做项目需求分析的时候，特别有一点需要指出：就是是否所有要求的数据可以从用户目前的业务系统中得到。如果业务系统中没有这种数据，那么这种需求就是缥缈需求，没办法实现的。

  8）搞清楚客户方的项目参与人员的情况特别是组织架构和权限大小。谁是幕后老板？谁能真正做出决策？对方的项目经理的权限是多少？有的公司项目经理的权限很大，可以调动很多资源并且做出某些决策。但是有的权限很小，需要其他职能经理进行决策。特别是搞清楚谁最后能决定项目验收与否。由于欧美公司一般也是给内部客户进行软件系统的开发，所以一定要和客户方的项目经理确定，最好客户那里也能分配一名人员进行项目的配合。