在全球化环境中管理开发流程

引言

根据我的经验，组建地域分散的开发团队时，需要考虑两个主要问题：团队动态和时区。

我还将提出两种处理全球开发团队的替代方案，以引发进一步的讨论。

本文不会涵盖项目流程本身的方法、策略和战略等主题；而是关注作为任何项目核心的人员，以及如何鼓励他们作为一个有凝聚力的单元工作，无论他们的地理位置或时区如何。

本文也不会分析不同地区和国家之间的文化、语言或方言差异。尽管本文的主要焦点是美国/英国之间的关系，但它应该同样适用于任何使用位于不同地理区域的团队开展项目的实例。

当然，英国人和美国人之间存在一些显而易见和刻板的差异，例如工作道德、幽默感、生活环境等，但这些也不在本文件的范围之内。

全球孤立与全球整合

这概括了在开发团队因距离和时间而分离，且主要通过被动沟通模式进行联系时可能出现的所有问题中最困难的部分。它倾向于助长“我们与他们”的态度，例如，代码变得被嫉妒地守护，任何批评都因“他们”提出而受到强烈抵触，并且，也许，被视为“俄亥俄团队”的应用程序被“利兹团队”打开，后者随后找出一大堆理由来建议或进行重大更改，或普遍批评代码，从而疏远了另一个团队。

管理层几乎无能为力来缓解这种情况，原因有二……

1. 如果这是一个合理的回复，那么必须决定接手工作并将其交给发现问题的团队，或者将其退还给编写它的团队并要求重写。无论哪种方式，原始团队都会因此感到被轻视和沮丧——他们被贬低了。
2. 如果结果证明批评无效或微不足道，那么提出批评的团队会因为被认为是做出了糟糕或错误的判断而感到沮丧——他们被贬低了。

这就是“全球孤立”，地域分散的团队，表面上为共同目标努力，却彼此孤立，以不同的、通常是竞争性的团队运作。这可能因各个团队的规模、年龄或经验分布的巨大差异而加剧，尤其是在仅通过电子邮件或电话进行联系的情况下，沟通渠道基本上是匿名的。

如果团队之间没有社交接触，那么一个团队就没有理由对另一个团队产生亲近感。

与此相反的是“全球整合”，即团队之间进行了良好的社交互动，并且名字与面孔对应起来。批评或贬低你认为是朋友和同事的人要困难得多，当你与那个人有个人关系时，你更有可能提供帮助，并且这种帮助会被接受为为了推进项目目标而提出的客观批评。

这必须与一个多少有些平淡的格言相平衡：你不会喜欢你遇到的每一个人，也不是你遇到的每一个人都会喜欢你。然而，你认识这个人并与他们面对面交谈过，与他们一起开过会，甚至可能在下班后一起吃过午餐或喝过酒，即使是在团体场合，也能确保团队之间的竞争成为健康的竞争，这种竞争的基础是在与其他团队合作的情况下成功完成项目，而不是尽管有他们。

实现这一目标的方法很简单——团队成员需要花时间（不必太长）与其他团队在一起。即使每个团队中只有一名成员在一段时间内交换角色，这也能产生相同的效果，因为他们会带着共同的经验和关系。

我见过许多大型项目失败，原因是没有对促成项目的人员给予足够的重视。专注于项目的逻辑、物理和抽象要求，而忽视促成项目的人员，这实在太容易了。

在我参与的至少一个项目中，团队被积极地劝阻不要互动，大量代码被隔离。没有一个开发人员对正在发生的事情有全面的了解，经理们似乎不愿，直到为时已晚，才让我们参与进来。

另一个项目失败了，因为尽管我们有联系，但只允许来自美国城市团队1和英国城市团队2的开发人员旅行（我至今不知道这是为什么）。这最终导致了巨大的不满以及相应的生产力和士气下降，因为我们从未得到一个合理解释说明为什么会这样，或者将采取什么措施来解决这个问题。

员工可能会默默接受任何出现的指令——但这并不意味着他们对此感到满意，而这预示着任何项目的厄运，因为士气下降，生产力也会随之下降。

尽管项目的复杂性或时间表会影响人员选择以及完成这些项目所使用的地点、技术和管理风格，但如果对促成这一切的人员没有给予足够的关注，那么这将是一场灾难即将发生。

仅仅管理项目是不够的，尤其是在区域或全球范围内。必须认识到，实地创建项目的人员；开发人员、业务分析师、测试人员等；也必须融洽相处，成为一个富有创造性和纪律的团队。如果不能从一开始就建立团队精神，这是无法实现的。这可能意味着前期需要投入更多预算来创建和培养这种精神，但这肯定会节省资金并在项目接近关键路径里程碑时带来回报，届时将不得不决定是否停止向无底洞投入资金，或者更糟的是，在这之后，即使需要投入更多资金来纠正，也很难停止这辆火车。

根据我的经验，对于这个问题，我有两种解决方案，它们都非常有效，而且只有在上面提到的一些灾难发生并进行了项目事后分析之后才得以实施。

第一个我之前已经简要讨论过。这涉及到区域间的角色互换，双向进行，持续一段时间。例如，伦敦的 John Smith 与洛杉矶的 John Doe 交换一两周，然后另一个开发人员也这样做，直到每个人都有机会与其他人见面并合作。这样做会使士气高涨，原因有几个，有些比其他的更明显。第一，旅行的机会，即使只是短时间，通常被视为旅行者的福利；第二，这被视为管理层对他们及其能力的隐含信任的衡量。

第二次是我被任命为“全球发展大使”时，是的，我讨厌这个头衔。这意味着最初的四个星期要在纽约推广这个项目，并协助团队选择过程。然后，在项目进行期间，我每月在纽约办公室待一周——幸运的是只持续了六个月。我最初的工作结束后很简单——在办公室里继续开发并做我的日常工作，同时充当地区之间的沟通渠道。这也意味着有一个单一的责任联系点，以确保问题尽可能在当地解决。然而，我没有承担管理角色；我只是一个直接而公正的与管理层沟通的渠道，如果需要的话。

在此之前，我也曾多次从事类似的工作。有一次，尤其是在一家位于伦敦的欧洲银行，我花了几个月时间，每两周在欧洲大陆待两天，成功地将一支最初充满敌意的，由高水平的德国和东欧开发人员组成的团队与一支类似的英国开发人员团队融合在一起（幸运的是，他们都说流利的英语）。

我坚信，无论情况如何处理，跨区域界限管理开发的关键在于首先管理人，并确保有团队精神和良好的士气。同样至关重要的是要进行技能匹配，以便团队在可能的情况下，不会觉得其他团队比他们技能更高或更低，或者受到任何不同的对待。

一个团队

当然，这个问题还有另一种解决方案……简单地说，就是不要拥有全球开发团队。

虽然拥有全球团队的一个明显好处是增加了其本地化知识，用于涵盖不同地区且每个地区在整体结构中都有自己要求的应用程序，但这无论如何都可以获得并应用于项目。

因此，拥有一个单一的开发团队从单一位置开发全球应用程序，在经济、物流和实践上都是有意义的。

第三条道路

最后，从预算角度来看，可以让整个团队异地工作，从而进一步削减成本。

外包——这对于那些直接受到工作威胁的人来说并不受欢迎。然而，根据具体情况，它可以变得有效。外包的一个明显缺点是控制权和技能基础的丧失。

如果项目应用程序预计具有较长的使用寿命，那么你不会希望多年来受制于第三方，同时又没有内部技能基础来执行支持和增强功能。

保持对项目及其代码库的内部控制的愿望，必须与例如将整个开发过程外包给印度所能获得的经济优势进行权衡，因为印度现在拥有很高的熟练度和更低的成本。

因此，如果在开发过程中不需要直接的用户接触，并且你只对团队的开发能力感兴趣，那么这是一个显而易见的答案。

时区

时区问题难以克服，如果过度依赖另一个团队来执行基本的管理任务，可能会导致团队成员之间的不满。例如，德国团队的成员可能需要等待旧金山团队的成员到来，才能解决德国团队无权解决的问题。

提名每个团队的一名成员组成一个管理委员会，每个成员都拥有全球管理权限，并且可以解决问题，而无需求助于远隔千里、时差数小时的团队，这可以解决这个问题。

当然，总会有需要全球响应的问题，但如果这些问题有充分的文档记录，并且预先确定了具体的行动方案，所有团队成员都清楚这一点，那么解决方案就不应该引起问题。

另一个解决方案是建立一个位于特定地点的团队，用于解决问题和管理目的，该团队将涵盖所有团队在其各自环境中工作的时间。

摘要

有多种方法可以管理全球开发，以确保其有效、目标明确、重点突出，并且所有团队都觉得他们在为同一目标努力。

1. 短期调派开发人员，以培养良好关系
2. 采纳“发展大使”方法
3. 放弃全球团队，采用本地团队理念
4. 将整个流程外包，以腾出团队用于其他职责或完全解散团队

此外，还需要考虑时区差异这个棘手的问题，除了上述第1点之外，其他所有方法都有助于解决这个问题。

结论

我确信，处理全球或区域团队动态的方法还有很多，但我希望我已表明，无论如何处理，任何团队最重要的组成部分都是其中的人员以及如何培养和管理他们，以确保团队融合，项目能够按时按预算完成。

请注意，这些观察结果完全基于我过去 30 年左右在各种环境和行业中（但主要是在过去 15 年左右作为新手、开发人员、经理和企业主的 IT 开发和管理实践和执行中）的工作经验，在此期间我曾多次有机会在英国和国外工作和生活。

如果您目前正在规划一个地理位置分散的项目，或者已经开始，我很乐意以咨询的方式与您讨论。详情请联系我：mark at merrens dot com