溝通：團隊成長時第一個受害者

本文由 The Effective Engineer 作者 Edmond Lau 授權翻譯

“隨著團隊和公司的成長，有哪些流程和系統崩潰，卻遲遲沒受到注意並獲得解決？

這是我最近在一個關於高成長工程的專題討論小組上向Dropbox、Facebook、Stripe和Lyft領導者提出的問題。一個接一個地，小組成員殊途同歸地談到同一主題：溝通往往是第一個因團隊成長而受害。隨著團隊的擴大，分享想法變得越來越困難，無法確保每個人都達到共識。以前習慣的工作模式和慣例開始出錯。

當我與工程師合作幫助他們更有效率時，溝通失敗的故事經常出現。產品團隊可能已準備好向客戶提供高度優先的功能，並決定向基礎架構團隊徵求支援，卻偏偏在最後時刻才有人發現阻礙發行的潛伏問題。或者平台團隊可能升級了服務背後的程式碼，剛剛好破壞了客戶端依賴舊API的行為中沒有行文告知的默認假設。或者一個團隊可能更新設定檔案，不知道由於歷史原因規範了某個設定，並導致一系列錯誤或觸發了此產品必須傳訊通知值班人員打火的警報。

這些事件可能看起來是獨立的，但它們都遵循一個共同的模式：由於溝通失敗造成的知識差距，傷害了團隊的執行能力。像研討小組的這些正在高成長的公司 – 員工基數持續年年增長2-3倍 – 出現這種失靈狀況越來越頻繁。但同樣的溝通失靈也發生在其他逐步成長的公司。結果造成工程能量的浪費、壓力增加、軟體品質降低和客戶不滿意度升高。

為什麼溝通失靈？

回想我初到Quora、Ooyala和Quip工作時，創業公司只有12~24個員工。我可以走到某人的辦公桌旁，有時甚至只是在椅子上轉個身，就可和隊友討論設計或做決定。我知道團隊中誰是某特定產品或程式碼基底的專家。此外，每位工程師都在他們的腦中保有產品和程式碼中合理的部分，並且這些知識都有共享的背景，使得提問和討論簡單容易。在這早期，溝通成本很低。

這樣的奢侈隨著公司的成長逐漸消失，原因有二。

首先，你需要溝通的總人數增加。Frederick Brooks 在 “人月神話 (The Mythical Man Month)”(註1) 中討論了這種效果，他指出，人之間的成對互動的數量隨團隊規模二次方成長。 1（這是為什麼於專案添加更多人常常不能使其更快完成的主要原因。）分享資訊可能不再意味著在休息期間和別人簡要的抬槓;它可能實際上需要一大群人安排正式的會議。

第二，與特定人溝通的成本也增加了。隨著團隊的成長，對產品和程式碼基底的平均熟悉度下降。新員工對於過去的決定沒有相同的歷史背景，甚至比較資深的隊友也不得不花更多的精力來讓大家於每件事同步。你與團隊中的其他人的共享關係較少，所以你可能在問題出現時，會猶豫在非正式的場合提問。相反地，你可能把問題整理整理，並只在預定的會議期間詢問。

問題也變得難以確切地闡述：有關這專案我需要知道哪些過往的歷史？可能被這影響的所有專案是哪些？誰真的知道這些事？誰是對未來的變動有強烈意見的利益相關者？

這些小小的不便加起來。對話和討論變得更加昂貴。因此，個人需要投入更多的時間進行溝通，這使得每個人可分配來完成工作的時間變少了。

每個人的效率降低，常常反而增加了成長團隊的壓力，想以僱用更多的人的手段達到業務目標。招聘更多的人意味著花更多時間處理招聘的事務，面試和匯報候選人以及訓練新進的工程師 – 所有這些活動都非常重要，但他們也代表花在這方面的時間將無法用來建立產品。當然，一旦這些新員工加入，溝通成本又上升，壓力進一步增加。

當我離開Quora和Ooyala時，他們都成長到70多名員工。和大多數類似規模的其他公司一樣，責任已經分散到更多的人和更多的團隊。雖然一些局部決定仍然可以迅速做出，但是較大的決定通常需要與多個利益相關者進行協調的會議。

在更大的公司，溝通成本進一步螺旋展開。您可能需要協調多個團隊的可用時間，在專案上獲得進展。你可能需要走到另一座辦公大樓去參加會議。或者你甚至可能需要飛往別的城市或利用視訊會議系統與遠端的隊友開會。

增加的溝通摩擦，意指在小團隊不會發生的於現在的規模卻發生了。 Pinterest的工程主管Michael Lopp在他的“管理人類(Managing Humans)”(註2) 一書中也提出了類似的觀察，“以前在每個團隊不同的組織規模下，自然異花授粉和傳播活動有機地發生，讓文化和戰略工作順利，並完成重大決策，今天無法再發生“

降低溝通成本

隨著公司的雄心和機會的增長，其團隊也為了迎接挑戰。Google和Facebook能夠處理小型初創公司無法處理的範籌和規模擴展的問題，部分是因為它們的規模大小和資源。

但是考慮到溝通的高成本，只要能做任何事減少這些成本都是非常高槓桿的活動。那麼，我們如何降低溝通成本呢？這裡有一些策略：

聘請高績效者。如果你可以僱用更少的工程師，每個工程師都是表現最好的，協調項專案所需的總體溝通量仍然較低。每個人都可以花更多的時間完成工作。你可以保持你的團隊精簡，同時仍有足夠的資源來面對你的關鍵問題，每個工程師也將更有效率。
投資就職訓練。在你拓展團隊的範圍內，就職訓練會是一個強大的槓桿點，為新員工提供完成工作和做出正確決策所需的背景資訊。確保每個新工程師都能夠接觸到核心抽象(abstractions)、開發工具、操作流程和業務目標，以便你可以重用這些資訊於以後的決策和對話。
投資工具以減少溝通的摩擦。當涉及到工具，速度和易用性如果讓溝通越容易，則將有越多人會使用它。請確保你有好的工具來共享狀態更新、交換有關程式碼審核的反饋、追蹤瑕疵與客戶問題，以及溝通其他資訊。我個人對於目前在Quip工作甚感興奮，因為我們正在建立一個新的生產力工具，可實際地讓團隊交流和共享資訊變得容易（和愉快）。我們幫助了成千上萬的公司，包括 Facebook、Pinterest、Stripe、Quora、New Relic、Instacart 和其他 – 如果你正在尋找良好的溝通工具，看看它吧。
盡可能用異步通信替換現場會議。有些 1：1 和面對面會議總是需要的，但常常會議在議程安排上沒有好好規劃，或對於每週的重複性會議，可以很容易地運用團隊共享的協作文件早已在開會前交換過訊息。異步討論比較不那麼具有破壞性，且只要更少的成本，並允許隊友有更長的時間專注於工作。建議你將會議保留給重要且實際上需要高頻度的討論、同步面對面的對話。
運用輕量和非正式的設計文件來共享資訊。編寫簡短的設計文檔是傳達信息和徵求反饋的好方法。它通常比召開資訊會議消耗更少的總時間和能量，比起建立某樣東西後請求反饋，輕量文件會是個更短的路徑反饋。設計文檔最終將是一個寶貴的知識庫，可供未來團隊成員就職時學習。如果傳達想法或計劃可以是輕量級的，並且不涉及多人會議，則人們顯然更有可能共享資訊，作為其工作流程的正常部分。
建立高度一致、鬆散耦合的團隊文化。 Reed Hastings將此理念歸於Netflix文化中成功的至要關鍵。(註3) 當策略和目標明確定義和理解時，你可以減少跨職能的會議，並相信團隊仍能保持一致。實現這一目標的方法是確定每個人都應該關注的核心業務指標。當團隊協調一致時，人們最終會只花精力與其他團隊討論優先順序，試圖請他人挪開在他們專案上的障礙，並持續前進。