代码之外：用“社交驱动力”拯救濒临崩溃的顶尖工程团队

想象一下，每隔六个月，你就要和一群全新的工程师组成团队，从零开始，共同交付一个复杂的产品。你们需要迅速磨合，经历成型、讨论、规范和执行等各个阶段，不断调整流程，以确保最终能够成功交付。这种频繁的团队重组，让我深刻体会到，驱动卓越工程团队绩效的关键，远不止于技术能力。

在 Red Hat 的咨询部门工作期间，我亲身经历了无数次这样的团队组建和解散。这让我意识到，在很大程度上，社交动力推动着我们的业绩。随着职业生涯的继续，我意识到，这些社交驱动力对于我们理解工程团队的绩效至关重要。退一步说，社交驱动力会对我们的工作方式产生影响，这其实并不奇怪。我们是人，这意味着，从本质上讲，我们是相当社会化的。社交确实影响着我们看待世界的方式。这些社交驱动力也会影响我们的工作表现，这并不奇怪。

在工程领域之外，我最喜欢的一个例子是《熊家餐馆》。该剧讲述了一家餐厅从休闲餐厅转型为高端餐厅的故事。在最近一季中，其中最著名的一个场景是这家高端餐厅开业的第一个晚上，一切都非常动人。这是一个意义重大的夜晚。在灯光昏暗的环境中，前厅的客人们正在品尝这些美味的高品质菜肴，这真是一次绝佳的体验。

在后厨，厨师们的关系开始紧张起来。他们本应作为一个团队一起工作，他们的工作也很出色，但他们之间的社交关系却有点紧张。随着时间的推移，压力越来越大，事也不断变大。最后，厨师长被锁在了冷库里，队员在外面大声呵斥。然后，他整晚都被锁在了那里。这可不是你想要的团队状态。

其实，这是非常重要的一课，因为如果不了解影响团队的社交驱动力，我们就不知道，在不同情况下，团队会有怎样的表现。举例来说，那些厨师的工作能力令人难以置信，他们正在生产高质量的产品，但由于他们的社会动力，情况很不稳定，这确实会影响餐厅的业绩。这一原则同样适用于工程团队。我可以给你看一张速度与质量的对比图，看完之后你会说，这是一个表现很好的工程团队。左侧是速度，随着时间的推移，速度在稳步提高。

右侧是质量指标，如变更失败率，从中可以看出，团队定期进行部署，对生产和构建的影响很小。这就是我们所说的精英团队。如果我给你看下面这些图，你瞬间就会对这个团队产生不同的看法。这是一支心理安全感不断下降、职业倦怠风险大幅增加的团队。这是一个处于崩溃边缘的团队。如果不改变现状，那么前两张图上的情况是不会持久的。对此，你可能会想，Lizzie，这太棒了，但捕捉和分析这类数据并非易事。

通过定期度量来增强信心

另外，让我来告诉你为什么这很重要。我们从大约 30 家公司的回复中抽取了一个样本，让大家告诉我们，他们多久一次度量社交驱动力，以及他们对团队工作效率的了解是否有信心？你会发现，在对于团队工作效率的了解方面，按季度或按月度量社交驱动力的团队可能更有信心。

虽然不一定就是这样，但这告诉我们，如果不定期对团队中的社交驱动力进行度量，你就不可能对团队的工作效率有信心。在这场演讲中，我将展示什么最重要、如何获取数据，以及从现在开始就可以采取的步骤。

首先，我们将介绍一个名为 TAPPs 的框架，它涵盖了了解工程团队绩效所需的最重要的社会动力。然后，我们将谈谈度量标准。我们将讨论 “谁” 和 “如何”。第三，我们将讨论如何开始。

TAPPs 框架

在讨论这些方面之前，我想先介绍一下情况。你们中很多人可能都遇到过这种情况，所以听起来可能有点熟悉。比方说，有一个软件工程团队，他们正在为一个大型发布而努力。这是一次非常重要的发布，它将为公司带来大量收入，所以压力很大。他们离终点越来越近了。

发布计划已经写好。我们进入了开发的最后阶段，突然有人发现了一个 Bug 。我们不知道这个 Bug 会造成什么影响。我们甚至不知道它的严重性。我们只知道有这样一个 Bug。问题是，那个队员会怎么做？下面我将带大家了解下应该如何考虑这个问题。我将用我所说的 TAPPs 框架来继续讲述这个故事，也就是你可以用来了解工程团队绩效的四大社交驱动力，即信任、自治、目标和心理安全。

信   任

让我们从信任开始。信任就是相信与你共事的人与你站在同一条战线上。它让你知道，与你共事的队员会履行承诺，分享诚实的反馈，并支持彼此的工作。当信任度低或信任度高时，情况会怎样？在信任度低的情况下，发现漏洞的队员会与团队分享他们的发现，但他们不确定团队是否会认真对待。他们会告诉团队，但也会自己去探索、分析和研究，也许会形成自己的结论。

团队的其他成员可能也会这么做。他们会想，还是我自己去搞清楚吧，因为我不确定我是否可以相信我的团队能正确地评估所发生的事情。你刚才做了很多多余的工作，花费了很多的精力。如果 Bug 影响不大，则意味着团队浪费了大量的工作周期，做了同样多的研究得出同样的结论。如果 Bug 很严重，那么所有用在多余工作上的时间原本都可以用来帮助寻找解决方案。我们还只是假设团队相信个人对 Bug 的评估是正确的。

也有可能出现这样的情况，每个人都说：“我不确定我是否相信这是一个 Bug，因为是你分享的”。这种情况并不好。让我们假设一个高信任度的场景。在高信任度情况下，队员会分享他们的发现并召集会议。他们会一起做一些初步的诊断工作，然后分头进行不同的探索、分析和诊断。然后，团队会聚在一起分享了解到的信息。

现在，他们可以相互学习，汇集知识，更快地发现并解决问题。如果不是问题，可能很快就能发现；如果是问题，团队也会迅速团结起来，找到解决方案。信任会带来坦诚的沟通，加速问题的解决，并减少返工。正是因为有了信任，团队才能分头独立工作，然后再聚在一起分享他们的心得体会，因为他们知道，整个团队都是站在同一条战线上的。

关于这一点有哪些研究呢？2019 年，谷歌的一个研究团队询问了三家不同公司的 600 多名开发人员，以便确定哪些因素对他们的工作效率影响最大。在下面这张图中，从 F1 开始到 F10 是预测工程师工作效率的主要因素。黄色突出显示了与他们对团队的信任程度有关的因素，占前 10 个因素的 40%。例如，在我的项目中，人们支持新想法，或者为我的软件编写代码的人能力很强。这些调查结果表明，信任对于提高软件工程师的工作效率至关重要。

信任对团队绩效的影响极为重要。就团队绩效而言，我之前已经分享了如何改善团队协作，这有助于提高团队的工作效率。从产品性能的角度来看，你会看到产品可靠性的提高以及其他下游效应，如部署时间缩短、变更失败率降低。令人难以置信的是，根据 2022 年和 2023 年的 DORA 报告，组织绩效的提高 30% 与高信任文化有关。

自    治

既然我们知道，信任是工程团队绩效的重要驱动力，那我们就来谈谈自治。自治是指软件工程师对自己的工作独立做出决定的能力。整个团队有明确一致的目标和边界。在团队内部，队员们会觉得，自己有能力搞清楚什么是合理的、如何确定工作的优先顺序、如何独立地实现团队目标以及如何找到合适的方法。让我们看下这里的故事。在自治水平低的情况下，团队经常受到流程或权限的限制，这影响了他们自己快速分流和判断 Bug 严重性的能力。

新来的工程师或发现这个漏洞的工程师可能对问题的严重性有一些想法，但却需要将其转到正式渠道，而不是独立采取初步措施来探索问题的严重性及可能造成的影响。也就是说，在确定这个问题的重要性方面会有延迟。如果不是什么大问题，则只会导致一点点滞后。如果是个大问题，就有可能要排队等待正式流程的检查，而工程师本可以开始了解影响是什么，并组织开展内容更丰富的讨论。让我们来看看高度自治的情况。

在高度自治的情况下，发现 Bug 的队员会认为，这是一个需要研究的重要问题，并了解其潜在的影响。他们可能会优先考虑这个问题，而不是正在做的另一项任务，因为他们认为这可能会产生很大的影响。结果是这样的，如果这不是个问题，那么他们就只是拯救了团队，使他们不至于为一些无关紧要的事情而焦头烂额。如果这是个大问题，那么他们就会带着更多关于影响、严重性以及下一步该怎么做的信息来发起讨论，这样团队就能更快地行动起来。

自治赋予工程师更快解决问题的能力。作为工程师，我们最强的技能之一就是解决问题的能力。实际上，自治是我们把工作做到最好的基础。让我们来看看相关的研究。首先，我想回顾一下我们之前谈到的那项研究。你还记得我告诉过你，十大因素中有 40% 与信任有关吗？另外 30% 与自治有关。比如，我的工作允许我决定用什么方法完成工作，或者，我的工作允许我在开展工作时运用个人判断。我们还可以看看另一项很棒的研究。

2017 年，对于如何成为一名优秀的软件工程师经理，研究人员请软件工程师和经理们对相关因素进行了识别和排名。左边从上到下显示了排名靠前的答案。对于每一项，上方的波浪线显示了工程师的回答分布，而下方的波浪线显示了经理的回答分布。然后，粗横线显示的是四分位距。垂直线显示的是平均值。不过，最重要的一点是，自治排在第三位。

更有趣的是，工程师和经理们观点高度一致，都认为自治非常重要。基本上，工程师和他们的经理都认为，自治是工程团队绩效的基础。结果不言自明。自治使工程团队有能力加强协作，改善交付周期。事实上，高绩效团队拥有的自治水平可能是低绩效团队的两倍。正如我们在上面的故事中听到的那样，自治行为还能加快团队前进的步伐。

与自治水平低的团队相比，自治水平高的团队实现高频部署和短期交付的可能性要高出 1.4 倍。最有趣的也许是，当团队之间有共同的目标，而队员可以选择他们的方式与目标保持一致时，这实际上就实现了战略一致性。你给了人们这样的空间：这就是我们的目标，你可以用自己的方式帮助我们实现目标。这一点非常重要，可以帮助组织向同一年度目标看齐。

目   标

我们已经谈了自治。现在我们来谈谈目标。我相信大家都感受过这样的反差：从一个朝九晚五、打卡上下班的地方，到一个让你觉得自己所做的事情非常重要的团队和公司。这种感觉就是目标感。它是指对团队工作为何重要以及如何与更广泛的组织目标保持一致有一个清晰的共识。让我们看看目标感不强会怎样。你们都看过《上班一条虫》吧。我认为这是一个非常好的团队目标感低的例子。在这个世界里，工程师发现了一个 Bug，但他们无动于衷。

更糟糕的是，他们会很恼火，因为他们会想：“我今晚得加班了，我一开始就不想来这”。他们可能会沟通这个问题，但不会有同样的紧迫感。团队可能也不会找到最理想的解决方案来解决这个问题，因为坦率地说，如果团队的目标感不强，那么他们就不会真正关心如何为用户找到最好的结果。从我的描述中，你就可以看到产品质量是如何受到影响的。

当一个团队非常关注其工作影响时，他们就会确保其工作不言自明。在目标感很强的环境中，工程师和团队会迅速团结起来，最大限度地减少对项目的影响，使团队可以向着最后期限继续前进。他们会想出创造性的解决方案，尽量减少对最终用户的影响，因为他们真正关心的是如何为客户提供服务。他们会详尽地报告、提出明确的主张并有效地解决问题，这同样是因为他们关心客户。

目标很重要，因为它使工程师的工作与他们所服务的客户保持一致。实际上，关于这一点，有一些非常有趣的研究。2024 年的 DORA 报告发现，在高度以用户为中心的环境下，交付吞吐量与产品性能并不相关。我们来看看，这究竟意味着什么。首先，我曾多次谈及 DORA 报告，但我发现自己并没有把它的内涵搞清楚。

DORA 报告是谷歌 DevOps 研究评估小组开展的一项研究，他们从全球 3 万多名工程领导者那里收集数据，然后利用这些数据了解高绩效工程团队的驱动力和动机。今年，他们发现，实际上，在以用户为中心的团队中，交付吞吐量或功能交付速度与产品性能并不相关。也就是说，即使你的交付吞吐量只有一半，也不一定意味着你的产品会更好，只要你以用户为中心。

在直觉上，这是说不通的。因为我们知道，向客户快速提供功能通常有助于打造出更好的产品。为什么会出现这样的情况呢？用研究人员的话说，开发出来的软件与它所处的世界不会脱节。研究人员认为，这是因为当一个团队对自己的工作和所服务的用户产生使命感时，他们就会始终朝着提供价值的正确方向前进。目标很重要。它能让团队表现得更好。让他们对工作充满激情。这既能提高他们的协作能力，又能提高他们的工作满意度。

这样才能提高产品的稳定性、可靠性和性能。从组织的角度来看，这也是保持组织凝聚力和减少人员流失的关键所在。团队希望开发他们认为真正重要的产品。

心理安全

最后，我想谈谈心理安全。我想谈谈它是什么，也想谈谈它不是什么，因为人们经常说这个词，我想确保我们清楚它的含义。什么是心理安全？它是一种信念，即队员可以承担人际交往中的风险，而不必担心负面影响。比如大胆发言、提问、承认错误。在安全、舒适的环境中，团队成员才能够这样做。这里有一些非常重要的细微差别，我只想确保我们有一个正确的理解。让我们来谈谈它不是什么。

Amy Edmondson 博士是哈佛大学的教授，是她让这个词成了一个流行词。她曾经说过，这个词给人一种温馨的感觉，我们都会对彼此好。这不是它的真正含义。它的真谛在于坦诚。它是关于坦率、冒险，以及愿意说 “我搞砸了”。当人们说出 “心理安全就是舒适” 或者 “这是一个软弱的团队” 之类的话时，这是团队中常见的一种非常错误的理解。让我来看一下它在团队中的表现。我会继续我们的故事，这样你就能真正地看到，它是如何发挥作用的。

我希望你们考虑的另一个重要因素是责任感，因为心理安全的表现方式取决于团队的责任感有多大。比方说，我们有一个团队，这个团队的心理安全感和责任感都很低。这就是我们所说的冷漠区。犯了错也不会有什么影响。团队没有获得真正的支持。实际上，这样一来，人们很难关心自己的工作，因为他们觉得自己有点脱离工作。老实说，这听起来很像目标感不强。

实际上，如果你的心理安全感和责任感都低，那么你的目标感很可能也低。如果发现了 Bug，可能也不会急于处理，也没有多大的责任感要这样做。假设这个团队的责任感很强，但心理安全感仍然很低。这就是我们所说的焦虑区。正是这种对羞辱、惩罚或指责的恐惧，让团队无法有效地开展工作。如果你曾经遇到过这样的情况：你想提出某件事，但又不想让自己听起来很愚蠢，或者你想提到发现的一个 Bug，但又不想揭露你的队友，让他们因此惹上麻烦，这听起来很像焦虑区。

就我们团队而言，发现问题的人可能会试图自己解决它，把它清理干净，不让其他人看到，这主要是因为他们不想与这个 Bug 联系在一起。如果他们提出来，他们会担心那会演变成一场指责游戏。他们也不希望给造成 Bug 的人惹上麻烦。我们非常关注是谁造成的，为什么会导致这个问题，而不是我们如何真正地解决这个问题？这是一个巨大的沟通失败，让团队无法专注于重要的事情，即在发布之前解决这个 Bug。

让我们谈谈更高水平的心理安全感。比方说，我们的心理安全感很高，但我们的责任感很低。人们在谈论心理安全时，往往会想到这一点，但却用错了语境。在这种情况下，团队确实合作得很好。他们感到舒适。他们知道自己可以承担风险，可以直言不讳，但他们并不会因此而被问责。他们在沟通这个问题时会感到很自在。他们会诊断影响，并找到解决方案，但团队并没有那种紧迫感。

好消息是，团队确实喜欢一起工作，这总是好的。他们知道可以冒险。坏消息是他们觉得没有理由。他们不会被迫承担任何风险。当你同时拥有高度的责任感和心理安全感时，真正的奇迹就会发生。团队行动迅速。他们把问题的重点放在了做什么和如何解决上，而不是回顾是谁做的，或者为什么要这么做。在我们的故事中，这样的团队会迅速确定影响，提出解决方案，并且在此过程中绝不会指责任何个人。

团队有机会从他们的经验中汲取前进的力量，从学到的教训中汲取前进的动力，在下一次做得更好。这些团队行动迅速，表现出色，并能学到很多东西。心理安全是承担适当的风险、快速学习、迭代和构建最具创新性的解决方案背后的驱动力。

在这里，我想谈谈一项极具影响力的研究，也是我最喜欢的一项关于工作场所的研究，从中我们可以看到，心理安全到底有多么重要。2012 年，谷歌努力探索了什么是最高效的工程团队？他们调查了谷歌内部的约 180 个团队，希望可以了解为什么有些团队的表现总是比其他团队好。他们研究了团队规模、人员构成、管理风格、个人技能组合等诸多因素。

有一段时间，这只是些噪音，直到他们开始思考，如果我们度量团队内部发生的这些变化，并将其作为一个数据点呢？突然间，他们开始考虑相关性。实际上，他们发现，这些个人因素，如团队构成、个人技能组合、管理风格等，远不如团队的合作方式重要。他们发现了五个关键因素，从上到下，按重要性排序。它们为成功团队奠定了基础。

最重要的是心理安全，其次是可靠性、结构和清晰度、意义和影响力。心理安全是如此重要，以至于他们几乎是立即成立了工作小组来研究，如何让每个团队都表现出更高的心理安全感，从而提高他们的绩效？这里还有一个非常好的地方，你会看到，我们在 TAPPs 框架中谈到的一些事项，谷歌的 Aristotle 项目也涵盖了。

2019 年的 DORA 报告也用非常棒的方式展示了心理安全的价值 。他们评估了哪些因素有助于提高组织绩效和生产力。他们发现，心理安全是唯一一个对两者都有实际影响的维度。解决心理安全问题不仅能提高团队的生产力，还能更广泛地提高组织的绩效。这种影响是深远的。与缺乏心理安全感的团队相比，心理安全感较高的团队其工作效率要高出 20%。

在产品方面，心理安全与更好的产品性能息息相关，因为团队知道，失败不会威胁到自己，所以他们可以放心地冒险、实验并尝试新事物。所有这些好处，不仅能大大提升组织的整体绩效，还能留住人才。人们都希望在可以承担风险、尝试新事物的团队中工作，也喜欢在一个支持他们的环境中工作。

度量：谁来度量以及如何度量

现在，我们已经介绍了 TAPPs 框架的各个层面。我想花一点时间谈谈度量，谁来度量和如何度量。然后，我们再谈一谈，如何将其应用到我们的团队中。我们先来谈谈谁参与了这个过程。在工程组织中，你能想到的群体当然是团队中的工程师、管理层，以及最高管理层。你需要团队贡献数据，因为他们是实地体验和贡献社会动力的人。

当然，在执行这些大型项目时，让管理层和高管了解情况对于获得他们的支持非常重要。在这里，我想重点谈谈一个经常被忽视的关键问题，也是我们应该讨论的问题。团队应该参与查看和分析数据。对你们中的一些人来说，这似乎显而易见，但实际上，现状并非如此。

作为工程师，你可能有过这样的经历：有人发给你一份调查问卷让你填，你花了很多时间，然后完成并提交了问卷，至于后续发生了什么，你没有听到任何消息。你们中的某些人是不是曾经有过这样的经历？是的，这种情况经常发生。事实证明，绝大多数研究都表明，让工程团队看到数据并参与数据分析，才会给团队带来实际的变化。为什么会这样呢？有两大原因。第一，要贡献数据，而且团队必须信任数据。

就社交驱动力而言，获取这些数据的最有效的方法就是询问那些每天都在经历这些的工程师。如果工程师不相信这些数据真的会用来改善他们的团队，那他们为什么还要花时间去做呢？更糟糕的是，如果他们认为这些数据可能会被用于对其团队不利的方面，那么他们肯定不会做出真实、诚实的回答。在《加速》一书中，Nicole Forsgren 和 Gene Kim 也强调了这一点。第二个原因是，建立一致性才能取得成果。

如果团队能够从自己的角度出发，就团队应该采取的行动达成共识，那么对于这项工作，他们就会有更强的主人翁意识。当他们对变革有更强的主人翁意识时，这些变革的执行就会加快。我们刚才已经谈了，自治可以通过赋予团队独立性的方式来达成战略一致性，让他们以他们认为最合适的方式来实现组织目标。同样，这也适用于更广泛地推动绩效改进。在社交驱动力和工作方式上，工程团队的一致性越好，结果就会越好。

既然我们知道谁应该参与进来，那我们就来谈谈如何实际地度量这些数据。在我的工作中，我与成千上万的工程负责人交谈过，有时我会问他们这样的问题：你们今天是如何度量这些社交驱动力的？我经常得到的一个答案是，我们通过一对一的方式来度量。如果你们有一对一的经验，我敢说，至少 80% 的人都有，那么你们可能知道这些议程可能会如何进行。

比方说，在一次时长 30 分钟的讨论中，你们要谈谈即将到来的带薪假期。接下来的项目怎么样？有什么挑战吗？有没有什么障碍？第四季度有哪些优先事项？我们要进行绩效和职业生涯方面的谈话，以便可以为明年做好准备。我们忘了谈团队的社交驱动力，我们要确保谈话覆盖这一点。我不知道你们的一对一谈话会持续多长时间，但要在 30 分钟内讲这么多内容，实在是太紧张了。这是个问题，因为这意味着时间太仓促，团队可能没有时间真正地思考影响他们的社交驱动力。

更糟糕的是，这些数据不是结构化的，而且有偏见。之所以说它是非结构化的，是因为你可能不会听人们做同类比较。你会听到的是：这个故事是关于信任如何影响了我的工程团队。作为管理者，这些故事非常重要，但在严重性和影响方面，很难将一个故事与另一个故事进行比较理解。

更重要的是，我们要求队员与他人交换有关社交驱动力的信息。你必须先假设存在一定程度的社交驱动力才能进行这样的对话。回想一下心理安全问题，如果一个团队的心理安全水平很低，那么在提出一些这样的情况时，队员们就会感到犹豫不决，因为他们不想给其他队友带来麻烦，或者他们不想让自己看起来像是提出这些问题并导致团队出现细微分歧的人。

在诚实搜集信息的过程中，实际上，一对一策略并不是获取这些数据的有效方法。度量工程团队社交驱动力的最佳方式是匿名综合调查。我们听到的最大的批评意见是，在进行调查时，合理地设置度量内容并得到恰当的响应非常困难。我知道。我们来谈谈如何才能真正地做到这一点。要设计好一份调查，你需要包含一些要素。我将以 TAPPs 四个社会维度之一的信任为例。

首先，你需要有一个明确的需要研究的问题。实际上，这个问题来自我们讨论过的一篇研究论文。因此，它是由微软研究人员在他们的一项生产力和绩效研究中设计的。实际上，我会分享一个链接，这样你们就可以获得所有的 TAPPs 问题，也就是你们想在团队中提出的问题，这样你们就不用担心如何设计问题了。我要指出的一点是，这是一个单桶问题。也就是说，它只问一件事，这使得它很清晰，很容易映射到原始维度。

其次是调查量表。你需要的是一致性。在这里，我们使用的是李克特量表（Likert scale），即从 1 到 5，从非常不同意到非常同意。这很容易理解。它为离群答案创造了空间。最重要的是，你可以开始对这些数据进行统计分析，看看平均值或范围是如何随时间变化的。

最后，也许也是最重要的一点是，你希望将调查设计成匿名的，并且随着时间的推移将回复汇总到团队层面。本质上，社交维度是关于队员之间的互动，因此，度量的核心单位应该是团队，而不是回复的个人。为了确保能够做到这一点并保持高度信任的环境，你需要对这些数据进行匿名处理，然后再汇总到团队层面。

入门指南

我们已经知道了社交维度是什么。现在，我们就可以了解怎么度量它们最好。接下来，我们谈一谈，要开始捕捉这些数据，你们的团队可以做些什么。开始这项工作，需要关注三个关键步骤。首先，要建立一个流程，让你能够长期、比较可靠地捕捉这些数据。其次，要怀着好奇心定期查看数据。我们将讨论这意味着什么。第三，要推动行动和改进，创造一个从度量到改进的持续循环。

首先，要长期可靠地度量 TAPPs，就需要建立一个流程。也就是说，要定期收集数据，从而分析数据随时间的变化情况。从 “一对一” 入手没错，但转向一个基于调查的体系，尤其是匿名和汇总调查，其好处是更容易建立一个流程，让你能够看到数据随时间推移的变化情况。你可以查看回复范围之类的东西。你可以查看平均值。你可以查看图表随时间变化的情况。

出乎意料地，你能在更长的时间跨度内更好地了解团队的心理安全状况了。另外，我建议，对于这些维度，至少每季度度量一次。如果你与你的工程团队之间建立了“度量改进”循环和良好的信任关系，那么实际上，按月采集这些数据就是你最好的选择，因为对于需要处理的变化，以及可能需要你发起讨论的古怪的离群值，它让你可以捕捉到相关的早期信号。

我们已经讨论了如何设置这一流程，下面我们谈谈如何带着好奇心去审查这些数据。对此，我有几个小建议。当你分析这些数据时，要考虑单个快照随时间变化的情况。同样，如果出现极大的波动，你会想知道发生了什么。一般来说，你想看看事情是如何随着时间的推移而变化的，因为这能让你更好地了解团队在日常工作中的实际运作情况以及影响他们的社交驱动力，而不是星期二发生的某个事情。

你要做的第二件事就是问自己，为什么？作为团队，我们应该了解发生了什么。你看到了一个大幅的飙升，那可能是在一次团队非现场活动之后。在那次活动中，团队真正地感觉到他们走到了一起，真正地理解了彼此。或者，你看到事情突然急转直下，你就会想，这与我们的截止日期被提前六周、压力骤增有关。问自己这些问题，想想为什么。第三，我之前提到过这一点，不要过度关注单个数据点，尤其是在查看范围时。

你真正要思考的是，随着时间的推移，平均值是如何变化的，或者团队的回复是如何变化的？而不是一次过度关注单个数据点。现在，团队正在收集数据并定期审查，你可以利用这些数据推动有意义的改进。例如，如果你发现团队的目标感有持续下降的趋势，就可以考虑让团队更贴近他们的最终用户。也许可以让他们听一些帮助客户取得成功的对话，或者让产品团队来参加一个午餐学习会，让他们谈谈上次构建的功能以及它对用户的实际影响。

然后，这些行动将有助于改变团队的目标感。如果你已经建立起了某种形式的持续度量，那么随着时间的推移，你就能看到这些变化。现在，你就可以创建一个持续收集数据、分析数据并采取适当行动的流程，从中你还可以看出情况的变化。

要点总结

首先，使用 TAPPs 框架获取工程团队绩效背后的主要社交驱动力，即信任、自治、目标和心理安全。为什么这四点很重要？信任是开放沟通、加速问题解决和减少返工的关键。自治使工程师能够更快地做出决定并解决问题。目标使工程师的工作与他们所服务的客户相一致。心理安全有助于承担风险、坦诚交流和提高创新能力。这就是 TAPPs 框架。如何运转它？

为了达到最佳效果，工程师应该了解数据收集和分析情况。当然，你要确保管理层和高管也参与其中，不要忘了这一点。度量社交驱动力的最佳方式是匿名汇总调查。一对一调查是一个很好的开始，但如果真想启动从信息到行动再到度量的循环，你就需要使用一种像问卷调查这样的持续度量技术。

从今天就开始，团队应建立一个一致的流程，定期审查数据。当然，还要带着好奇心，推动行动和改进。当我们知道影响团队的首要社交驱动力时，就能创建一种更快乐、更高效的工程文化。

原文链接：

https://www.infoq.com/presentations/trust-psychological-safety/