讓會議開的更有效率六個要點

讓會議開的更有效率六個要點

開會,是每個職場工作者都無法避免的工作任務之一,懂得開會的人,工作效率一般很好,也能透過會議解決許多的問題。但也有很多人即便開了數百次會,還是無法把會議開好。

如何開好一個會議呢?往下我將跟大家分享我過去開會的方法。

首先,請記得以下幾個原則,會議最忌以下幾件事:
第一,會而不議,大家聚在一起了,卻沒有討論什麼重要的事
第二,議而不決,討論了議題,但卻沒有做出任何決議
第三,決而不行,大家決定好怎麼做了,但卻沒有採取任何行動

緊接著,就讓我們來看看有效開會的步驟與方法吧。

1.目的要清晰

年輕的時候如果有人邀請我去開會,我通常也不太問為何需要開這個會,而是先到現場再隨機應變,有時討論的議題我熟悉,我便能侃侃而談,但若是我不熟悉的主題,然後我也沒準備,去到現場大概就是幫忙製造二氧化碳。

年紀稍長,開始覺得時間異常重要,每次會議前我總會先詢問:「今天要討論什麼?會議結束後期望得到什麼結論? 」

若今天是專案啟動會議,那你的目的是取得大家的承諾,你一定要把你要他人承諾的事情寫在專案議程中,並逐一獲得大家的承諾;如果是決策方案會議,那你要把候選的方案條列,並說明不同方案間的優劣,最終要取得大家的決議。

若只是例行性會議,重點就放在進度與議題上,不要變成需求討論會議,唯有目的明確,你才能把握會議內容是在計畫內,不會偏離。

會而不議,多數的問題都在於會議的目的不夠清晰。

如果連目的都不清晰,那代表你不該開這個會。

2.成員要挑選

第二個很常犯的錯誤,便是關鍵與會者都沒來,卻來了一堆閒雜人等,因此當會議的目的明確後,你該接著思考哪些人應該要來參與這個會議,把你認為該參與會議的人放到你的郵件收件者中,並把你會議的目的與預計的結論摘要於會議邀請郵件中。

在我擔任會議主席時,我會特別提醒對方務必要參加,請務必附註他跟哪件事情直接相關,此外,不要每次開會都拉一群人進來,會議的成本非常重,一場兩個小時的會議,找了 20 個人進來,無形中就浪費了多少的工作產出,若這些人對於產出結論沒有明顯幫助,只是為了同步結論,那可以在會議後發送會議摘要與結論即可。

而身為會議的受邀人,也請務必確認這會議參與的必要性,避免時間在無形中浪費了。

如果關鍵人員不能出席,那寧願改期也不要浪費時間開一個不會有結論的會議。

享有「矽谷教練」尊稱的比爾・坎貝爾(Bill Campbell)曾說:

我沒有提供過一個產品意念。我在做的只是保證房間裡面坐的都是對的人,而且那些瘋狂的想法可以得到支持。

3.相關人員要表態

當會議圍繞著我們設定的主題進行,相關的人員也都到場了,這時候身為會議主席的你就必須要去引導相關的人員表態,讓他說說他對這項議題的看法,很多會議結論最後被翻盤都是因為相關人員在會議中沒有明確的表達他贊成或反對,但會後卻四處去說會議的決策有誤。為了避免與會者事後放砲,最好的作法就是在會議中讓他說完,不論是好是壞,但當所有人的意見充分被表達,會議才真的有意義。

因此,從會議在確定目的與挑選成員時,其實你應該就要設定好誰應該對什麼主題表達意見,誰又應該對哪件事下決定,才不會落入議而不決的窘境。

4.結論要明確

會議過程中一定會有許多的討論,有些討論會有爭論,但爭論最終都一定有一個結論,而這個結論必須非常明確,例如確認採用A方案、確定這次提的兩項需求排入計畫,並於專案期間完成、確認不購買第三方工具,會議後大家看文字就知道會議中決定了哪些事情,也知道接下來要幹嘛,那就足夠明確,反之就代表結論不明確。

明確的結論引導團隊向前行,模擬兩可的結論則讓大家無所適從,若有些議題沒有結論但又很重要,那就要列為待辦事項,且被標註確切的預計完成日期與責任者,並在會議後追蹤。

要盡可能的避免一個會議的主要決議是在開另一個會,因為這通常反應的是討論的議題或參與的成員一開始就選定錯誤,才會陷入難以決策的困難中。

一個基本的原則,會議後,大家必須要知道如何往下進行工作。

5.會議記錄要確實

會議過程的一切都要白紙黑字寫下來,才不會死無對證,會議的結論、決議與待辦事項尤其重要,一定要記錄下來,並在會議結束前再次宣讀,確認大家都已經獲得共識,有問題的應該在此時提出,否則就此定案,如果要嚴謹一點,還可以請大家在會議簽到表上簽到,證明他有來參與這場會議。

好的會議記錄不必是逐字稿,而是針對過程中做了哪些討論,有哪些決議,而過程中的重要提議或決策分別由誰提出,決議後的待辦事項又有哪些,每個事項分別由誰負責等。

6.待辦事項要追蹤

會議後的待辦事項一定要追蹤,否則會議等於只開了一半,會議記錄的宣讀不代表會議的結束,追蹤每個待辦事項是會議的最後一件事,而這件事常常被忽略,也辜負了大家辛苦開會所用的腦細胞。

這也是時常犯的錯誤,會議主席往往認為他的責任就是開完會,然後獲得結論,實際上,主席的責任應該是確認會議初始的目標能達到,也就是開會所討論的問題必須獲得解決,而待辦事項的跟蹤與完成便是確保問題得以解決的最後一哩路。

若無法在會議結束前請每個待辦事項的負責人押上deadline,那就要在會議紀錄上請各負責人回覆,確保每件事都有人在跟進。當然了,並不是有人回覆這件事便會完成,你還要每週或每幾天跟進一次,確保每件待辦事項都在進度內,將待辦事項的跟蹤當成一個專案,每一件事都要如期交付

當能做到上述6件事,便能讓每個會議都開的更加高效,永遠記得,開會是為了溝通,而溝通則是為了確保認知一致與行動一致,若能不開會就做到這些,那其實就不用開會,很多人忽略了這件事,錯把開會當目的。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。 結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是: 1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi