亚马逊AWS官方博客
挑战有关如何构建卓越云中心的传统智慧 | AWS 云企业战略博客
我们可以从百老汇的成功学到哪些有关构建高效团队的经验
在企业的云迁移过程中，其中一个基本步骤便是建立卓越云中心 (CCoE)。CCoE 是一个多学科团队，旨在实现云采用所需的监管、最佳实践、培训和架构，以便为大型企业提供予以遵循的可重复模式。这点不言而喻，但是在努力创建新的基于云的预置和交付流程时，高效的 CCoE 需要稳健的执行技能和创造力，这些流程延续其当前的运营模式的官僚作风和限制。
鉴于此功能的重要性，我们也就能够理解，为何企业常常会针对理想的卓越云中心组成和功能寻求指导。构建 CCoE 团队的方法多种多样，在此我推荐两种我认为是最常用的方法。第一种是建立一个全新的团队，其中团队成员来自与建立新的云运营模式有关的各组成功能领域，并且拥有广泛的技能。使用此方法构建的 CCoE 通常包括来自基础架构运营、PMO、企业架构、应用开发、信息安全、采购和 QA 的代表。
第二种方法是利用现有的高绩效项目团队并将其重新部署到 CCoE。不同于第一种方法，该方法可以快速建立 CCoE。在该方法中，先借助已知晓如何交付结果的 A 团队，随后即可快速构建团队。第二种方法更常用于已建立跨职能团队的企业，以便进行 Scrum 或敏捷开发。
这两种方法的逻辑都是可接受的，并且我掌握了不少有关它们可在企业中有效执行的实例证据；不过有研究表明，诸如此类我们通常用于组建团队的方式可能会削弱我们对 CCoE 和其他计划的结果期望。自多年前进行这项研究以来，我一直在利用其结论来构建具有成功结果的创新型团队（包括云团队）。奇怪的是，这项研究的内容是为何百老汇音乐剧能在上个世纪的大部分时间不断获得成功，以及如何将其更广泛地应用于组织设计。
研究人员 Brian Uzzi 和 Jarett Spiro 研究了 1945 年至 1989 年间，百老汇制作的近五百部音乐剧的合作者（作曲家、导演、词作者、制片人）的关系 (a)。借助过往工作关系密度的比率 (Q)，研究人员发现，若音乐剧合作者之间的现有工作关系比率较低（低 Q），则不太可能获得商业或关键成功。可能这并不令人惊讶，但是 Uzzi 和 Spiro 还发现所谓具有极强连接性的“A 团队”或者曾在其他音乐剧有过合作（高 Q）亦非良好的成功指标。事实证明，拥有新旧关系（中 Q）的百老汇团队获得票房成功的可能性是其三倍。简而言之，他们发现大多数获得成功的音乐剧，其团队成员既包括过去曾有过良好合作关系且知道如何推出顶级制作的人，还包括可源源不断提供新想法的新人。
如果我们将这些发现应用于我之前所述的典型 CCoE 模型，那么它们可能会遇到哪些挑战呢？
若采用第一种方法构建 CCoE，则我们构建的云团队可结合所需的所有功能领域并且具有独特的视角和技能。但是这些以再现为主的团队通常具有较低的 Q 值，缺乏一起工作的经验，并且可能需要大量的反复试验方能交付结果。我发现，这些团队往往难以提前获得成功，而且他们还需要更多的协调，而这并不适用于大多数希望通过云实现的更精简的运营模式的企业。
“A 团队”CCoE 方法具有较高的 Q 值，虽然他们可能已有了可快速交付结果的工作模式，但他们目前的状态、地位和过去的成功都是基于优化甚至操纵旧有工作方式而获得的。他们可开发一个新的基于云的基础设施预置流程，将交付时间从八周减少到四周。这听起来非常不错，但为什么不是四天，甚至四个小时呢？ 这些团队往往大力投入于其当前的工作模式和关系，以致于难以进行创新。
早在 2012 年需要我们决定应由谁来领导 Edmunds 的第一个云团队时，我们就已知晓这些发现，我们的目标是创建一个拥有各种关系的新团队，以便提供全新想法和运营效率。我们的基础设施工程团队拥有累累成就，包括一个带有基于 Chef 的基础设施即代码自动预置平台的私有云。从很多方面来看，他们都是领导 CCoE 工作的最佳团队。
但是，我们的期望不仅仅是更快地预置服务器。我们希望能够改进我们在迁移到云时构建和部署应用程序的方式。鉴于这些更高的期望，以及知晓要获得成功，团队必须兼具执行能力与创新思维，因为我们必须要深入思考应如何配备 CCoE 的人员。
最终决定是，不依惯例行事，将我们的基础设施工程负责人和自动化测试团队的高级成员进行搭配。在我于 AWS 工作期间，我看到过不少客户的 CCoE 组织结构图，并且我不记得曾经看到过在 CCoE 中担任领导主角的 SDET（测试中的软件开发工程师）。但它符合我们的目标。虽然基础设施领导为集团带来了系统自动化经验，但 SDET 比公司中的任何人都更了解我们的应用程序。了解哪些应用程序架构完善、有噪音或者依赖关系较为脆弱，则合并后的团队可以快速完成数百个本地应用程序的映射，并开发加速的云采用计划，以及应用程序的支持工具和流程迁移。2016 年，Edmunds 成功迁移到云并关闭了其最后一个数据中心。
在开始新的计划时，无论是面向客户的产品开发还是面向后端技术团队，我均持续考量了团队的关系密度。我使用了一组简单的标准来评估团队组成：
- 预期的核心可交付成果是什么，以及领导者或团队成员分享了哪些类似执行的经验？ 要确保执行与交付不会存在任何问题，应该有足够的旧有工作关系。
- 我们想要实现的目标有哪些新鲜或不同之处，以及我们可以向谁寻求帮助，以获得有关这一挑战的不同看法？
这并不会产生无张力的环境。事实上，我们鼓励具有创造性张力的环境，以便产生超越阶段改变的结果。另外，我们并不只是随机地搭配人员，然后期待魔法发生。相反，我们会赋予团队相关执行能力，希望能减少通常与新团队相关的“形成”税，因为其会延长交付结果的时间。
企业通常会建立一个 CCoE 来引领他们的云计算，期望提高效率，增强可靠性以及缩短交付时间。重要的是，他们组建的 CCoE 团队在实现这些目标所需的工作关系、运营效率和创新思维之间须保持适当的平衡。
新年快乐！
Philip Potloff
AWS 企业战略负责人
@philippotloff
LinkedIn
有关上文提及的 Brian Uzzi 和 Jarrett Spiro 研究的完整内容，请参阅：Collaboration and Creativity: The Small World Problem
(a) Uzzi, Brian, and Jarrett Spiro.“Collaboration and Creativity: The Small World Problem.” American Journal of Sociology, vol. 111, no. 2, 2005, pp. 447–504. JSTOR, JSTOR, www.jstor.org/stable/10.1086/432782.