為什麼沒有效率的會議是我的痛點之一呢？曾經有段時間公司的會議次數太多、時間冗長、常常討論不完或是會議大綱跟實際上討論的重點有所衝突。久而久之，團隊的情緒會對會議感到焦慮，會議永遠開不完，想討論的事情多到沒有結束的一天。

團隊持續改善會議的效率，從中觀察到身為會議的參與者，也可以讓會議順暢，而不是讓主持人或是某些人才能做控場，接下來會以會議的流程分別從會前、會議中以及會議結束後去做說明可以改善的方式。首先來聊聊會議前的準備有哪些可以做的：

會通

會議的發起人想召開近十人的會議，通常會盡可能把要討論的項目都塞在這個時間裡面，避免後續還要花其他人的時間。這是人之常情，但如果有這樣的念頭，會演變成什麼都想要討論，可是時間不夠。或是某些議題要討論的時間需要花的更多，而失焦原本要討論的重要事項。

如果你是發起會議人，可以先想想這種會議的目的、會議的流程以及這場會議結束後，想要得到什麼產出。把這些釐清清楚後，可以在會通內容說明會議的進行方式，此外也可以做為開會時的待辦事項，確保這場會議結束之後，可以預期達成的目標。

舉下方例子說明，最後期望的是前後端確認規格無誤後，接下來可以進行開發：

會議邀請主旨：[主題] 討論需求 A 規格
討論時間：08/31(二) 10:00 ~ 10:30
討論內容：
- 請後端工程師說明文件規格
- 前後端對於回傳欄位建議事項
文件規格連結：https://xxx.xxx.xxx/spec.doc

了解會議要討論的項目，以及期望會議結束之後的結論是什麼。所以當參與會議時發現有人開始失焦討論需求 B 或 C 時，可以適時地提出提醒與會者們，讓會議能夠順暢的進行。

參與者

如果少了誰，這場會議就無法順立進行？如果是這樣的人物，當然要加入與會名單當中。但很多會議是不確定要不要出席，為避免可以漏掉很多資訊，所以還是參加為上。舉例來說，在討論改善會員 onBoarding 流程，而這場會議只是跟大家說明為什麼要做，預期改善會帶來什麼效果。身為一個工程師，通常前期討論跟最後要實做的方向會變動很大，所以不參加其實也不會影響太多，只是會少了了解需求過程的演變。

還有一種可以決定事情的關鍵人物不在這場會議當中，代表可以決定事情的人不在這個空間，就會讓整個會議的討論的每個事項都需要事後再一一確認。舉例來說，老闆可能會說你代表參加會議，他覺得可以不參加，然後跟你同步訊息。如果你了解這場會議會需要他的決定才能順利進行下去，那還是請你說服老闆參加吧。要不然會演變成，討論中的決定全部都需要在事後討論，而老闆若不滿意，是不是又需要花更多的時間做討論呢？

預習

有些時候在發想階段的會議，很難有事前準備好的文件可以做參考。但大多時候討論都會基於目前已知的資訊進行討論。假設大家都是參與會議的當下再進行了解開發規格，會讓會議開頭變成給大家閱讀的準備時間，試想這些準備若不是放在這邊，而是大家先行了解的話，其實大家馬上可以針對開發規格有什麼想法跟建議進行討論。

再來先行閱讀可以帶著問題進去會議當中，你的問題，也許都是大家的問題。而你的提問說不定可以衍生出更多的碰撞，能讓產品或是開發體驗可以越來越好。而當每個參與會議的人都這麼做的時候，會議上會發散的情形會逐漸降低，漸漸地，若有人不先做功課，先提出問題時，大家也會有默契了解誰在浪費彼此的時間。

在我的經驗當中，在會通狀況比較多，參與者跟發起人彼此對這場會議的想像完全不同。所以在討論的內容容易走歪，而且歪到不知道走到哪個角落去了。這時候都需要靠參與者去拉回主題，或是來回對焦彼此想要產出是什麼。所以列出會議要討論的項目很重要，就可以當做 Check List 勾選哪些已經討論過的項目。如果大家也有跟我相同的困擾的話，不妨試試。或是有更好的做法也歡迎分享，讓大家彼此交流。