我参与了一些多元文化项目（编程语言是普遍的，社会规范，而不是更多），看看团队的动态如何跨文化交流总是很有趣。我不是在谈论coding differences，我在谈论在项目开始时跨文化交流的基本规则。良好的团队建设练习，使用小团队与大型团队，隔离功能，使所有开发人员感觉好像他们正在贡献，培养尊重等。
在我们日益多元化的文化产业中，什么有效，什么失败？
答案 0 :(得分：2)
几年前我对此进行了详细调查，并得出以下结论（没有特别的顺序）：
我们看到的外包组织（所有印度人）都拥有非常强大的流程基础。我不知道这是文化还是他们选择自己的方式（可能是两者兼而有之），但我们觉得这可能是一个真正的问题。
他们谈论的是卡内基甜瓜成熟度模型中的五个（谷歌，但基本上这意味着他们已经定义并记录了所有内容，包括当有人放屁时会发生什么），我们通常在1或者左右运行2（大致相当于交叉手指并希望最好）。
我们的流程水平主要是由我们的客户推动的，他们对签署规范没有任何兴趣（有充分的理由和不好），希望了解他们的业务并填补空白的人，并希望改变他们的想法一天三次。尽管许多这些因素激怒了英国的程序员，但我们知道他们永远不会改变。
这可能是我们最关心的问题 - 我们认为我们不会想出一个适用于所有三个团体（客户，英国IT团队和印度外包团队）的流程模型。
首先要做的是 - 弄清楚你的过程是什么，并确定你是否真的认为你可以让它为所有相关方工作。很容易说“我们要做敏捷”，但如果一方在1000英里之外，你怎么能让它工作呢？或者，如果你想要一个坚实的瀑布路线，给你的客户这是真实的吗？
其次，了解团队中根深蒂固的文化差异。
我的经验（我在这里很明显地概括）是来自美国和英国的程序员心甘情愿地（有时候太自愿）质疑权威和假设。要求他们做一些愚蠢的事情，你可能会发现自己被告知你曾经要求他们毫不含糊地做一些愚蠢的事情，然后他们就会告诉你你真正想要的东西。
这不是全球范围内的常态。我与之合作的许多印度开发人员都没有以同样的方式质疑事物。这并不是说他们不那么聪明，他们只是运用他们的智慧来提供你所要求的东西，假设你有充分的理由这样做。
你可以为这些中的任何一个做好/坏（我已经失去了我听过开发人员质疑他们被告知的次数的数量，并说明了事情应该如何，尽管不了解基本知识他们所从事的行业），但重要的是他们不同，他们会发生冲突。
所以答案很可能是你需要感受到所涉及的团队，并在此基础上，选择适合他们的工作方式。
是的，设置视频会议，每次都访问另一个网站（这会产生很大的不同），并且尽可能让人们在早期阶段严格需要时进行讨论，但最重要的是努力了解所涉及的群体并设计一个适用于所有群体的动态 - 在另一个群体上强加一个世界观将无效。