(注： 由於markdown效果太不滿意，故另外寫了一份非markdown版本的，內容都一樣，只是添加了些排版，對排版比較敏感的，歡迎看非markdown版本。以后的更新應該也主要針對非markdown版本，鏈接請點：會議管理心得記錄（非markdown版）)
前提
本文說的會議特指有開發團隊成員參與的會議， 包括但不限於開發、設計、測試、運維、管理崗位的成員。 因為不同工種和行業都有其特殊性，我是一名程序員，並不太了解其他工種和行業的具體情況，不敢妄言。
術語定義
會議： 本文中的“會議”指的是當團隊有問題需要解決時，並且希望通過會議的形式，讓若干個團隊內或外的人員參與進來，通過開會討論的方式找到解決方案。這種會議包括項目總結會、頭腦風暴、周會等。不需要進行討論、不是為了給問題找出解決方案的會議不在本文討論范圍之內，如信息宣布的會議（如宣布領導的決策）、表彰大會、畢業典禮（任何一人說眾人聽的都不算）、大部分公司年會。
公司成本： 指公司為了聘用一名員工需要投入的成本，該成本高於員工月薪，因為一般還要包含社保、公積金、辦公用品、辦公場地等成本。
為什么要進行會議管理
較多人認可的一個事實是：會議是一種工作中成本比較高的集體活動，其中較明顯的成本包括：參會人員會議時間成本，會議室的場地成本。
舉例說明，某開發團隊遇到一個問題需要討論解決， 一名高級工程師創建了一個時間為2小時的會議，需要自己和另外四名中級工程師參與。
我們來大概計算一下這個會議的成本。
要計算這個會議的大概成本，只要計算出全部參會人員的公司成本即可， 因為公司成本包含了場地成本，所以不必另外計算會議室成本。
假設高級工程師的月薪是HighSalary，中級工程師月薪MiddleSalary。
再假設:
HighSalary = 2W;
MiddleSalary = 1W;
假設公司花在員工身上的成本為員工月薪的1.5倍（實際上往往不止）。
一個月一般有21-22個工作日, 這里我們按21.5個工作日算。 每個工作日算8小時。 那么最終會議成本cost就等於：
cost = ((( HighSalary + 4 * MiddleSalary ) * 1.5) / 21.5 / 8 ) * 2;
==>
cost = 1046.5元； // 約等於
這個2小時5人參與的會議，成本1000元多一點點，好像還不是很貴。
當然我上述的月薪都是假設的，可能比市場價要低，大家可以根據自己公司的情況換算一下， 看是否超出了你們的預料。
當然這是對公司的成本，開發人員可能不太敏感。 那么開發人員有什么成本呢？
在有項目計划或進度壓力的情況下，如果開了一個效果不理想的會，為了完成原定的工作目標，往往開多長的會，就代表你要加多久的班。（很多團隊制定開發計划時是沒有把會議的時間算到計划中的）
前面說了，這是會議的明顯成本，其實還有一些不明顯的成本。例如：
- 會議前，組織者需要為會議花時間准備
- 會議前，參與人員需要進行一定的學習和准備
- 參會人員工作被打斷帶來的成本。（由於程序員工作的特殊性，有些文章提出，程序員工作被打斷后要大約1個小時才能重新進入狀態）
這些成本有不確定性和偶發性， 大家可以根據自己的經驗和情況大概算一下。
除了考慮單個會議的成本外，還需要考慮會議成功與否，因為如果會議失敗，就意味着這個會議的成本投入全部或部分白費了，可能還要另外再開一個會。
一般會議有幾種結果：
- 按時結束，並能完成既定目標，那么這個會議是非常成功的；
- 能完成既定目標，但是比計划占用了更多時間，也算勉強成功；
- 按時結束，但未完成既定目標，那算是一般的、可接受的失敗；
- 即超出了原定時間很多，又沒有完成既定目標，那么這個會議就比較失敗了。
由於會議的成本不低，公司想降低成本，員工想少加班，所以我們要進行會議管理。
會議的目標是通過討論來解決問題，所以會議管理的目標其實是降低解決問題的成本。我們通過以下兩點來實現這個目標：
- 縮短單個會議時間，提高會議效率
- 提高單個會議成功率
在說如何具體如何做之前，我想先說說我認為比較常見的幾種失敗會議。
（PS:為什么我要花那么多篇幅在這一節呢？ 因為我覺得，很多問題，要解決起來並不太難，難的是要意識到那是一個問題。）
失敗會議
場景一
在我第一家公司時，我們開發團隊在深圳上班，經理在香港上班。
經理每周會過來找我們開會，了解我們的情況。有時也討論幾個問題。由於一般每周都有，暫時稱其為周會吧。
周會上，討論問題時經常跑題和閑聊，等問題討論完也不舍得結束會議。
討論完問題，經理會和我們說下公司的美好前景和接下來的宏大計划，還有心靈雞湯等等。
經常一開就是一整天的會。
剛開始，每次開完這種會，都感覺精神抖擻，像打了雞血一樣，工作更有干勁了。
但是時間久了，每次開完會，該做的工作還是要做，反而因為開這種會，要加更多的班了。
場景二
在一個解決方案的研討會議上，一群開發人員唇槍舌戰，討論得面紅耳赤。 在經過數小時的辯論后，終於一致認可了某個解決方案。然后散會。
散會后沒有寫會議紀要，也沒有讓參會人員審核會議結論，散會后就各忙各的了。
一個月過去了，當時的參會人員已經執行了當時的解決方案一段時間，但是慢慢發現一些問題，大家就又開了一個會。
在這個會上，大家都說依然認可一個月前定下的解決方案，但是不同的人對該解決方案的解釋卻不一致。
有些是因為時間久了，記憶出現偏差， 有些是當初的理解就和別人不同。
然后又辯論一遍，而且會后依然沒有記錄和審核。
場景三
某開發團隊就一個目的，定了會議議程並組織一個會議。 該會議要討論並解決3個問題，為期1小時。
開會時第一個問題就討論了1個小時，而且還沒解決。
然后大家堅持把3個問題都討論完，已經花了3個多小時。
討論完后，某為成員又想到一個問題並提了出來，大家馬上就這個新問題進行討論。
在筋疲力竭的情況下再堅持1個多小時把新問題也討論完了。
終於散會了。
以上是我個人工作中遇到比較多的情況。當然失敗會議的情況各種各樣，無法一一列舉。
如何進行會議管理
這里說的會議管理，主要是討論會議組織者需要做什么以及怎么做。
但是會議要開的好，光組織者做得好是不夠的，也會議參與人員的配合才能得到好的效果。 所以下面也會偶爾提及一些需要參與人員配合的情況。
我認為要開好一個會議， 不光是開會的時候要有各種技巧和注意事項，開會前准備和開會后的工作也同樣重要。
1. 會議前
之前提過的我個人評價會議成功與否的標准，主要看是否實現了會議的目標，是否解決了會議打算解決的問題。
所以首先，我們要有一個需要解決的問題。
然后，我們要問自己，是否真的需要開會來解決這個問題？ 有時可能只需要兩三個人私底下討論一下就能解決問題，未必都需要開會。
如果確實需要開會，有了要解決的問題，我們的會議就有了目標。
有了目標后，我們需要考慮為了實現這個目標，需要哪些人參與討論，即參會人員。
由於會議成本主要是人力成本，所以我們應該嚴格控制參與會議的人數。我認為以解決問題為目的的會議不需要旁聽人員，即參會人員都是會參與討論且意見都可能被采納的。不參與討論或意見不會被采納的人員就別邀請進會議了，那只是浪費大家時間。最忌諱的就是有事沒事拉一大幫人進會議室。
會議的目標會是解決某個或某幾個問題。然后我們需要根據問題的大小和復雜度，設定一個打算用來解決這個問題的時間限制。
大部分會議不會只討論一個問題，當需要討論多個問題的時候，可以根據要討論的問題之間的關系、每個問題的復雜度等，定出問題討論的順序。
此外，要解決的問題可能會有些相關的資料，需要整理這些會議資料，以附件的形式添加在會議邀請中。會議資料可能包含目標的信息、解決方案的線索等等。有些會議資料是需要參會人員在開會之前先學習了解的，對於這些資料，最好在會議邀請中注明。
以上幾點完成后，就可以做會議前准備的最后一步了，就是會議邀請。 一般我是以郵件的方式來邀請會議，當然用其他形式也可以。
會議邀請中需要包含上述准備好的信息，以郵件為例：
- 會議主題 - 本次會議要解決什么問題
- 會議時間
- 會議地點
- 會議議程 - 即上述說的會議目標、討論順序以及討論每個問題的時間限制
- 參會人員
- 會議資料 - 若需要參會人員提前學習的，需要注明。
對於會議組織者來說，以上是我能想到的會議前准備的各個點。當然這並不能涵蓋所有會議，不同的會議根據其特殊性，可能要准備得多一點或者少一點， 我們根據實際情況處理就好。
作為參與者，如果有需要會議前學習的資料， 為了會議效果更好，也需要盡量配合組織者，進行必要的學習和准備， 因為其實這也是在節約自己的時間和提高自己的時間效率。
2. 會議中
會議中的注意事項其實不多，但是卻是比較難實際操作的。會議進行中，會議組織者需要做的事情主要有三點：
- 盡量按照會議議程進行會議
- 盡量讓參會人員圍繞會議當前議程進行討論
- 記錄每個議題的結論，若沒有結論，應記錄
關鍵信息（在后面再細說）以供下次會議繼續討論
會議中，我們會按照議程一個個議題進行討論，每個議題都是一個問題。一般我們討論一個問題，需要先分析問題的各種特點和信息，盡量拆分問題以便將一個大而難的問題拆分成多個小而容易解決的問題。
討論問題時，一般很少一下得到最終答案，而多數情況是跟我們中學時做數學題類似，要一步步推導直至得到結論。 討論問題時，我們會得出多個中間結論，我們會一致認可這些中間結論，再一起基於中間結論繼續向下推導。每個中間結論都給我們提供更多關於問題的信息，這些信息都能幫助我們得出最后結論。
關鍵信息: 即上面提到的問題的各種特點和重要信息，以及最后一個大家都認可的中間結論。這樣下次會議大家可以接着討論。
上面第一點提到了“盡量”按照議程，因為實際情況總是多變的，如果某議題已經到時間，但是討論明顯已經進入尾聲，馬上就能得到結論，那么我們不應該打斷該議題的討論， 而應該讓其順利得到結論，再進入下一個議程。
但如果某議題看起來離得到結論還有不短的距離，除非這個議題沒結果后續議題就無法討論，或該議題比后續議題重要很多， 那么建議將當前議題的中間結論和關鍵信息記錄下來， 然后轉入下一個議題。
關於第二點，其實可以用簡短的話進行概括， 就是： 避免會議失控。
開會很常見的情況就是會議失控，大家原本為了討論一個問題，由於各種原因，可能出現以下情況：
- 跑題 - 聊着聊着說到其他事情上而且短時間內回不來了，也沒有人負責組織會議，來把話題拉回來。跑題有時是變成與工作無關的閑聊，有的是跳到聊另一個問題去了。
- 無意義的爭論 - 對一些次要的對解決問題不起太大作用的細節進行無休止的爭論，各人不願退讓，甚至到后來只是為了爭論而爭論，不僅阻礙議程的完成，經常出現無意義爭論還可能影響團隊和諧。
跑題跑到其他問題上的情況是比較常見的，例如討論問題A的過程中，發現了另一個有一點關聯的問題B，但是問題B對解決問題A不起什么作用。這時，我們不應該想到問題B就馬上切換到問題B的討論上，如果問題B是個重要的需要解決的問題，我們可以記錄下來，另起一次會議來解決問題B。 這能避免會議時間和議程的失控。
會出現這些問題，一般是由於會議缺少一個“主持人”，即會議組織者。會議組織者需要在有人明顯跑題、進行無意義爭論時進行干預，讓會議回歸原本的議題。 在議題明顯超時時，要果斷的組織進入下一個議題。
會議組織者的任務就是讓會議盡量按時結束， 會議過程讓時間盡量都花在解決問題上。這么做是為了達到之前提到的會議管理目的：
- 縮短單個會議時間，提高會議效率
- 提高單個會議成功率
剛開始這么做時，很容易出現時間到了議題還沒討論出結果的情況，但這是必經的過程，因為團隊還習慣於沒有時間限制的會議，他們可以海闊天空的暢所欲言，不必擔心時間不夠用，也不會擔心浪費了大家的時間。 但是當團隊慢慢習慣於有時間限制的會議后，就像習慣於有開發計划的項目一樣，大家會逐漸遵從有時間限制進行會議，會有意識的避免閑聊、跑題、廢話、無意義爭論等浪費大家時間的行為。
當你手機只剩20%的電時，你肯定會把這20%的電只用在最重要的事情上。
當然，對於會議組織者，每個議題的時間制定也是需要慢慢總結經驗並調整的，如果你發現制定一個小時來討論一個中等復雜度的議題，總是討論不完，而且會議中你覺得自己已經組織得足夠好了，那么你應該調整你制定的時間限制，在下次組織會議時，可以適當增加類似復雜度的議題的討論時間。
議題的討論時間限制過短，就跟項目開發計划時間過短一樣，因為原本就不可能完成，這個限制會變得沒有意義。
但是對於已經制定好的會議議程，建議還是嚴格遵守。
3. 會議后
如果會議前、會議中，都已經做得很好了，是不是工作就結束了呢？
當然不是！
會議的產出是各議題的結論或解決方案，這是經過討論並能得到大家認可的，是參會人員這會議期間的勞動產出。
但由於不同人的理解很可能不同，人也會隨着時間流逝而忘記一些細節甚至完全記錯， 所以，我們需要會后整理會議紀要。會議紀要可能會包含這些內容：
1.對於有結論的議題，要清楚寫明結論的詳情，詳情可能包括：如何解決問題、如何執行、誰負責執行、何時應該完成等。
2.對於還沒結論的議題，需要記錄問題的關鍵信息，該問題已解決的部分和未解決的部分分別有哪些。
3.新發現的問題，是否需要再開一個會解決，大概何時開會、誰需要參加等等。
會議紀要的作用不單是記錄，更重要的作用的避免歧義。 所以會議紀要寫好之后，需要讓所有參會人員進行審核，若發現理解存在歧義，需要進行討論和修正。 以實現大家對會議結論的理解基本一致。
在審核過后， 有會議紀要的存在，也能促進會議結論的執行。
根據會議性質不同，會議紀要的內容可能大相徑庭，但是會議紀要還是很有必要的。 會議紀要需要記錄會議中的重要結論，我認為如果會議的結論不寫進會議紀要，跟沒開過會沒什么分別。
就我個人而言，我不是一個記性好的人，而且工作中每天要思考和處理各種問題，我不可能牢記每個問題的前因后果，也記不住每次會議的過程和結論， 所以我需要將這些結論寫下來可供我日后查看。 我不需要占用大腦的容量來記錄這些，給大腦騰出點空間來思考。 我把我的大腦想象成固態硬盤，而各種文檔是我外接的機械硬盤。
結尾
這篇文章斷斷續續寫了很久，能想到的基本都寫下來了，主要為了供自己記憶和日后回顧。 寫的不太順暢、也不夠簡潔，功力還很欠缺。博客園的markdown效果也很不滿意。日后再慢慢補充完善。
注： 由於markdown效果太不滿意，故另外寫了一份非markdown版本的，內容都一樣，只是添加了些排版，以后的更新也主要針對非markdown版本，鏈接請點：會議管理心得記錄（非markdown版）
謝謝觀看，
2016.10.31