為什麼人們都討厭開會？

原創不易，求分享、求一鍵三連

會議是工作中最重要的組成部分，因為他需要解決兩個核心難題：

資訊傳遞；
達成一致；

有效的資訊傳遞是戰略落地的前提條件，更多的認知統一更是可以加速成功的發生。但無論是資訊傳遞還是達成一致，都不是一件簡單的事情，特別是會議中人多嘴雜，更是加大了這種難度。

所以，如何設計會議，是我們今天要討論的話題。

時間殺手

無效會議已經成了我們最大的時間殺手，比如我的日程：

因為我更偏向於執行層，如果所有會議都參加那麼可以認為所有會議都沒參加，如此密集的會議會導致兩個問題：

沒有時間獨立思考；
沒有精力跟進執行；

那麼為什麼會有這麼多會呢？

規避決策成本

一方面會議的目的是傳遞資訊，另一方面會議還有兩個不光彩的目的：

求助；
規避責任；

比如50個會裡面，有三分之二是外部門邀請參加，一些是業務方週會，一些是專案例會，一些根本不知道是什麼會，總體而言，這些會不外乎是他們不想決策，希望我給出專業意見，最好可以幫他決策或者是需要我的幫助，最好是白嫖研發資源...

舉個例子，公司手裡有1000w某服務商代金券即將到期，現要求我在一個月使用出去，這種臨時代金券的使用多半有大坑，我當然不能隨心所欲，於是就拉幾個業務方一起開會：

首先提供供應商提供的服務和對應成本；
其次問他們結合自己業務有哪些要採買的，免費；

這個階段，業務負責人會以為是白嫖資源，欣然參與，但list出來後，把採買需求人填上去後，他們顯然就有點不願意了，如果再加一列風險說明或者ROI說明，幾個業務負責人就想離場了...

我這裡拉會的目的可以說是求助，也可以認為是規避責任的行為，這裡也引出會議要點之一：

會議要點：責任歸屬到個人

有責任歸屬，才會考慮成本，決策有成本才會減少決策錯誤。規避責任對於個人而言是好事，但對於公司而言就會產生很多無用會議，並且會議時間會特別冗長，這種規避責任的會議會吃掉人們大量時間。為了避免大家互相推諉的情況發生，也會引出另一個會議要點：

會議要點：重要會議需要有能拍板的人

主題偏移

但是，有時候就算責任人就位，能拍板的人也在，但如果主題被帶偏，很多會依舊又臭又長。這裡有兩個要點：

會議要點：一事一議

會議要點：主持人控制節奏

一事一議，並不是說一次會議裡面只能討論一件事情，而是說會議中討論事情聚焦，不要東拉西扯。

另一方面，面對會議主題偏移的情況下，主持人必須站出來，將眾人匯入正軌。

舉個例子：之前Java和Go需要做技術棧二選一合併，如果主題是Java和Go選那一個，優劣是什麼？

如果一個資深架構師，大談特談PHP是世界上最好的語言，那麼在這次會議上都不能讓他得逞，可以在這次技術棧選擇結束後，比如已經選了Java後，再新開一個話題使用PHP會不會收益更高。

這就是主題聚焦，我們如果說產品體驗就不要強調實現難度，我們如果聊實現難度，就不要扯微信怎麼行，主持人要控制節奏。

工匠精神

也會有些Leader，雖然也是在同一主題深入，但是他的尺度拿捏也會導致大家很痛苦，這裡引出一個要點：

會議要點：不要在多人會議上追求完美的問題解法

舉個例子，線上出了一個BUG，分析下來是因為並行沒加鎖，這個時候可以更進一步討論Code Review的重要性，以及流程如何設定是正確的，或者準備出一個並行的培訓也毫無問題。

但是主持人進一步想討論CodeReview的流程該如何設計或者並行有幾個技術點，每個技術點到底是怎麼樣的，那麼就是浪費大家時間了...

因為，為了更好的落地，流程機制的設計要考慮很多場景；其次並行的培訓材料也需要整理很多資料和案例，這些都不是一次會議的內容，如果要繼續展開，首先是準備不足質量低，其次未必是所有參會人都感興趣。

另一個場景是，專案負責人工作比較細緻，在過專案進度時候，總喜歡連續問各個埠的細節，導致會議時間過長，這雖然也是圍繞專案進度展開，但如果依次討論各個埠細節，會導致其他人的時間被浪費，這種工匠精神也要注意。

上層角色如果時間無規劃、工作無條理，生活無規律，就會陷於細節導致各種混亂，最終結果可能是眉毛鬍子一把抓，那真正的全域性事物可能就沒精力關注了。

主題過大

比主題偏移更惱火的是主題過大，主題過大首先容易導致討論無法開始，無病呻吟會導致會議冗長無結果，更重要的是容易演變成一場散播焦慮的會，這裡的點是：

會議要點：不要在會議室提出主題過大的話題，也不要在人多的會上散播焦慮

舉個例子，如果問題是如何將1000w代金券花完，不能每次會議一開始就，怎麼辦，時間馬上就到了，1000w還不知道怎麼花？這種極容易變成散播焦慮。

取而代之，我們需要分解這些問題，比如：

供應商提供哪些服務，成本怎麼樣；
我們當前有什麼需求，什麼需求可以又服務替代；
我們有多少費用是確定的，多少是不確定的，有沒有兜底方案；

問題過大便無從著手，問題過小便陷入細節，只有問題被切割的足夠大小才能很好的解決問題。

走神

還有些Leader，比如專案負責人，在別人彙報時候總喜歡玩手機、回微信，當別人尋求幫助時候又不得不重複重複再重複，這裡的點是：

會議要點：開會就要認真聽！

會上不認真聽，會後抱怨會議沒效果，不認真聽還想有結果，做夢呢...

總結一下，會議之所以是時間殺手，主要原因是：

一些會議的目的是用來規避責任的，如果沒人拍板就容易扯皮；
一些會議主題不聚焦，東拉西扯，自然耗時費力；
一些會議關注的問題過於細碎，這會浪費大量時間；
一些會議討論的主題過大，不僅無從討論，還可能引發焦慮；
還有一些會議內容沒問題，但是由於會議紀律不好而導致效率低下；

所以怎麼辦呢？

會議設計

會議精神

儘量少開會、開短會，確保每次會議有結果，結果有人跟，結果有反饋，反饋有失效。一般來講，組織會議管理有五項原則：

能躲就躲

根據重要緊急四象限，不重要、不緊急的會議就不開，必須要參加的會議少開。

舉個例子，會議人數越多，會議意義越低，比如技術團隊大了後，週會更像是求助、同步，很難在這種大會上決策什麼重要事情，所以超過30人的週會可以由單週會變成雙週會。

取而代之的是由部門負責人組成10人以內的部門月會，將需要決策的事項放月會上集中處理。

這裡需要注意的是，日會變週會、週會變雙週會甚至月會，並不是之前的週會不開了，而是作為大Leader參與的會議質量需要更高，而每個小組的週會，每個專案組的日會依舊要各自負責進行。

明確會議主題

一個會議有幾個議題，每個議題負責人是誰，提前通知到，到時候就一事一議，甚至分批進入，最大程度節約時間。

會議紀律

重要會議要認真，關手機、不準使用電腦，罰款之類的都可以，保證會議質量。

會議節奏

每個會議都需要指定主持人，需要控制時間，控制話題。

權威發言

重要會議必須有可以拍板的人，如果是權威者需要最後發言，也必須發言。

會議型別

從資訊目的和結果會議可以分為：

1）專案會議：保障專案成果執行；獲取專案資訊；

2）OKR會議：保障OKR成果執行；獲取OKR資訊；

3）團隊週會：管理層保障團隊健康運轉；獲取所有專案資訊，解決跨部門共同作業問題；

4）團隊月會：管理層保障團隊發展方向正確；獲取團隊總體資訊，收集抽象類團隊問題；團隊重點事項決策；

5）CaseStudy+專案覆盤會：管理層保障團隊錯誤規避；獲取團隊執行類錯誤資訊，收集工程或組織問題；

6）幹訓班會議：管理層保障leader認知對齊；團隊文化輸出；

7）專項問題討論會：為解決具體事項而召開的專題討論會，如底層框架確定，移動框架選擇，評優設計等；

8）半年彙報會：管理層保障團隊健康運轉；讓全員瞭解團隊發展狀況，未來發展方向，制度宣發；

暫時只能想到這些，需要大家補充。

通用會議模型設計

效率高的會議大同小異，一般由幾個要素組成：

1）明確的會議主題，要解決的問題；

2）能把握節奏的強力主持人，資訊量較全（聰明點的）的會議紀要者；

3）明確的會議結論或者會議後續；

4）有時間、唯一負責人的todolist；

5）有對會議結論持續追蹤的機制；

6）控制會議總時間，最好不要超過2小時（1小時最佳）；

這裡以大家最熟悉的週會為例，做一個demo，這裡需要回答的第一個問題是週會的主題是什麼？

PS：注意，不同團隊對會議的定義不一樣，這裡只是打樣，不可完全套用。

一般來說，週會是每個團隊一定會存在的一個會議，他是幫助團隊瞭解團隊情況的重要且不可替代的會議，也是一些專案及跨團隊問題暴露的重要場所，所以：

週會是同步團隊資訊，包括專案資訊，暴露團隊問題包括專案問題並求助的重要會議

如果對週會目標的定義是同步資訊、暴露問題及風險，那麼就不能在週會上大談解決方案是其一，其中產生的問題，無論是團隊問題或是專案風險問題或是工程建設問題，都應該指定到相關領域的專家，寫定todolist，每次週會跟進執行情況即可，我們現在週會模板大概是這樣的：

特殊會議

在權責利不清的時候，在上層打架的時候，會產生很多扯犢子的事情，比如：

1）一個專案中會有負責人由於某種原因「缺失」的時候；

2）也有兩個部門之間由於資源問題（可能是內卷，也可能是不想吃虧）而來回拉扯，而專案都岌岌可危的時候；

在參與這種會議或者這種時候，你如果是其中的關鍵角色，雖然這麼說未必很好，請一定做好會議紀要，並且跟多方確認，發出郵件，留下「證據」，這類專案失敗的風險極高，要留下一些材料免責...

節奏控制不好的專案容易耗時費力效率低，並且多數人一頭霧水，這個大家應該有所感受，這類不再贅述。

領導力的另一個關鍵也是能不能把一件大的事情分解為幾個小的模組，讓多數的人有事可做，並且產生好的結果。

戰略意圖暴露

資訊通暢是好事，但是關鍵戰略洩露或者說私密資訊洩露，也會非常致命，特別是對於很多有協調者或者外交家屬性的leader，這裡要分輕重，有些資訊還是不能完全告訴對方，所以在會上不要亂說話！不同團隊對於資訊洩露的標準不一，反正注意就好。

另一方面，公司層面要做一些技術或者說基建防止公司資訊（業務資訊）洩露，甚至是程式碼洩露，一個是防堵一個是找補，真的當這類資訊洩露了的應對措施是什麼需要提前定義。

月會

如前所述，月會跟週會的目標又不一樣，週會更關注日常事務，一般不涉及人事問題，因為週會一般是第一圈層+第二圈層，人數較多，公開評價某人如何如何很不好，一些業務上敏感的資訊也不能完全透傳，容易引發恐慌，畢竟真相可能不好看。

月會一般是團隊第一圈層少數人蔘與，比例在5%左右，目標有：

1）暴露業務問題，跨團隊問題，甚至公司問題，管理層的壓力會部分下放到這個圈層，把業務風險赤裸裸的放出來；

2）暴露團隊人員類風險，梯隊問題，核心人員離職問題；

3）業務建設、工程建設情況，在月會中佔有很重的比例，而且必須持續投入；

4）問題專案覆盤，團隊問題暴露，與週會大體相同，但是這裡會更徹底一些，可能會將遮羞布扯下來，也會討論應對方案，好的案例會作為幹訓班材料；

按照以上目標做材料整理，會更希望做資料化的呈現而不是空口無憑，總之月會規格會高很多。

總結

最後總結幾個會議要點是：

會議todolist責任歸屬到個人；
需要決策的會議需要有能拍板、敢於拍板的人；
一事一議，並且主持人要控制節奏；
不要在多人會議上追求完美的問題解法；
不要在會議室提出主題過大的話題，也不要在人多的會上散播焦慮；
重要會議就要認真聽！

好了，今天的分享就到這，喜歡的同學可以四連支援：

想要更多交流可以加微信群：