筆記：高能軟體開發團隊的文化

原文為Habits of High-Functioning Teams，已徵得作者Denise Yu同意翻譯。作者分享了他職涯中的經驗，試著歸納出優秀軟體團隊的共通特質。本文為閱讀過後的整理筆記，並非原文的逐句翻譯，若與原文意義有出入，歡迎留言或是來信指正。

心理安全感

一個擁有高度心理安全感的團隊，通常會有以下特徵：

鼓勵反思

團隊成員願意大方討論目前還有什麼不好的地方，也不會避諱談論自己的缺失，因為大家都明白，建設性的回饋才能幫助團隊進步，沒有必要去假裝自己什麼都懂，或是掩蓋什麼錯誤。

不會獨自浪費時間卡死在問題上

當碰到一個難解的問題，我們總會有個心理門檻，來決定要掙扎多久再去找人求救。在健康的團隊中，這個門檻不會高到太過分，因為不用擔心會因為尋求協助，其他人就對自己的能力產生負面評價；相反的，如果因為怕被認為能力不足，就自己悶起頭來掙扎了非常久才願意求救，這些浪費掉的時間對團隊來說也是無形成本。

不會糾結於個人的有形產出

有些人會因為自己的程式碼，被刪掉或重構掉而覺得挫折，但在健康的團隊中，成員們會更重視整體團隊的產出和價值，只要這個改動對結果是有幫助的，並不需要去強調自己產出了多少，去爭取這個功勞，而是會想到「我們」一起做出了很棒的東西。成員間也能放心談論所謂的「價值」是什麼，又為什麼不該只是去比較大家寫了多少程式。

能夠放心請假

成員會傾向於使用更多特休或是請病假。作者猜想，這是因為他們對團隊的信任，不用擔心專案會因為自己請了幾天假就爆炸，因為其他人在自己不在的時候，依然能夠穩定產出、做出對的決定。但作者並沒有很肯定這就是原因，因為過勞（burned out）也可能導致常常請假。

譯註：我個人的經驗是，健康的團隊確實會讓大家能夠放心請假，因為不用擔心：

• 被視為懶惰的表現
• 被認為不夠盡心盡力為團隊付出
• 萬一進度落後會受到更嚴厲的責難

軟體開發潔癖

當我們要對一個既有的軟體加新功能或是修bug時，往往都會需要花費大量的時間做考古：下git blame，讀一大堆commit訊息，看有哪些相關的issue，翻遍任何有關的資料，只為了要搞懂，為什麼這行程式碼當初要這樣寫？

有好的軟體開發習慣的人，會花費額外的時間去紀錄當下的狀況脈絡，例如：

• 有意義的commit訊息
• 依循程式語言慣例，並且表明意圖的命名方式
• 在單元測試中使用有意義的變數命名
• 在issue上的討論串做溝通，避免使用私訊，以留下紀錄方便未來查閱

總歸來說，這種開發上的潔癖是出自於同理心。這些習慣會讓未來的其他團隊成員，甚至是未來的自己，能夠更快了解當時的問題脈絡，花費更少的認知成本去做考古。

經驗值分配

在RPG中，同樣的一隻小怪所帶來的經驗值，對於一個高等角色來說可能毫無意義，卻可以讓一個低等角色快速升級。

在軟體開發團隊中也有類似的道理。任何事情都交給資深程式來做當然是非常可靠，但如果不是什麼很困難的問題，對他們技能上的成長就不會有什麼幫助；然而，同樣一件事情，如果讓比較初階的程式也有機會去應付，那麼他獲得的能力提升一定也會比較顯著。這樣一來，整體團隊戰力就能有所提升，初階程式也能從中獲得自信，對團隊士氣也有幫助。

寬容的溝通

作者提到了兩個來自不同領域的原則：

• 穩健性原則 (Robustness Principle)

  原本出自軟體設計，內容就是一句話：「保守的對待你所做的，開放的接受別人所給予的。（Be conservative in what you do, be liberal in what you accept from others.）」

  TCP就遵循了這個原則，在發送封包的時候確保合乎格式，卻會盡可能的去接收各式各樣的封包，只要它的意圖足夠清楚。

• 善意理解原則 (Principle of Charity)

  出自哲學和修辭學，意指在理解他人發言的時候，如果同時有數種解讀方式，我們應該選擇其中最好、最有邏輯、最沒有瑕疵的那個。

應用在軟體開發日常中，當有任何一個團隊成員提問，我們都能夠假設：

• 他已經做了基本的功課（例如：google過了）
• 他會選擇問其他人，是因為他找不到任何內部文件記錄能夠解答，要嘛這個文件實在不好找，又或者是根本沒有這種文件

換句話說，要假設你的同事是個稱職、聰明而講理的人，他會這樣問，一定只是他缺少了什麼脈絡，他已經很努力的把能做的都做了。

舉個例子，缺乏寬容的對話可能會像這樣：

我：欸，為什麼那裡要放個load balancer啊？

某人：load balancer是用來分散request到其他service上的，這樣我們才不會被DDoS啊…這裡有幾篇文章是在解釋load balancer的基本原理，你自己看過一遍就知道為什麼我們該用了好嗎！

我：呃好，但我想問的其實不是這個。我知道load balancer是用來幹嘛的，我只是好奇為什麼我們的架構會設計成，把HAProxy放在那個service前面。

某人：搞屁喔，你一開始就這樣問不就沒事了嗎…

相反的，如果能夠寬容一點理解的話：

我：欸，為什麼那裡要放個load balancer啊？

某人：你想問的應該是，為什麼我們會選HAProxy，然後為什麼是那些service需要，對吧？

我：啊對，這就是我想問的！

某人：一年半前，我剛開始做這個系統的時候…

關鍵在於，在回答問題之前，先搞清楚發問者的程度和意圖。

這樣回答的好處是：

• 能夠早點切入正題
• 減少不必要的摩擦

譯註：想要雞婆一點強調的是，這篇文章想分享的是健康的團隊會有的文化，而文化不是一兩個成員能夠決定的，所以我們是不可能單獨在團隊中應用這些原則的。最好不要盲目而一廂情願的，在目前身處的團隊中，去實踐文章提到的任何一點，很可能會反而讓自己的處境更為艱難。