我非常幸運，到目前為止，我在職業(yè)生涯中已經直接與幾十個（甚至是幾百個）開發(fā)人員合作過。我曾在一些不健康的團隊工作過：在那些團隊里，人們會感到害怕，出于對職位的擔憂，他們會把自己的底牌捂得很緊，不讓其他人知道自己的計劃或意圖；我也在功能失調的團隊工作過，那些團隊由于工作優(yōu)先級不明確而搖擺不定，或者協(xié)調成本太高而沒有人愿意干活，許多天甚至數(shù)周的開發(fā)時間被浪費掉，團隊成了一個個體的集合，而不再是一個工作單元。但幸運的是，我也曾在一些非常優(yōu)秀的團隊工作過。當我身處這些優(yōu)秀團隊的時候，我每天去上班時都很興奮，對于那些比我年長的人，我也不怕公開提出反對意見，因為我認為自己的聲音和工作很有影響力。

在這篇文章中，我將試著記錄下，我所共事過的表現(xiàn)最好的團隊所具有的特質和習慣。

本文最初發(fā)布于 Denise Yu 的個人博客，經原作者授權由 InfoQ 中文站翻譯并分享。

心理安全這個概念被提出來已經有一段時間了，所以我不打算花太多時間來解釋它。如果你以前沒有看過這個概念，請先閱讀這篇文章（https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/）。

軟件團隊由真實的人組成，他們在無形的社會和政治結構中生活和工作，他們從出生起就被社會化，變得更加自信，更加謙恭，更加直言不諱，更加禮貌，更加好爭論，更善于安撫，等等。顯然，這都是陳詞濫調了，我說這些是為了證明，心理安全不僅指的是招聘一些顧問來開展員工培訓、告訴大家這個概念意味著什么：建立真正的心理安全感需要領導者和管理者評估人與人之間交往的所有無形的社會規(guī)則，并理解這些規(guī)則如何影響一個人參與團隊討論、貢獻團隊動力的能力。簡而言之：社交特權很重要。否則，當一些微不足道的小事情開始侵蝕團隊凝聚力的時候，不要感到驚訝：攻擊性的言語或小動作、刻板印象威脅、將幸存者偏差變成成就高效團隊成員的信條。

根據我的觀察，具有高度心理安全感的軟件團隊會有以下某些行為：

• 定期回顧，在“什么進展不順利？”這一欄里列出適當數(shù)量的事項。那里不應該總是陽光和彩虹。那會讓我懷疑回顧中是不是沒有提出并討論什么難題。健康的團隊應該能夠公開地反省并自我批評，因為每個人都明白，建設性的反饋是為了不斷改進。

• 個人不會在一個問題上花很多時間。他們會有一個或明或暗的“奮斗時間窗”，在這個時間之后，他們會向同伴尋求幫助，他們知道，自己不會因此而得到負面評價。

• 個人從看得見的輸出中分離出他們對團隊的價值。我見過這樣的情況，人們對自己的代碼后來被刪除或重構感到沮喪。但在健康的團隊中，大家接受這樣一個事實：改進是增量的、漸進的，貢獻是對團隊整體結果的貢獻，而不是對特定輸出（如代碼行數(shù)）的貢獻，表現(xiàn)出來就是“這是我們交付的”，而不是“這是我交付的”。此外，具有高度心理安全感的團隊可以討論價值的含義，以及價值為什么不僅僅是幾行代碼。

• 帶薪休假時間和病假時間往往會更長，這很有趣。我認為，這是他們的信念的一種體現(xiàn)，即團隊的其他成員可以在他們不在的情況下繼續(xù)做出正確的決策，因為他們之間已經進行了足夠多的對話，這使得整個團隊都認為，他們在產品和技術決策上非常一致。但我不太確定這其中的因果關系。因為人們如果發(fā)高燒，也會申請更多的帶薪休假。

當一個團隊有高度的心理安全感時，你可以嘗試一些很酷的試驗。我相信，這些試驗會產生一種自我強化的積極反饋循環(huán)，創(chuàng)造出更高層次的信任和安全感。在我的第一個高績效團隊里，在一次回顧中，每個人都覺得一年兩次的績效評估周期不夠頻繁，也不夠細致，無法促進職業(yè)發(fā)展，尤其是在我們團隊的優(yōu)先事項發(fā)展得如此之快的情況下。所以，我提出了一項試驗：反饋周。

這是一個為期一周的過程，每個人（包括團隊負責人和項目經理）都被隨機分配去收集對另一個人的反饋。這個過程進行得如此順利，以至于在我的隊友加入新的團隊后，也帶去了這個試驗。最終，辦公室里的其他團隊開始模仿我們！我在這篇博文中更詳細地介紹了這個試驗。我還在 2019 年的多倫多 DevOpsDays 大會上就此做了一場演講。

能夠開展類似這樣的反饋周，就說明你的團隊處于高度的心理安全狀態(tài)。如果你足夠幸運參與其中，我的建議是：不要只站著不動。這是一個大膽試驗你的過程和實踐的機會，嘗試像反饋周這樣的事情，可以幫助你挖掘隱藏的積極反饋循環(huán)。如果你確實想出了一些很酷的東西，請告訴我！

我就直說了吧，我永遠不會有一個完整的 GitHub 心智模型。它太龐大了，有太多的邏輯路徑，坦率地說，花費過多的時間學習代碼的所有部分，并不能使我的工作做得更好。而且，它可能明天就又變了。

因此，當我必須收集足夠的上下文信息以實現(xiàn)下一個特性或 Bug 修復時，我會依賴于代碼中已有構件的準確性，這些構件是在我之前從事這些工作的人留下的。

我花了很多時間來研究代碼：運行 git blame，查看過去的提交、 有關問題，以及任何有助于我理解為什么某行代碼這樣寫的信息。如果我看到一個難以理解的改動，提交信息是“WIP”，這就會變成效率殺手。

良好的軟件開發(fā)規(guī)范意味著需要額外花一些時間來記錄當前的上下文信息，這可能表現(xiàn)在：

• 描述性的提交信息

• 至少，做到每個提交信息都包含一個動詞。有些團隊甚至更進一步，要求每次提交都可以跟蹤到問題編號。務必選擇適合你的團隊認知投資水平的方法；

• 遵循語言和框架約定、可以表明意圖的類名和方法名；

• 單元測試帶有有用的描述信息，使用符合實際的變量名和數(shù)據，而不是“foo”和“bar”這樣的變量；

• 在問題跟蹤系統(tǒng)中就相關特性反復溝通，而不是在 Slack DM 和其他地方。今后，入職不滿 6 個月的團隊新成員將無法訪問這些地方。

最后，良好的開發(fā)規(guī)范事關同理心。工件越整潔，團隊成員就可以越快地了解上下文，花在上下文切換和探查上的認知精力也就越少。此外，這其實對未來的你自己也是有好處的。道德哲學的一個分支認為，未來的你是一個有道德權利主張的不同實體，我想說：推廣這些開發(fā)規(guī)范后續(xù)一定會得到回報，特別是在凌晨 3 點有人因為你寫的一行代碼給你打電話時！

我喜歡角色扮演游戲，尤其是《火焰紋章》和《口袋妖怪》系列，我最近還慢慢地喜歡上了《最終幻想》。

提這個是因為我認為，在《火焰紋章》中組建軍隊的方式和組建均衡的軟件開發(fā)團隊之間有很多相似之處。在 RPG 游戲中，我擁有自己的核心團隊，我非常喜歡將所有角色都均衡升級。如果我獲得了一個等級較低的新角色，但他有一套技能或親和力可以給隊伍做補充，我就會對他進行投資，給他升一點級，這樣他就可以在地圖上到處移動而不用擔心敵人的攻擊。如果我的角色一開始就有一個很高的等級，我就會避免讓他們與較弱的敵人戰(zhàn)斗，因為這只會占用經驗點，而這些經驗點會讓我的低等級角色受益更多。

我傾向于認為，軟件團隊中也存在類似的原則，但這些經驗點不是為了增加力量、防御、魔法和抗性，每一項新工作都是一個“敵人”，一旦交付，就會擴大團隊的領域上下文和信心。通常，團隊中是沒有核心“謀士”這樣一個角色的，至此，這個類比就開始變得不恰當了（主管和項目經理不算，他們通常沒有足夠的視野或最新的上下文信息，無論如何，把如此復雜而又動態(tài)變化的事情都集中在一個人那里是個壞主意）。如果你的團隊里已經有很多優(yōu)秀的騎士和圣騎士——呃，我的意思是，高級開發(fā)人員——那么作為一個團隊，你應該注意，不要總是只安排他們去處理困難的工作。在健康的團隊中，上下文再分配也是他們工作的一部分，這樣一來，一個缺乏經驗的戰(zhàn)士——我的意思是，工程師——也可以獲得一些有價值的經驗點。如果每個人都覺得自己至少在某種程度上具備了應對任何挑戰(zhàn)的能力，那么這將提高整個團隊的生產力和士氣。如果沒有，他們知道自己可以增加一個獵鷹騎士作為副官——換句話說，向更有經驗的人尋求幫助。

關于最后一點，我想了很多。在對我的想法的所有描述中，我認為最好的是 Nat Friedman 在最近一次全體會議中所做的介紹。他說過類似這樣的話：“我們彼此之間的交流應該遵循穩(wěn)健性原則：發(fā)送時要保守，接收時要開放。”他還鼓勵我們堅持寬容性原則，尤其是在非常困難的情況下與對方溝通的時候。但是我認為，高績效團隊會百分之百遵循這個原則。

我非常喜歡這種框架化，因為它讓我想起了多年前我在 codebar 做志愿者時所經歷的導師培訓?！凹僭O你接觸到的每個學生都知識有限，但智慧無限?！边@樣一來，指導者就有責任確保他們的解釋容易理解——考慮到老師和學生之間固有的權力不平衡，這是傳達附加的情緒勞務的一種很好的方式。

同事之間慷慨大方地交流意味著，我們假設任何時候任何人問問題時：

• 已經做了基本的研究，如已經用谷歌進行了搜索；

• 他們是因為在任何地方都無法找到答案才找人問。因為這個地方很難找，或者根本不存在。

換句話說：假設你的同伴是一個有能力、聰明、通情達理的人，他們問問題是因為他們不了解上下文，雖然他們已經設法了解過。

當你開始尋求幫助時，你的上下文信息和工作經驗被不斷地“四舍五入”，我都不知道該怎么表達這是多么令人沮喪。是的，這里面有性別因素，但這超出了我們現(xiàn)在的討論范圍。以前，我曾發(fā)過多條推特，表達了當別人認為你實際上遠沒有那么經驗豐富和知識淵博時的沮喪。當然，別人是不可能真正知道的，無所不知是不可能的！但是，這里有一個折中方案，也是一個合理的要求：慷慨。

像下面這樣就不夠慷慨：

相反，下面這樣就是慷慨的：

上面兩種互動方式的關鍵區(qū)別在于，在慷慨的互動中，在給出答案之前，回答者會確認他們對問題的假設，進而核實提問者的上下文層級和意圖。采用慷慨的交流方式有非常積極的影響：首先，注意到交流時所使用的詞匯減少了嗎？他們實際上可以更快地得到答案。其次，沒有產生不必要的摩擦。兩個人團結一致消除了不確定性，而不是糾結于每個人知道多少，如果是后者，也許最終他們也可以得出答案，但同時也失去了一些信任和善意。

如果你有在高效軟件開發(fā)團隊工作的經驗，或者花時間做過這方面的研究總結，請留言告訴我們你的感受和想法！