據說程序員都討厭開會，不知道是不是都，但我確實也不喜歡。「小道消息」的 Fenng 曾經寫過在阿里的后兩年，他負責數據庫團隊時，每周會議也是多到讓其感覺無法忍受。程序員討厭寫文檔是出了名的，但討厭開會的程度是討厭寫文檔的立方，以上推論來自漫畫《神秘的程序員》，如下：

有哪些會？

當我打算寫這個主題時，反思了下過去都參加過哪些會議，發現有時會莫名其妙的就參加了一些完全無意義的會議。下面我們先看看一般程序員都會碰到哪些會議。

需求會

這類會議一般是產品或項目經理召集，組織參與項目的程序員一起討論需求并確定排期。這類會議容易出的問題是，程序員到了會上才***次知道需求，并陷入到需求細節的無休止討論中。更好的方式是提前讓程序員詳細了解需求，會上只需敲定排期并讓互相有協作依賴的程序員之間達成一致和形成承諾。

討論會

這類會議的場景比較廣泛，比如：項目進行過程中同組程序員之間就設計或實現的討論，或與其他組項目合作人之間的討論等等。這類會議容易出現的問題是臨時把一堆人拉到會上，然后陷入混亂的自由討論，失去焦點。

還有一類討論會叫頭腦風暴會，也是容易把一堆人拉到會上，開動頭腦風暴。如今遺憾的領悟到這是最沒效率也沒效果的方式。頭腦風暴會需要就待解決的問題讓參與人員提前準備，搜集或閱讀材料，不同人從不同角度各自提出自己的觀點或方案，然后到了會上將所有觀點和方案列出來，再開動頭腦，碰撞連接一下，看看能不能風暴出一些新的觀點或方案去有效解決問題。

周例會

一般來說一個部門或小組都會每周開個例會，例會容易被當作日常的例行工作而不被重視。例會應該有固定的時間和議程，而且例會是一群經常一起工作并熟悉的人開會。雖然開例會的人都在同一個部門，但并不意味著他們都會相互合作完成同一個項目或事情。所以，例會是通過了解各自工作來完成了解整個部門或小組工作進展的機會，而不是每周固定的休閑時光。當然我們也可以在每周的例會留出一段自由討論時間，可以暢所欲言，增加工作之外交流。

除了周例會，有些實施敏捷方法的團隊也會開每日站立會，每日站立會的一般內容是：

• 昨天干了什么

• 今天計劃干什么

• 遇到了什么障礙

每日站立會議的主要目的是讓團隊成員互相交流互通工作情況，而不是為了讓經理們了解情況而召開的會議。每日站立會不是一個團隊的人站一圈各自說下工作情況，因為曾經發現彼此并不關心對方工作內容的人站一圈開這個站立會，其意義何在？

分享會

部門內、公司內或行業內都會有各類不同規模分享會，想清楚你為什么要去參加一個分享會？一般來說我只有兩個原因，我對分享的內容感興趣，這應該是大部分人參會的原因。另一個，即使分享內容我已經很熟悉，那么參會的原因一般就是對分享人感興趣，想要去通過這個分享了解分享人。

還有一種情況可能是礙于面子參加一些完全沒興趣的分享會，恩，這種還是盡量規避吧。

臨時會

總會碰到這種情況，突然有個人過來叫你臨時去參加個會，然后你就一臉懵逼的去了。這種會似乎屬于身不由己，不好規避，這類會議多是非計劃性的任務驅動型會議。英特爾前 CEO 安迪·格魯夫說過：

在現實中，有 20% 的情況還得靠任務導向會議來解決。但如果經理人將超過 25% 的時間用在應急的任務導向會議上，這個組織就一定有了毛病。

這種類型的會議隨時召開，而且會針對具體情況產生決策，若這種臨時緊急的任務驅動會議太多了，那問題肯定出在平時的工作中。

總結會

可能是項目上線或產品發布后的總結會，也可能是線上故障后的經驗教訓總結會。我以前開過的很多總結會都變成了領導的總結會，關于這類會大家有什么好想法嗎？

參加會議

反思了上面參加過的各種類型會議，然后我得出了一個以后參會的原則：若我沒有在會議上發言的潛在可能，就不需要參加。

發言的可能表明你參會是存在主動因素的，需要通過發言（建議、意見、詢問、交流）去取得收獲。但并不意味著每次參會都需要發言，只是說存在這種可能。比如，參加一個分享會，可能你是想去交流和詢問了解一些東西，但可能在分享的過程中你已經有了答案，就沒必要發言詢問了。

有時你會收到一些莫名的會議邀請郵件，只是因為收件人中有你的名字，就會不自覺地在會議自動提醒彈出時跑去參會。其實在會上發現好像和自己又沒多大關系，但進行到一半又不好離場，只好自顧自的玩起了手機，是不是很熟悉的場景？

即使一個臨時會，看似完全被動，也可以問問通知人為什么需要你去？很可能通知人會告訴你是 Boss（老板或上司）找你，他也不知道原因？好吧，這種情況只好去了，這里的問題不在你，而在你的 Boss 身上。Boss 可能只是找你咨詢一些細節情況，也可能需要咨詢你的意見。總之一種完全沒準備的臨時會議是不利于效率和效果的。

一個正在埋頭編程的程序員，突然被通知開個臨時會議，程序員還可能陷在前一份編碼工作的細節中沒切換出來，導致后續的臨時溝通討論都比較低效。所以，若不是特別緊急，盡可能把各種會議安排在一天的開始或結束前，為程序員留出整段的集中時間來進入狀態和脫離狀態。

組織會議

你可能沒想過，有些程序員把開會當作編程一樣來設計。

模式

現在后端分布式領域流行微服務架構，所以我也主張微會議，一個會議聚焦一件事，除了分享會，不要召集太多人來參會。人越多可能越混亂和無效，效率損失也很大。

架構

設計程序時需要仔細選擇組件，所以可以像編程一樣設計會議，剔除多余的資源消耗，保持簡潔。仔細分析每個潛在的參會人是否對本次會議有價值，我們不需要一個冗余的玩手機的參會人。如果你發現你的會議上多了一個玩手機的家伙，那不是別人的錯，而是你的錯誤。

實現

在正式編碼前，我們早已在頭腦或紙上做好了設計，只是用代碼將其表達出來。所以，正式開始會議前，請確保參會人都做好了準備，而不是到了會議桌前才開始想這個會議需要解決什么問題？

會議的過程也需要掌控節奏，集中主題，避免發散跑偏。代碼實現時總會出現超出當初設計的一些現實問題沒考慮到，會議中也可能突然冒出一些新想法，和編碼不同，對這些新情況若發現有價值但又無法短時間討論清楚，可以先記錄下來，列入下次會議的議程，而避免本次會議過度發散，導致會議延時，主題分散，沒有結論。

...

把開會當作一個程序問題來分析后，我發現開會其實也沒那么討厭了。