前言
小王同學曾經有一位同事戲稱：對於網際網路人，工作時間是用來溝通（開會）的，而休息時間才是用來寫代碼的。
今天我們來探討一個很多程式設計師日常工作中，經常碰到卻會帶來困擾的話題：開會。
頭疼的開會
有一次，我聽到兩個程式設計師在聊天。一個資深程式設計師說：「還是晚上好，我可以一門心思寫代碼」，另一個年輕程式設計師不解地問：「你白天也可以寫啊。」
資深程式設計師很無奈，「我倒是這樣想，可是白天參加那麼多會，哪有工夫啊！我的代碼就只能加班寫了。」這段對話聽上去讓人有點心酸，但這種現象，確確實實廣泛存在於程式設計師的日常工作中，尤其是你經驗豐富又在一個大組織中工作，這幾乎成了你的宿命。
在這些程式設計師的認知中，開會太多影響了他們寫代碼。你以為我想討伐開會嗎？並不是，開會本身並沒有錯，因為開會的本意是將大家組織起來解決問題。但請你回想一下，你參加的會議有多少解決了問題呢？
開會是為了解決問題，但真實情況卻是開了會又沒有解決多少問題，這真是一個奇特的矛盾。
回想一下，你參加過的會議裡面，有沒有效果特別好的呢？在我職業生涯中，凡是效果特別好的會議，基本上都是用來做信息同步的。比如，領導宣布一個事情，這種會議幾乎不會浪費時間。宣布消息，大家收到消息，結束。
那效果不好的會議是什麼樣呢？幾乎都是那些討論會，你一言我一語，每個會幾乎無一例外，都有幾個擅長打岔的，這個會基本上都會跑偏，時間就會這樣一分一秒地流逝了。
我給你舉個例子，我之前參加過一個上線計劃的評審會，這個團隊的負責人要把相關利益方都召集起來，其中包括上下遊可能會受影響的團隊、測試、運維等等，一個不大的會議室裡擠滿了人。
這個負責人剛開始講方案沒幾分鐘，下遊團隊的負責人就站出來問：「這個方案為什麼要這麼做？我擔心會對我們系統造成影響。」講方案的人只好停下來解釋。結果是越解釋，細節越多，雙方你來我往，一個方案評審會，就轉變成一個技術討論會了。
測試和運維的同事本來是想來聽技術方案，以便為後續的工作做準備的。看著雙方的討論，一臉無奈，因為他們知道，方案沒確定好，所有的事情還是下回再說吧！
怎麼樣？是不是很熟悉的感覺。為什麼會這樣？因為他們選錯了溝通方式。
開會是一種重量級的溝通，幾乎是我們日常工作中最重的。它有很強的儀式感，所以，大家相對來說會很重視。而且會議通常會牽扯到很多人，尤其是與這個事情相關度不那麼高的人。
你可以想一下，有多少次開會，你是在精力集中的？如果你是高度集中的，那恭喜你，你是高效地參與其中。但更多時候，你可能神遊天外，因為討論的內容可能與你關係不大，或者你已經聽不懂了，你坐在那裡的唯一原因是，主持人還沒宣布會議結束。
用開會這種重量級的方式討論問題，就好比殺雞用了牛刀，這是不恰當的。那該怎麼解決這個問題呢？很簡單，殺雞用雞刀。
輕量級溝通
實際上，真正在會議上能夠積極參與討論的人並不會覺得會議是浪費時間，因為高度參與其中，人是進入到心流狀態的，時間流逝很快。覺得浪費時間的，往往是沒有參與其中的人。
換句話說，會議之所以給人留下如此不堪的印象，一個重要的原因是，真正參與討論的人並不多。所以，我們換個角度思考一下，只要把這些真正參與討論的人拉到一起討論不就好了？
所以，改善會議的第一個行動項是，減少參與討論的人數。
有人會說，我這個討論有好幾個議題，每個議題要不同的人參與，那你要做的是，分別找這幾個人專門討論，而不是把大家放到一起。
不知道你發現沒有，在討論行動項的時候，我用的是「討論」，而沒有提到「會議」兩個字。我之前說過了，會議是一種重量級的溝通方式。所以，我們會傾向於選擇一種輕量級的溝通方式，比如面對面溝通，這樣一來，每個人的壓力就會小很多。
相比於會議的形式，面對面溝通因為注意力有限，參與的人數不可能太多。也因為參與的人數相對少一些，每個人的投入也會更多一些。
所以，我們的第二個行動項是，如果你要討論，找人面對面溝通。
一旦理解了這些改進方式，我們就可以改進自己的行為方式。如果有一個問題需要討論，我要做的是，分別找到相關人針對關心的主題進行討論，然後，我把討論的結果匯總再去徵求大家意見。如果大家達成一致了，我才會選擇開會。
這個時候，開會的目的不再是討論，而是信息同步：我準備這麼幹了，相關各方已經同意了，知會大家一下，結束。
站立會議
開會並非都是不好的，一些信息同步的會還是有必要的。
舉個例子，有一種實踐叫站會（Standup）。很多公司都在實踐它，站會甚至成為每天的開工儀式。一般的做法是，早上大家來上班了，先開一個站會，讓大家同步一下昨天的工作，然後開始今天的工作。
有的人一聽到站會這個形式就會皺起眉頭。如果是這樣，多半是你的團隊「站」錯了。
你知道，這個會為什麼是「站」會嗎？因為按照一般人的習慣，站的時間不會太長，因為站的時間長，累啊！所以，如果站會超過 10 分鐘，你的站會一定是錯的。
也許你會說，這點時間恐怕不夠給我們站會吧？因為每個人都有一大堆要說的。請問，你覺得其他人說那麼多，你關心嗎？現實是，一旦一個人說多了，跟你關係又不大，你就開始思維發散了。
所以，在總長固定的情況下，每個人發言的時間一定是有限的。在有限的時間內，你能說什麼呢？我建議你只說三件事：我昨天做了什麼？我今天打算做什麼？我在過程中遇到了什麼問題，需要請求幫助。
「做了什麼」 ，是為了與其他人同步進展，看事情是否在計劃上。一旦偏離計劃，請主動把它提出，這樣，項目經理可以過問，因為這會涉及到是否要調整項目計劃；
「要做什麼」 ，是同步你接下來的工作安排。如果涉及到與其他人協作，也就是告訴大家，讓他們有個配合的心理準備；
「問題和求助」， 就是與其他人的協作，表示：我遇到不懂的問題，你們有信息的話，可以給我提供一下。
這三件事都是與別人相關的，幾句話快速說完，結束。因為這些事情與別人相關，所以，大家的注意力可以相對集中一些。
你或許會問，如果我的問題很複雜，需要討論該怎麼辦。對不起，那是另外一件事，你可以在站會結束之後，找相關人去討論，不要在這個會上浪費大家時間。在站會上，你只要在問題和求助中告訴大家，你有一個問題，需要相關人討論，結束。
為了讓大家保持注意力集中，我的一些團隊還用過發言令牌的方式。比如，找一個毛絨玩具，誰拿到「令牌」誰發言，然後，隨機地扔給一個人，一旦這個人走神，大家一下子就能發現了。
一些有趣的方式、短暫的時間，以及與所有人相關的事情，因為滿足了這三點，所以普遍來說，這種站會效果還可以。
關於站會，有一個典型的錯誤是，有些團隊把站會開成了匯報會。項目負責人指定一個個輪流發言，說的人都向負責人在匯報工作，其他人自然就容易走神了，因為事情與己無關。
當團隊很大時，更應該做的是把團隊拆分了，因為你不太可能與 20 個人緊密地工作在一起。沃頓商學院曾經做過一項研究，5-12 個人是一個恰當的團隊規模，每個人在其中都能發揮自己的重要作用。
最後
開會是很多程式設計師的困擾，太多的會議甚至會影響到你工作的進展。開會的本意是為了解決問題，但實際上，大多數會議並不能很好地解決問題。因為會議是一種重量級的溝通方式，很多人參加會議時，並不能很好地參與其中。
如果你想用會議的形式與別人討論問題，最好放棄這種打算，面對面的溝通是最好的方式。因為面對面溝通很輕，人數相對少，每個人參與度就會高很多。基於這種改進，我們可以把大部分會議都改成信息同步的會，效率就會得到提高。