牛叉的技術經理，也應當是牛叉的除錯者

據我觀察，就我認識的牛叉技術經理，他們通常也是牛叉的除錯者（debugger）。為什麼會這樣呢？這兩項工作到底有什麼重疊的技能呢？

牛叉的除錯者會堅持不懈地去追求導致 bug 的原因。當我們在應用邏輯層中查詢錯誤時做到這點是很容易的，但是我們都知道 bug 可以藏在很深層的地方，特別是在那些具有許多獨立部件且處理延時網路的複雜系統中 bug 可能會藏地更深。一個差勁除錯者的標誌是，當他們為了查詢錯誤而在一段併發程式碼中新增日誌語句後發現錯誤無法重現了，就會假設問題因此被解決了。

這是一種偷懶的習慣，但是卻很常見。有時，有一些問題看起來很難查明，很多人都沒有耐心去為了只發生一次的錯誤而去深挖他們自己或者別人的程式碼、日誌檔案、系統設定，以及其他可以瞭解某些底層的東西。也不能去責怪他們。被動地去除錯只發生一次的問題，有時只是浪費時間，但是這卻展示了一個對未知不滿的心態，特別是當半夜三更時它出現而你卻不知道為什麼的時候。

那麼作為主管應該怎麼做呢？

管理團隊是一系列複雜的過程，是黑盒與其他複雜的黑盒之間的互動。這些黑盒有可觀察地輸入和輸出，但是當輸出無法按預期輸出時，想要知道原因的話需要嘗試著開啟黑盒，去看看它的內部到底是怎麼了。也許有時你是看不到原始碼的，或者不瞭解原始碼所用的語言，或者日誌檔案是不可讀的，又或者團隊的黑盒子會抵抗外部力量。

團隊也具有另一個著名盒子的特性，即盒子裡必定發生兩個結果之一，而外部觀測者只有開啟盒子才能知道里面結果的“薛定諤的貓”原理。這個實驗的重點是說明觀察變化結果的行為，或者觀察變化導致一種結果的發生。不融入到團隊、不參加他們的會議，不觀察他們的站立會議的話，你是不能瞭解一個團隊的，也無法改變團隊的行為。你的存在改變著團隊的行為，也許你能從中發現正在找尋的隱藏問題，同樣地你可能發現至少在一段時間內一個日誌語句導致的併發問題神奇地被解決了。

除錯系統 vs 除錯團隊

去除錯一個系統，可能你必須想好合理的假設解釋為什麼系統會進入失敗的狀態，如果你可以將問題重現的更好，這樣你就可以解決 bug （或者至少可以避免它將來再次發生）。去除錯一個團隊，你也應當嘗試著想出團隊為什麼存在問題的假設。為了不讓自己在複雜問題中反而起到搗亂作用你應當盡最大可能這樣做。在團隊問題中，你還有一項額外的挑戰，某些團隊問題並不表現為一次失敗，而更像是一個效能問題。整個系統是可以運轉的，但效率越來越低。機器是正常的，除了時不時會崩潰一下。人們看上去都很高興，但系統內耗非常嚴重。

讓我們看個例子。我們有一個看起來死氣沉沉的團隊。你已經從他們的商務合作伙伴還有產品經理那裡聽到了這樣的抱怨，你也認為和你的其他團隊相比，這個團隊確實看起來缺少了同樣的熱情。那我們該怎麼做呢。

像除錯一個嚴重的系統問題一樣去除錯它。當我除錯一個系統問題時，首先我會看看日誌檔案，還有其他的系統狀態和事故時間的記錄。如果一個團隊不能按期完成工作，看看記錄。看看這個團隊的聊天組都聊了什麼，還有他們的電子郵件，看看他們的計劃，看看程式碼庫的程式碼評審和簽入的程式碼。我們能看到什麼？這些是不是佔用了他們太多時間？是不是很多人都不夠活躍了？是不是他們在程式碼評審中的註釋裡有對程式碼風格的不同意見？計劃是不是被填寫地模糊不清，太多了，或者太少了？這個團隊是不是看起來溝通方式很樂觀，聊天時是否也分享一些有趣的事情，或者他們只討論業務？看看他們的工作日曆。團隊是否在一週內被會議佔用了太多時間？他們的經理是否一對一談話了？這些是都是小事，但是它們卻能指出一些問題的所在。

也許上面說的那些看起來都沒啥問題，但是團隊還是沒有按照你認為他們能做到的那樣把工作完成。你知道這裡有人才，團隊很友好，他們沒有為支援生產線而感到壓力過大。發生了什麼？也許現在是時候開始做一些調查了。參與他們的會議。你覺得他們讓你無聊麼？這個團隊太無聊了麼？大部分時間是誰在說話？在整個團隊都參與的會議中，會議的大部分時間是否是大家聽領導或者產品主管說話了？無聊的會議是一個徵兆。也許意味著由組織者做出的計劃很低效。也許會議中資訊量覆蓋太多。也許意味著團隊成員無法幫助團隊找到方向，或者為將來目標選擇現在做什麼。如果不是上級領導存在問題的話，那麼可以肯定的是無聊的會議是浪費時間的。

問問團隊的目標是什麼，他們能說出來麼？他們能理解這些目標存在的理由麼？如果他們無法理解他們工作的目標，那麼團隊領導（經理，技術領導，產品經理）在使團隊成員認識到他們的工作目的這方面，沒有做好本職工作。幾乎所有的工作動力都是源自人們能夠理解和了解他們工作的目的。他們為了誰在搭建這些系統，對客戶、商務或者團隊的潛在影響是什麼樣的。他們是否參與了這些目標的決策，專案是否是為了完成這個目標而進行的？如果不是，那為什麼不是呢？當你看到一個團隊花費他們全部的時間在開發上，而忽視了應當去關注的產品或者商務部分時，可能是因為缺少了積極性去與他們交涉。

最後你也許該會看看團隊的實際動態。大家是否彼此喜歡？他們是否很友好？在專案中是否能夠很好地協作或者獨立完成各自的工作？休息室中閒聊或者發郵件時是否會開玩笑？他們和其他的相鄰部門和他們的產品經理是否有不錯的工作關係？在一些專門討論工作的群組中組員之間是否會有一些私交。團隊中有一部分人從來不和其他人交流並且總是在做著獨立的專案，這樣並不能叫做團隊協作。這種情況下，如果團隊還能工作的很好的話，那也沒什麼問題。但是假設不是的話，那就是你的錯了。

有時經理的經理選擇將這樣的問題當作是團隊經理需要解決的問題。你需要去衡量這個經理對於他們團隊的作用，畢竟當事情發展地不順利時，這應該是他們的責任去解決問題。這是真的，正如有時候我也可能會加入並幫忙除錯複雜系統的問題，儘管我很少寫程式碼，這沒什麼，加入進去幫助團隊除錯問題，特別當經理也無法解決問題時。這也許會成為一個機會去教導這個經理並幫助他們成長。這樣也會暴露更多的組織基礎問題，例如缺少高階商務領導的話就算是再好的經理也不能找到或者獨立解決問題。

當組織出現問題時，找尋它發生的原因是對你來說是很好的一種鍛鍊和經驗教訓。如果經常這樣做，我們在除錯方面會更有長進，可以瞭解哪個部分更容易出現問題，哪個指示器為找到問題提供了最大的價值。通過推進我們自己和我們領導的團隊去更深入地查詢底層問題，找到問題出現的原因，可以讓我們變得更好，也會幫我們在以後能夠越來越快地解決問題。如果不知道為什麼，我們靠著魅力和幸運去看待我們的管理生涯，我們根據一個人的魅力和幸運去僱傭人和解僱人，當我們從錯誤中學到東西時，就會發現我們其實存在著一個巨大的盲區。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者