好的開會方式是使籌備輕鬆有效率的關鍵

「開會」非常常見，不少人都有參與會議甚至召開會議的經驗。然而，開會可說是相當左右任務推進的重要因素，認真看待如何開會、事前認真準備會議，絕對會實際省下更多時間、並且在任務成果上有回報。

志工組織開會難度高

組織管理工作中，開會本來就已經是不簡單；在籌備團隊這類大多由志工所組織而成的團體，因為組織相對於公司行號，階層間往往較鬆散與平行，在召開會議的頻率與執行強度上，更容易增加額外的難度，因此也更需要把握每一次開會的機會。

清楚知道自己的會議定位與種類

葛洛夫給經理人的第一課 ( High Output Management ）有一個章節專門在講開會，整理得很不錯，有興趣可以翻翻。

書裡面有提到會議粗分成幾種，社群研討會籌備團隊各組定期「例會」我會偏向把他歸類在 "process-oriented meetings" 下的 "staff meetings"，需要討論的則是屬於 "mission-oriented meetings"。書中提到的開會類型對應到 PyCon TW 籌備團隊目前的行事方式的話，大概可以這樣理解：

• process-oriented meetings - one-on-ones: 盡量讓組員帶意見或問題給你，自己要單向佈達的事情留到 staff meeting 即可。跟自己的組員們 1-2-1 是個對組織長期回報很大的事情，例如志工留存時間長度會比較高、 實質貢獻也會比較大；時間和心力夠的話不妨投資看看。
• process-oriented meetings - staff meetings: 社群研討會籌備團隊各組定期「例會」，組長和組員們定期的內部溝通與討論。有時我會考慮採用類似 office hour 那樣更鬆散、輕鬆一點的方式進行。
• process-oriented meetings - operation reviews: 總召召開的月會，驗收各組工作匯報。
• mission-oriented meetings - 討論特定主題與任務、只有特定與會人士的會議。

這幾種會議提供不同檢視組織的角度，所以組織與專案規模到一定程度以上時，大概四種會議都需要。社群組織通常比較容易忽略掉 one-on-ones ；可以檢查一下自己還少了哪些。

召開會議的目的是確定共識

開會的本質是「確定共識」，無論共識是如何凝聚的，會議在召開與結束時一定要作到這點。任何有礙於「確定共識」的行為都要盡量避免。能夠在短時間內將共識找出並確定下來的會議，就是有效率、好的會議。

共識不等於認同，但一定表示彼此支持決議

每個人的意見總有不合、甚至完全互斥的時候。即使如此，共識仍然可以是「我不同意這個作法有助於我們的團隊目標，但一旦走出這個會議室門口，我就會在行動上支持你」。

所以凝聚共識時，最直觀、也最初的方式是在會議前或會議前，透過優劣劇本討論來選擇到彼此都覺得合理的作法。無法在這上面取得交集時，則可以考慮其他動之以情的方式。

避免冗長的會議就是會議前已凝聚好共識

會議前如果已經將共識凝聚得差不多，會議本身就成為「確定共識」的儀式。這種會議就會很快。

冗長的會議除了讓與會者最後失去注意力、導致決策品質下降以外，長期來說可能會讓團隊成員降低參與會議的意願，進而傷害到團隊資訊流通的程度。

常見冗長的會議來自將「討論」放到會議中、而不是會議「前」。所以避免冗長的會議往往是指開會的時候避免進行「討論」[1]，除非：

1. 這個會議本來就是召集來「討論」的。例如會議召開人真的對要解決的事情不太有頭緒，有點請教其他人或是大家來腦力激盪的意思。
2. 會議召集人邀請來的與會者，每個都有對應的能力與對事情的認知到能夠直接參與討論
3. 討論的「框架」有事先講好[2]，這樣與會者比較有默契可以在什麼時候都有共識彼此離題失焦了該拉回來，比較不容易議而不決。

我自己如果是會議召集人，我通常會在事前就幾乎橋好所有需要「討論」的事情[3]，會議幾乎都是在佈達、確定橫向溝通上彼此都有共識。

PyCon TW 在 2020 的時候，總召把 「幹部會議」 另外獨立出來，讓「志工月會」成為大家（所有志工不限組長）來尬聊，基本上差不多就是在實踐這種精神：「幹部會議」用於討論，「志工月會」用於佈達討論結果和聯絡感情。

我自己在擔任總召時，則是偏好使用可以讓我非同步作業的文字溝通管道，像是使用 email 或是即時通訊平台像是 slack/discord ，事先溝通完畢。「志工月會」用於佈達討論結果和聯絡感情的聚會，以及少數文字比較不方便商量與跨組溝通的事務。

[1] 「討論」的定義：我這邊定義為三分鐘內彼此口語來回還不能達成共識的都算「需要討論」。
[2] 討論框架：六項思考帽、RFC 等等，一下想到這些，還有其他風格的族繁不及被載。
[3] 這當然只是理想上，事實上時間和心力都有限，有些東西還是會偷懶直接放到例會上橋一下；trade-off 可能是至少有橋好預期大概比較難橋的、比較有爭議的議題可能也很不錯了。

準備 Agenda 是體檢團隊執行程度的先行指標

會議召集人如果覺察到自己寫不太出 agenda ，就表示要省視一下自己對專案與團隊掌握度是否不足。

如果都有會前橋好需要凝聚共識的事項，agenda 就會很好寫；如果下筆 agenda 常常有要硬擠或是「最近好像沒什麼進度」的感覺，大概都是沒有完整做好這類會前溝通、多少有點把「待辦事項」留在會議上做的感覺，這種就很容易造成會議氣氛很乾；因為沒直接跟這件事情有關的人大概不太能參與討論，或是要等待待辦完成，就很容易閃神。把待辦事項放到會議上處理，也容易使得會議冗長。

開會時的氣氛

怎麼讓開會氣氛活略、不會太乾、只有你在講話？其實好的氣氛可能往往只是副產物，大家如果手上都實際有任務、有真的在做一些事情，大概大家就比較能夠進入狀況、參與討論，這樣自然氣氛就會起來。這有點像是有實際參與籌備的志工，總是比沒什麼投入的志工，能夠實際交到更多朋友、也往往對彼此有比較深入的認識。

沒有對應監督驗收計畫的放權委任，是領導者的失職

放權與委任是將專案做大的不二法門。任何的放權與委任，都一定要有對應的、雙方都同意的驗收方式。沒有這類驗收方式的放權，是領導者的失職。這樣接近卸責的行為，也有可能讓被委任者覺得自己偏向是被找來「畫押」或是「揹責任」者，而不是「夥伴」，這可能輕則影響士氣、嚴重時甚至會降低彼此間的信任關係。任何會議前或會議中的「分配工作」一定要把握這個原則。

其他小技巧

直接在會議上敲定下次開會時間，這樣可以省去事後調查大家可行時段的困擾。會議中明確指定負責人與對應的 action item，也有助於每個人對於如何執行共識上，有夠具體的理解。

如果這次會議是系列會議第一次召開，在約大家可出席的時間時，只要必要或是核心人員出席即可敲定時間。這類時間必須要公告或是盡量通知所有的 stakeholder；即使他們不方便出席，這類通知邀請會是最基本的尊重。另外每次會議前一兩天可以考慮提醒大家。

出席時間和決定會議共識採用這種方式，是基於社群之事大多是業餘、且彼此角色職責相對平行的情況下，去和執行效率權衡。

業餘時間原本就是稀少珍貴，如果一場會議要邀請超過含主持人五人，大概就會陷入「永遠約不到大家都可以的時間」這種困境。這種類似 Python 語言「 Easier to ask for forgiveness than permission （ EAFP ）」的思維，同樣也可以應用在決策大多數的事情上：如果不是直接跟利益分配、價值觀或意識形態相關的決策，願意執行的人有共識，大概就可以某種程度的公告後下去執行，不用等「某個權威」允許。採用這類思維可以大幅提高社群研討會籌備時的效率，並且在各種事務上 「 release early release often 」。

如果是直接跟利益分配、價值觀或意識形態相關的決策，大概最好是取得所有 stakeholder 的共識後再進行，這是對每一個成員的尊重。

好會議的指標

根據前面的討論，這裡總結一下我們提到，顯示一個會議是否是好會議的指標有：

• 會議召開完後，成員間有共識。
• 共識包括具體負責人與對應的 action item
• 事前的 agenda 安排得很具體
• 時間精準、不會超出預期地冗長
• 任何分配的工作都一定有搭配對應有共識的驗收計畫

作為團隊或專案領導者，會議前好好準備與跟其他成員事先協調、凝聚共識，乍看很花時間，但長遠來說，以專案推進的速度與品質上來看，這類投資絕對是值得的。不好好準備會議就貿然召開，自以為省下的時間，日後絕對會用別的形式代償。