如何切實減少會議（而非僅是抱怨會議）

主管每週花 23 小時在會議上，這一數字自 1960 年代以來增加了一倍多。員工每週花 5 小時在他們自己都認為毫無成效的會議上，比 2019 年增加了一倍。微軟的數據顯示，其生產力套件中 60% 的時間用於電子郵件、聊天和會議，只有 40% 的時間用於創作工具。員工平均每 2 分鐘就會被會議、訊息或通知打斷一次。

每個人都知道這是一個問題。大多數解決方案都行不通，因為它們治標（會議太多）而不治本（只能透過同步方式傳遞且未記錄的背景資訊）。

「準備會議議程」並不能減少會議次數。「縮短會議時間」只是把相同的協調工作壓縮到更短的時間內。「取消一週的所有會議」會帶來暫時的改善，但隨後會出現大量重新安排會議的情況。這些都是針對結構性問題採取的表面修飾措施。

為什麼會議會成倍增加

會議成倍增加是因為一個特定的機制：隨著團隊的成長，需要分享的背景資訊量，其增長速度超過了團隊透過非正式管道分享資訊的能力。在 5 個人的團隊中，背景資訊透過人際接近來傳播。在 15 個人的團隊中，這開始需要刻意的努力。在 30 個人的團隊中，這種刻意的努力就表現為會議的形式，因為會議是同步傳遞背景資訊的預設機制。

大多數會議的存在是出於以下四個原因之一：

背景資訊傳遞。「事情是這樣發展的，我們目前進展到這裡，下一步計劃是這樣。」每日站會、進度更新、全員大會、Sprint 評審。這些會議的存在是為了讓大家掌握最新資訊。

決策。「我們需要在 A 和 B 之間做出選擇。」架構討論、規劃會議、策略辯論。這些會議的存在是為了透過討論達成結論。

達成共識。「大家的想法一致嗎？」啟動會議、回顧會議、跨團隊同步。這些會議的存在是為了確保共同的理解。

創意協作。腦力激盪、設計會議、結對編程、解決問題。這些會議的存在是為了透過互動創造新的東西。

只有最後兩類會議需要人們同時在同一個房間（或通話中）。前兩類會議佔了大多數組織中大部分的會議時間，如果有了適當的基礎設施，完全可以透過非同步方式處理。

取代傳遞背景資訊的會議

進度會議之所以存在，是因為進度沒有記錄在每個人都可以閱讀的地方。Sprint 評審會議之所以存在，是因為交付的工作在團隊之外是不可見的。全員問答會議之所以存在，是因為領導層的背景資訊沒有以書面形式分享。

這其中每一項的非同步替代方案，都是保持最新狀態的說明文件：

每日站會 → 專案進度文件。一個自動編寫的 wiki 可以追蹤已交付、進行中和被阻礙的工作，並從 GitHub 活動和專案討論中生成，它提供了與站會相同的資訊，而不需要每個人在同一時間都有空。五個人參加的 15 分鐘站會，每天要消耗團隊 75 分鐘的時間。而一份文件所需的成本為零。

Sprint 評審 → 變更日誌。根據合併的 PR 和版本說明產生的說明文件展示了交付了什麼以及原因，任何想閱讀的人都可以隨時閱讀，而不需要舉行同步的儀式。

全員大會 → 書面更新。領導層的背景資訊以書面更新的形式分享，員工可以在自己的時間閱讀，問題則透過非同步方式提交和回答。真正需要的全員大會（慶功、重大宣布、針對敏感話題的問答）減少了舉辦頻率，且因為它不與例行的資訊傳遞相衝突而顯得更有價值。

用非同步流程取代決策會議

決策會議之所以存在，是因為推理過程和選項記錄得不夠充分，無法讓人們獨立進行評估。

非同步的替代方案：撰寫一份決策文件，列出問題、選項、權衡取捨和推薦的方法。與決策者分享該文件。設定提出評論和反對意見的截止日期。如果沒有實質性的反對意見，則做出決策。如果有反對意見，則將反對意見記錄下來，並在討論串中解決，或者提升為簡短、有針對性的同步討論，而這場討論是從共同的理解開始，而不是花費前 20 分鐘來建立共識。

這種方法比會議能產生更好的決策，因為推理過程被記錄下來了，每個人在回應之前都有時間思考，而且決策記錄會保留下來以供未來參考，而不是消失在與會者的記憶中。

保護那些重要的會議

我們的目標不是零會議。有些協調工作更適合同步進行：創意腦力激盪、艱難的對話、建立關係，以及即時討論能比非同步交流帶來更好結果的複雜決策。

當這些會議不再與那些本應是文件的會議競爭時，它們的效果就會提高。一個團隊如果每天要開四個會議，其中三個是背景資訊傳遞，那麼就不會剩下精力來應對那一個真正需要討論的會議。一個透過說明文件處理背景資訊傳遞的團隊，可以將其全部注意力集中在真正需要它的會議上。

實用的框架：對於你日曆上的每個定期會議，詢問它是主要在進行單向的資訊傳遞（→ 文件），還是透過互動產生新的東西（→ 會議）。如果是傳遞資訊，說明文件基礎設施應該取代它。如果是產生新思維，請保護它。

說明文件的依賴性

上述的每一項建議都取決於人們信任且能找到的說明文件。如果文件過期，人們就不會去讀，會議就會持續下去。如果文件被埋在無人查看的 wiki 中，它們在功能上就是隱形的。

這就是為什麼自動編寫的說明文件是有效減少會議的前提條件。從 Slack、GitHub 和會議錄音中自動生成並維護的文件可以保持最新狀態，無需手動維護，這意味著它們能保持被信任的狀態，也意味著人們會去閱讀，這進一步意味著它們所取代的背景資訊傳遞會議不需要再開了。

會議問題和說明文件問題是同一個問題。解決了說明文件問題，會議問題就迎刃而解了。

常見問題

如果我們用文件取代會議，人們難道不會錯過重要的更新嗎？ 如果文件是可搜尋的、最新的，並推送給了正確的人，那麼覆蓋範圍實際上比會議更好，因為文件可以傳達給每個人，而會議只能傳達給與會者。相較於持久且可搜尋的說明文件，會議中錯過更新的風險更高（你錯過了一次會議，你就脫節了）。

我們如何處理會議中的社交層面？ 刻意保留它。安排不偽裝成進度更新的社交時間。在會議中建立的社交聯繫很有價值，但不應該需要透過 30 分鐘的站會來達成。每週一次的團隊咖啡時間或每月一次的團隊午餐，比每天五次站會更能有效發揮社交功能。

與外部利益相關者的會議該如何處理？ 出於維護關係的原因，外部會議（客戶電話、供應商審查、合作夥伴同步）通常需要同步進行。然而，內部的準備和後續跟進可以高度非同步化：會議前的簡報文件、會議中自動記錄的會議記錄，以及會議後追蹤的行動項目。

延伸閱讀：為什麼會議會成倍增加、為了工作而工作、知識擴充問題、本該是文件的會議。相關頁面：自動編寫的文件、針對工程團隊。