作者 | Lizzie Matusov

譯者 | 平川

策劃 | Tina

想象一下，每隔六個月，你就要和一群全新的工程師組成團隊，從零開始，共同交付一個復雜的產品。你們需要迅速磨合，經歷成型、討論、規范和執行等各個階段，不斷調整流程，以確保最終能夠成功交付。這種頻繁的團隊重組，讓我深刻體會到，驅動卓越工程團隊績效的關鍵，遠不止于技術能力。

在 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/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。