我經常需要費力地跟人解釋，作爲高效軟件團隊的一員到底意味着什麼。當然，關於這一點已經有大量的資料，比如LinkedIn就有整套思想領導力理論介紹了各種幫助團隊有效運作的指導方針和啓發性思考，但根據我的經驗，如果你從來都不知道什麼樣纔算好，就很難內化這些想法並遵循別人的模式。
我非常幸運，到目前爲止，我在職業生涯中已經直接與幾十個（甚至是幾百個）開發人員合作過。我曾在一些不健康的團隊工作過：在那些團隊裏，人們會感到害怕，出於對職位的擔憂，他們會把自己的底牌捂得很緊，不讓其他人知道自己的計劃或意圖；我也在功能失調的團隊工作過，那些團隊由於工作優先級不明確而搖擺不定，或者協調成本太高而沒有人願意幹活，許多天甚至數週的開發時間被浪費掉，團隊成了一個個體的集合，而不再是一個工作單元。但幸運的是，我也曾在一些非常優秀的團隊工作過。當我身處這些優秀團隊的時候，我每天去上班時都很興奮，對於那些比我年長的人，我也不怕公開提出反對意見，因爲我認爲自己的聲音和工作很有影響力。
在這篇文章中，我將試着記錄下，我所共事過的表現最好的團隊所具有的特質和習慣。
本文最初發佈於Denise Yu的個人博客，經原作者授權由InfoQ中文站翻譯並分享。
高度的心理安全感
心理安全這個概念被提出來已經有一段時間了，所以我不打算花太多時間來解釋它。如果你以前沒有看過這個概念，請先閱讀這篇文章。
軟件團隊由真實的人組成，他們在無形的社會和政治結構中生活和工作，他們從出生起就被社會化，變得更加自信，更加謙恭，更加直言不諱，更加禮貌，更加好爭論，更善於安撫，等等。顯然，這都是陳詞濫調了，我說這些是爲了證明，心理安全不僅指的是招聘一些顧問來開展員工培訓、告訴大家這個概念意味着什麼：建立真正的心理安全感需要領導者和管理者評估人與人之間交往的所有無形的社會規則，並理解這些規則如何影響一個人參與團隊討論、貢獻團隊動力的能力。簡而言之：社交特權很重要。否則，當一些微不足道的小事情開始侵蝕團隊凝聚力的時候，不要感到驚訝：攻擊性的言語或小動作、刻板印象威脅、將倖存者偏差變成成就高效團隊成員的信條。
根據我的觀察，具有高度心理安全感的軟件團隊會有以下某些行爲：
- 定期回顧，在“什麼進展不順利？”這一欄裏列出適當數量的事項。那裏不應該總是陽光和彩虹。那會讓我懷疑回顧中是不是沒有提出並討論什麼難題。健康的團隊應該能夠公開地反省並自我批評，因爲每個人都明白，建設性的反饋是爲了不斷改進。
- 個人不會在一個問題上花很多時間。他們會有一個或明或暗的“奮鬥時間窗”，在這個時間之後，他們會向同伴尋求幫助，他們知道，自己不會因此而得到負面評價。
- 個人從看得見的輸出中分離出他們對團隊的價值。我見過這樣的情況，人們對自己的代碼後來被刪除或重構感到沮喪。但在健康的團隊中，大家接受這樣一個事實：改進是增量的、漸進的，貢獻是對團隊整體結果的貢獻，而不是對特定輸出（如代碼行數）的貢獻，表現出來就是“這是我們交付的”，而不是“這是我交付的”。此外，具有高度心理安全感的團隊可以討論價值的含義，以及價值爲什麼不僅僅是幾行代碼。
- 帶薪休假時間和病假時間往往會更長，這很有趣。我認爲，這是他們的信念的一種體現，即團隊的其他成員可以在他們不在的情況下繼續做出正確的決策，因爲他們之間已經進行了足夠多的對話，這使得整個團隊都認爲，他們在產品和技術決策上非常一致。但我不太確定這其中的因果關係。因爲人們如果發高燒，也會申請更多的帶薪休假。
當一個團隊有高度的心理安全感時，你可以嘗試一些很酷的試驗。我相信，這些試驗會產生一種自我強化的積極反饋循環，創造出更高層次的信任和安全感。在我的第一個高績效團隊裏，在一次回顧中，每個人都覺得一年兩次的績效評估週期不夠頻繁，也不夠細緻，無法促進職業發展，尤其是在我們團隊的優先事項發展得如此之快的情況下。所以，我提出了一項試驗：反饋周。
反饋周
這是一個爲期一週的過程，每個人（包括團隊負責人和項目經理）都被隨機分配去收集對另一個人的反饋。這個過程進行得如此順利，以至於在我的隊友加入新的團隊後，也帶去了這個試驗。最終，辦公室裏的其他團隊開始模仿我們！我在這篇博文中更詳細地介紹了這個試驗。我還在2019年的多倫多DevOpsDays大會上就此做了一場演講。
能夠開展類似這樣的反饋周，就說明你的團隊處於高度的心理安全狀態。如果你足夠幸運參與其中，我的建議是：不要只站着不動。這是一個大膽試驗你的過程和實踐的機會，嘗試像反饋周這樣的事情，可以幫助你挖掘隱藏的積極反饋循環。如果你確實想出了一些很酷的東西，請告訴我！
良好的開發規範
隨着系統複雜性的增加，系統中任何單個行爲主體的自有模型的準確性都會迅速降低。
— Woods Theorem
我就直說了吧，我永遠不會有一個完整的GitHub心智模型。它太龐大了，有太多的邏輯路徑，坦率地說，花費過多的時間學習代碼的所有部分，並不能使我的工作做得更好。而且，它可能明天就又變了。
因此，當我必須收集足夠的上下文信息以實現下一個特性或Bug修復時，我會依賴於代碼中已有構件的準確性，這些構件是在我之前從事這些工作的人留下的。
我花了很多時間來研究代碼：運行git blame，查看過去的提交、 有關問題，以及任何有助於我理解爲什麼某行代碼這樣寫的信息。如果我看到一個難以理解的改動，提交信息是“WIP”，這就會變成效率殺手。
良好的軟件開發規範意味着需要額外花一些時間來記錄當前的上下文信息，這可能表現在：
- 描述性的提交信息
- 至少，做到每個提交信息都包含一個動詞。有些團隊甚至更進一步，要求每次提交都可以跟蹤到問題編號。務必選擇適合你的團隊認知投資水平的方法；
- 遵循語言和框架約定、可以表明意圖的類名和方法名；
- 單元測試帶有有用的描述信息，使用符合實際的變量名和數據，而不是“foo”和“bar”這樣的變量；
- 在問題跟蹤系統中就相關特性反覆溝通，而不是在Slack DM和其他地方。今後，入職不滿6個月的團隊新成員將無法訪問這些地方。
最後，良好的開發規範事關同理心。工件越整潔，團隊成員就可以越快地瞭解上下文，花在上下文切換和探查上的認知精力也就越少。此外，這其實對未來的你自己也是有好處的。道德哲學的一個分支認爲，未來的你是一個有道德權利主張的不同實體，我想說：推廣這些開發規範後續一定會得到回報，特別是在凌晨3點有人因爲你寫的一行代碼給你打電話時！
主動重新分配“經驗點”
我喜歡角色扮演遊戲，尤其是《火焰徽章》和《口袋妖怪》系列，我最近還慢慢地喜歡上了《最終幻想》。
提這個是因爲我認爲，在《火焰徽章》中組建軍隊的方式和組建均衡的軟件開發團隊之間有很多相似之處。在RPG遊戲中，我擁有自己的核心團隊，我非常喜歡將所有角色都均衡升級。如果我獲得了一個等級較低的新角色，但他有一套技能或親和力可以給隊伍做補充，我就會對他進行投資，給他升一點級，這樣他就可以在地圖上到處移動而不用擔心敵人的攻擊。如果我的角色一開始就有一個很高的等級，我就會避免讓他們與較弱的敵人戰鬥，因爲這隻會佔用經驗點，而這些經驗點會讓我的低等級角色受益更多。
我傾向於認爲，軟件團隊中也存在類似的原則，但這些經驗點不是爲了增加力量、防禦、魔法和抗性，每一項新工作都是一個“敵人”，一旦交付，就會擴大團隊的領域上下文和信心。通常，團隊中是沒有核心“謀士”這樣一個角色的，至此，這個類比就開始變得不恰當了（主管和項目經理不算，他們通常沒有足夠的視野或最新的上下文信息，無論如何，把如此複雜而又動態變化的事情都集中在一個人那裏是個壞主意）。如果你的團隊裏已經有很多優秀的騎士和聖騎士——呃，我的意思是，高級開發人員——那麼作爲一個團隊，你應該注意，不要總是隻安排他們去處理困難的工作。在健康的團隊中，上下文再分配也是他們工作的一部分，這樣一來，一個缺乏經驗的戰士——我的意思是，工程師——也可以獲得一些有價值的經驗點。如果每個人都覺得自己至少在某種程度上具備了應對任何挑戰的能力，那麼這將提高整個團隊的生產力和士氣。如果沒有，他們知道自己可以增加一個獵鷹騎士作爲副官——換句話說，向更有經驗的人尋求幫助。
慷慨大方地交流
關於最後一點，我想了很多。在對我的想法的所有描述中，我認爲最好的是Nat Friedman在最近一次全體會議中所做的介紹。他說過類似這樣的話：“我們彼此之間的交流應該遵循穩健性原則：發送時要保守，接收時要開放。”他還鼓勵我們堅持寬容性原則，尤其是在非常困難的情況下與對方溝通的時候。但是我認爲，高績效團隊會百分之百遵循這個原則。
我非常喜歡這種框架化，因爲它讓我想起了多年前我在codebar做志願者時所經歷的導師培訓。“假設你接觸到的每個學生都知識有限，但智慧無限。”這樣一來，指導者就有責任確保他們的解釋容易理解——考慮到老師和學生之間固有的權力不平衡，這是傳達附加的情緒勞務的一種很好的方式。
同事之間慷慨大方地交流意味着，我們假設任何時候任何人問問題時：
- 已經做了基本的研究，如已經用谷歌進行了搜索；
- 他們是因爲在任何地方都無法找到答案才找人問。因爲這個地方很難找，或者根本不存在。
換句話說：假設你的同伴是一個有能力、聰明、通情達理的人，他們問問題是因爲他們不瞭解上下文，雖然他們已經設法瞭解過。
當你開始尋求幫助時，你的上下文信息和工作經驗被不斷地“四捨五入”，我都不知道該怎麼表達這是多麼令人沮喪。是的，這裏面有性別因素，但這超出了我們現在的討論範圍。以前，我曾發過多條推特，表達了當別人認爲你實際上遠沒有那麼經驗豐富和知識淵博時的沮喪。當然，別人是不可能真正知道的，無所不知是不可能的！但是，這裏有一個折中方案，也是一個合理的要求：慷慨。
像下面這樣就不夠慷慨：
我：嗨，這裏爲什麼有一個負載均衡器？
X：負載均衡器用於將請求分發到多個服務上，這樣我們就不會遭受DDoS攻擊了！這裏有一些文章介紹負載均衡器的基礎知識，以及從理論上講我們爲什麼要使用它們！
我：好的，但我問的不是這個。我知道負載均衡器是什麼。我只是想了解下，在架構決策時，爲什麼要把**HAproxy放在這個特定的服務前面。
X：奧！好吧，你應該直接這樣問！
相反，下面這樣就是慷慨的：
我：嗨，這裏爲什麼有一個負載均衡器？
X：我猜你是在問我們爲什麼選擇HAproxy，以及爲什麼選擇這些服務。如果不是的話，現在就告訴我。
我：對，就是那樣！謝謝你先確認我的問題。
X：不用客氣。是這樣的，18個月前，當我們構建這個系統時……
上面兩種互動方式的關鍵區別在於，在慷慨的互動中，在給出答案之前，回答者會確認他們對問題的假設，進而覈實提問者的上下文層級和意圖。採用慷慨的交流方式有非常積極的影響：首先，注意到交流時所使用的詞彙減少了嗎？他們實際上可以更快地得到答案。其次，沒有產生不必要的摩擦。兩個人團結一致消除了不確定性，而不是糾結於每個人知道多少，如果是後者，也許最終他們也可以得出答案，但同時也失去了一些信任和善意。
如果你有在高效軟件開發團隊工作的經驗，或者花時間做過這方面的研究總結，請留言告訴我們你的感受和想法！