會議管理心得記錄

(注： 因爲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. 會議前，組織者須要爲會議花時間準備
2. 會議前，參與人員須要進行必定的學習和準備
3. 參會人員工做被打斷帶來的成本。（因爲程序員工做的特殊性，有些文章提出，程序員工做被打斷後要大約1個小時才能從新進入狀態）

這些成本有不肯定性和偶發性， 你們能夠根據本身的經驗和狀況大概算一下。

除了考慮單個會議的成本外，還須要考慮會議成功與否，由於若是會議失敗，就意味着這個會議的成本投入所有或部分白費了，可能還要另外再開一個會。

通常會議有幾種結果：

1. 按時結束，並能完成既定目標，那麼這個會議是很是成功的；
2. 能完成既定目標，可是比計劃佔用了更多時間，也算勉強成功；
3. 按時結束，但未完成既定目標，那算是通常的、可接受的失敗；
4. 即超出了原定時間不少，又沒有完成既定目標，那麼這個會議就比較失敗了。

因爲會議的成本不低，公司想下降成本，員工想少加班，因此咱們要進行會議管理。

會議的目標是經過討論來解決問題，因此會議管理的目標實際上是下降解決問題的成本。咱們經過如下兩點來實現這個目標：

1. 縮短單個會議時間，提升會議效率
2. 提升單個會議成功率

在說如何具體如何作以前，我想先說說我認爲比較常見的幾種失敗會議。

（PS:爲何我要花那麼多篇幅在這一節呢？ 由於我以爲，不少問題，要解決起來並不太難，難的是要意識到那是一個問題。）

失敗會議

場景一

在我第一家公司時，咱們開發團隊在深圳上班，經理在香港上班。

經理每週會過來找咱們開會，瞭解咱們的狀況。有時也討論幾個問題。因爲通常每週都有，暫時稱其爲週會吧。

週會上，討論問題時常常跑題和閒聊，等問題討論完也不捨得結束會議。

討論完問題，經理會和咱們說下公司的美好前景和接下來的宏大計劃，還有心靈雞湯等等。

常常一開就是一成天的會。

剛開始，每次開完這種會，都感受精神抖擻，像打了雞血同樣，工做更有幹勁了。

可是時間久了，每次開完會，該作的工做仍是要作，反而由於開這種會，要加更多的班了。

場景二

在一個解決方案的研討會議上，一羣開發人員脣槍舌戰，討論得面紅耳赤。 在通過數小時的辯論後，終於一致承認了某個解決方案。而後散會。

散會後沒有寫會議紀要，也沒有讓參會人員審覈會議結論，散會後就各忙各的了。

一個月過去了，當時的參會人員已經執行了當時的解決方案一段時間，可是慢慢發現一些問題，你們就又開了一個會。

在這個會上，你們都說依然承認一個月前定下的解決方案，可是不一樣的人對該解決方案的解釋卻不一致。 

有些是由於時間久了，記憶出現誤差， 有些是當初的理解就和別人不一樣。

而後又辯論一遍，並且會後依然沒有記錄和審覈。

場景三

某開發團隊就一個目的，定了會議議程並組織一個會議。 該會議要討論並解決3個問題，爲期1小時。

開會時第一個問題就討論了1個小時，並且還沒解決。

而後你們堅持把3個問題都討論完，已經花了3個多小時。

討論完後，某爲成員又想到一個問題並提了出來，你們立刻就這個新問題進行討論。

在筋疲力竭的狀況下再堅持1個多小時把新問題也討論完了。 

終於散會了。

以上是我我的工做中遇到比較多的狀況。固然失敗會議的狀況各類各樣，沒法一一列舉。

如何進行會議管理

這裏說的會議管理，主要是討論會議組織者須要作什麼以及怎麼作。
可是會議要開的好，光組織者作得好是不夠的，也會議參與人員的配合才能獲得好的效果。 因此下面也會偶爾說起一些須要參與人員配合的狀況。

我認爲要開好一個會議， 不光是開會的時候要有各類技巧和注意事項，開會前準備和開會後的工做也一樣重要。

1. 會議前

以前提過的我我的評價會議成功與否的標準，主要看是否實現了會議的目標，是否解決了會議打算解決的問題。

因此首先，咱們要有一個須要解決的問題。

而後，咱們要問本身，是否真的須要開會來解決這個問題？ 有時可能只須要兩三我的私底下討論一下就能解決問題，未必都須要開會。

若是確實須要開會，有了要解決的問題，咱們的會議就有了目標。

有了目標後，咱們須要考慮爲了實現這個目標，須要哪些人蔘與討論，即參會人員。

因爲會議成本主要是人力成本，因此咱們應該嚴格控制參與會議的人數。我認爲以解決問題爲目的的會議不須要旁聽人員，即參會人員都是會參與討論且意見均可能被採納的。不參與討論或意見不會被採納的人員就別邀請進會議了，那只是浪費你們時間。最忌諱的就是有事沒事拉一大幫人進會議室。

會議的目標會是解決某個或某幾個問題。而後咱們須要根據問題的大小和複雜度，設定一個打算用來解決這個問題的時間限制。

大部分會議不會只討論一個問題，當須要討論多個問題的時候，能夠根據要討論的問題之間的關係、每一個問題的複雜度等，定出問題討論的順序。

此外，要解決的問題可能會有些相關的資料，須要整理這些會議資料，以附件的形式添加在會議邀請中。會議資料可能包含目標的信息、解決方案的線索等等。有些會議資料是須要參會人員在開會以前先學習瞭解的，對於這些資料，最好在會議邀請中註明。

以上幾點完成後，就能夠作會議前準備的最後一步了，就是會議邀請。 通常我是以郵件的方式來邀請會議，固然用其餘形式也能夠。

會議邀請中須要包含上述準備好的信息，以郵件爲例：

1. 會議主題 - 本次會議要解決什麼問題
2. 會議時間
3. 會議地點
4. 會議議程 - 即上述說的會議目標、討論順序以及討論每一個問題的時間限制
5. 參會人員
6. 會議資料 - 若須要參會人員提早學習的，須要註明。

對於會議組織者來講，以上是我能想到的會議前準備的各個點。固然這並不能涵蓋全部會議，不一樣的會議根據其特殊性，可能要準備得多一點或者少一點， 咱們根據實際狀況處理就好。

做爲參與者，若是有須要會議前學習的資料， 爲了會議效果更好，也須要儘可能配合組織者，進行必要的學習和準備， 由於其實這也是在節約本身的時間和提升本身的時間效率。

2. 會議中

會議中的注意事項其實很少，可是倒是比較難實際操做的。會議進行中，會議組織者須要作的事情主要有三點：

1. 儘可能按照會議議程進行會議
2. 儘可能讓參會人員圍繞會議當前議程進行討論
3. 記錄每一個議題的結論，若沒有結論，應記錄關鍵信息（在後面再細說）以供下次會議繼續討論

會議中，咱們會按照議程一個個議題進行討論，每一個議題都是一個問題。通常咱們討論一個問題，須要先分析問題的各類特色和信息，儘可能拆分問題以便將一個大而難的問題拆分紅多個小而容易解決的問題。

討論問題時，通常不多一下獲得最終答案，而多數狀況是跟咱們中學時作數學題相似，要一步步推導直至獲得結論。 討論問題時，咱們會得出多箇中間結論，咱們會一致承認這些中間結論，再一塊兒基於中間結論繼續向下推導。每一箇中間結論都給咱們提供更多關於問題的信息，這些信息都能幫助咱們得出最後結論。

關鍵信息: 即上面提到的問題的各類特色和重要信息，以及最後一個你們都承認的中間結論。這樣下次會議你們能夠接着討論。

上面第一點提到了「儘可能」按照議程，由於實際狀況老是多變的，若是某議題已經到時間，可是討論明顯已經進入尾聲，立刻就能獲得結論，那麼咱們不該該打斷該議題的討論， 而應該讓其順利獲得結論，再進入下一個議程。
但若是某議題看起來離獲得結論還有不短的距離，除非這個議題沒結果後續議題就沒法討論，或該議題比後續議題重要不少， 那麼建議將當前議題的中間結論和關鍵信息記錄下來， 而後轉入下一個議題。

關於第二點，其實能夠用簡短的話進行歸納， 就是： 避免會議失控。
開會很常見的狀況就是會議失控，你們本來爲了討論一個問題，因爲各類緣由，可能出現如下狀況：

1. 跑題 - 聊着聊着說到其餘事情上並且短期內回不來了，也沒有人負責組織會議，來把話題拉回來。跑題有時是變成與工做無關的閒聊，有的是跳到聊另外一個問題去了。
2. 無心義的爭論 - 對一些次要的對解決問題不起太大做用的細節進行無休止的爭論，各人不肯退讓，甚至到後來只是爲了爭論而爭論，不只阻礙議程的完成，常常出現無心義爭論還可能影響團隊和諧。

跑題跑到其餘問題上的狀況是比較常見的，例如討論問題A的過程當中，發現了另外一個有一點關聯的問題B，可是問題B對解決問題A不起什麼做用。這時，咱們不該該想到問題B就立刻切換到問題B的討論上，若是問題B是個重要的須要解決的問題，咱們能夠記錄下來，另起一次會議來解決問題B。 這能避免會議時間和議程的失控。

會出現這些問題，通常是因爲會議缺乏一個「主持人」，即會議組織者。會議組織者須要在有人明顯跑題、進行無心義爭論時進行干預，讓會議迴歸本來的議題。 在議題明顯超時時，要果斷的組織進入下一個議題。

會議組織者的任務就是讓會議儘可能按時結束， 會議過程讓時間儘可能都花在解決問題上。這麼作是爲了達到以前提到的會議管理目的：

1. 縮短單個會議時間，提升會議效率
2. 提升單個會議成功率

剛開始這麼作時，很容易出現時間到了議題還沒討論出結果的狀況，但這是必經的過程，由於團隊還習慣於沒有時間限制的會議，他們能夠海闊天空的暢所欲言，沒必要擔憂時間不夠用，也不會擔憂浪費了你們的時間。 可是當團隊慢慢習慣於有時間限制的會議後，就像習慣於有開發計劃的項目同樣，你們會逐漸聽從有時間限制進行會議，會有意識的避免閒聊、跑題、廢話、無心義爭論等浪費你們時間的行爲。

當你手機只剩20%的電時，你確定會把這20%的電只用在最重要的事情上。

固然，對於會議組織者，每一個議題的時間制定也是須要慢慢總結經驗並調整的，若是你發現制定一個小時來討論一箇中等複雜度的議題，老是討論不完，並且會議中你以爲本身已經組織得足夠好了，那麼你應該調整你制定的時間限制，在下次組織會議時，能夠適當增長相似複雜度的議題的討論時間。

議題的討論時間限制太短，就跟項目開發計劃時間太短同樣，由於本來就不可能完成，這個限制會變得沒有意義。

可是對於已經制定好的會議議程，建議仍是嚴格遵照。

3. 會議後

若是會議前、會議中，都已經作得很好了，是否是工做就結束了呢？
固然不是！

會議的產出是各議題的結論或解決方案，這是通過討論並能獲得你們承認的，是參會人員這會議期間的勞動產出。
但因爲不一樣人的理解極可能不一樣，人也會隨着時間流逝而忘記一些細節甚至徹底記錯， 因此，咱們須要會後整理會議紀要。會議紀要可能會包含這些內容：
1.對於有結論的議題，要清楚寫明結論的詳情，詳情可能包括：如何解決問題、如何執行、誰負責執行、什麼時候應該完成等。
2.對於還沒結論的議題，須要記錄問題的關鍵信息，該問題已解決的部分和未解決的部分分別有哪些。
3.新發現的問題，是否須要再開一個會解決，大概什麼時候開會、誰須要參加等等。

會議紀要的做用不單是記錄，更重要的做用的避免歧義。 因此會議紀要寫好以後，須要讓全部參會人員進行審覈，若發現理解存在歧義，須要進行討論和修正。 以實現你們對會議結論的理解基本一致。

在審覈事後， 有會議紀要的存在，也能促進會議結論的執行。

根據會議性質不一樣，會議紀要的內容可能截然不同，可是會議紀要仍是頗有必要的。 會議紀要須要記錄會議中的重要結論，我認爲若是會議的結論不寫進會議紀要，跟沒開過會沒什麼分別。

就我我的而言，我不是一個記性好的人，並且工做中天天要思考和處理各類問題，我不可能牢記每一個問題的來龍去脈，也記不住每次會議的過程和結論， 因此我須要將這些結論寫下來可供我往後查看。 我不須要佔用大腦的容量來記錄這些，給大腦騰出點空間來思考。 我把個人大腦想象成固態硬盤，而各類文檔是我外接的機械硬盤。

結尾

這篇文章斷斷續續寫了好久，能想到的基本都寫下來了，主要爲了供本身記憶和往後回顧。 寫的不太順暢、也不夠簡潔，功力還很欠缺。博客園的markdown效果也很不滿意。往後再慢慢補充完善。

注： 因爲markdown效果太不滿意，故另外寫了一份非markdown版本的，內容都同樣，只是添加了些排版，之後的更新也主要針對非markdown版本，連接請點：會議管理心得記錄（非markdown版）

謝謝觀看，

2016.10.31