ExplainThis 全端開發雙週報 #54
工程師開會時，如何避免無效的會議?
嗨～ 歡迎閱讀第 53 期的 ExplainThis 全端雙週報。
在進到這期的主題文之前，想分享 ExplainThis 的《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》線上課程，前兩週新增了 MCP 系列共 7 個單元的內容，涵蓋了 MCP 基礎介紹，到如何在使用 Cursor 時搭配 MCP。
我們已經將 MCP 單元搭配的教材上傳到 ExplainThis 的網站 (目前總共 25 篇)，讓想了解如何高效使用 Cursor 的讀者們可以免費閱讀 (連結)。因為有些內容很難用文字描述，推薦偏好看影片課程的讀者，歡迎加入 E+ 成長計畫 (連結)。雖然這門課是以 Cursor 做為主要工具，但課程中講到的概念，都適用其他 AI 驅動的工具 (例如 Windsurf 或 GitHub Copilot)。
工程師開會時，如何避免無效的會議?
在資深工程師的思考力 — 開會與反思檢討該提什麼問題? 一文中，我們有談到資深工程師可以在會議當中提哪些問題，藉此讓思考更加完整，同時也讓會議結果更理想。在這一期的主題文，我們會從另一個角度切入來談開會這件事。具體來說，我們會從「假如你今天是會議負責人或主持人，要如何確保會議能高效進行?」這個角度來談。
因為主持會議與帶討論，是很多工程師邁向資深時必須面對的門檻，特別是當成為團隊或技術的負責人，基本上免不了要帶技術設計的會議討論，因此如果你過去對如何帶會議的討論沒有頭緒，推薦可以參考這篇主題文提到的具體方法。
談到開會，很多人可能只會想到會議當下，但事實上要開好一場會，事前的準備很重要，以下是我們推薦在會議前準備要先思考的面向。
確保會議有明確的目標
首先，會議前準備最重要的點是「會議目標要足夠明確」。如果沒有明確的目標，那會變得一群人不知道在討論什麼，這是導致會議無效最常見的原因。要檢視是否有良好目標的一個有效方式，是問「我希望透過這場會議改變什麼?」，然後先寫下有會議跟沒有的差別是什麼。
更進一步說，不同目標的會議，會有不同的開法，不該用單一種方式來開所有類型的會議。如果會議目標是達成做出某個決策，用發散搜集想法與回饋的開法來進行，很可能到會議結束仍無法做出決策，就會讓目標無法被達到。反之，如果是希望透過會議來發散，假如在會議中有人急著要下結論，也會讓發散的效果不佳。
以下列出常見的會議類型，以及對應可以達到的改變
資訊同步型：這類會議是分享資訊與同步為主，通常不會有過多的討論。常見的公司全員會議 (all-hands meeting)，就是典型的資訊同步型。可以透過這類會議達成的改變，是原本與會者不知道某個重要資訊，但是在會議後能掌握某個新資訊
關係建立型：這類會議是以關係建立為主，會議是以促成平常沒有機會接觸的人交流，建立關係本身就是目的，因此多半不會有決策在這類會議發生。可以透過這類會議達成的改變，是原本與會者彼此關係與交情淡薄，在會議彼此更熟悉、關係更好。
發散型：這類會議是以發散想法為主，例如常見的腦力激盪會議 (brainstorming meeting) 或者是邀請不同類參與者給回饋的會議。可以透過這類會議達成的改變，是原本對某個主題的想法有限，在會議後能有更多觀點的想法。
決策型：這類會議有明確的決策目標，在會議中會有討論與交流，討論的目的是要指引最終的某個決策。可以透過這類會議達成的改變，是原本某個無法推進的事項，能夠在會議後有明確可往下的決策。
在上面四種常見的會議類型中，工程師比較常會需要開後兩種類型。特別是在技術設計相關的討論，可能會需要廣泛搜集不同方的想法，同時也會需要有會議來定奪最終的設計方案。因為會議的目標很不同，這兩種會議的開法也會很不同，在下個段落我們會特別來談如何開這兩種不同的會議。
確定會議是必要的
不過，不論是哪一種類型的會議，最重要先確定會議的目的；因為當目的清楚後，就能有效判斷誰該參加、誰沒有一定要參加。如先前在 資深工程師的思考力 — 開會與反思檢討該提什麼問題? 一文談到的，每個會議都是有成本的，當某個非必要的人，沒有把時間花在會議上，就等同於那個人的時間能釋放出來做其他有生產力的事。
因此，如果你已經是團隊中的資深工程師，一個更重要必須問的問題是「這個會議真的有必要存在嗎?」 以及「真的每個與會者都是必要的嗎?」。如果會議目標不明確，就先弄清楚，不然不要召開會議；同樣地，假如某個人沒有必要真的參加會議，可以點出這件事，讓那個人的時間能夠被釋放出來，去做其他更重要的事情。
先前 Shopify 創辦人兼執行長 Tobi Lutke 曾發過一篇貼文談這個點。他的總結是，當越少會議，就越多時間能專注在把事情做好。他的原文是說 Companies need to occasionally delete all recurrent meetings to stay healthy. This works because it creates back pressure that all meetings have to be rejustified on merit. Fewer meetings: more focus on craft.
確保會議時間沒有過長
除了開會的目標要明確，要讓會議有效率，會議時間的設定也很關鍵。很多讓人覺得很冗長的會議，很常是因為會議時間過長，原本可以快速解決的會議，卻拉了一個很長的時間。因為時間拉長，與會者就容易寬容無意義的討論，造成會議的無效率。
更進一步說，如果一個可以一小時完成的會議，拖到兩個小時，假如有十個人參與，那等於浪費了 20 小時的生產；如果有更多人參與，那浪費會更多。因此會推薦，在準備會議前，先檢視所需的會議時間。如果能半小時完成的會議，就不要排一個小時。這樣在會議中，如果有一些走偏掉、會太過細碎的討論，就可以打斷並說「因為時間有限，讓我們專注在最核心的部分」，藉此來讓會議更聚焦也更高效。
確保有做事前準備
做好會議的事前準備是非常重要的，過去我們在不同的組織，都經常看到會議前幾分鐘，主持會議的人還手忙腳亂地在處理事情，不論是處理設備問題，或者是去找出會議相關的文件以分享給與會者，但這麼做是非常沒有效率的。
試想，假如今天主持人在會議前就把相關文件都準備好，這個準備時間只會花主持人一個人的時間。但假如這場會議有 10 個人參與，然後會議一開始主持人還在找文件，就算只花兩分鐘找文件，總共也是佔據了 20 分鐘 (兩分鐘 x 10 人)。
在會議中浪費的時間，都不只是主持人自己的時間，還會是每個參與者的時間，這種浪費是倍數的浪費。因此，不論是先確保設備沒問題，或者是該有的文件的連結都已經開好，都是在開會前要做的。
閱讀更多
除了會議前要先做好準備的，下一步要做的是先規劃好如何進行會議。我們在 E+ 成長計畫的主題文中，會更深入地去談，讓讀者們能確保在不同類型會議時，有效進行。想更進一步閱讀相關內容的讀者，歡迎加入 E+ 成長計畫 (連結)。
本期推薦
相信讀者們這週都被各大公司的 AI 代理發表搞得眼花撩亂，在眾多 AI 代理有新發表的同時，我們覺得最難能可貴的，是原本已經開源的 VS Code，進一步 Copilot Chat 的部分也開源了。想了解 Copilot 實際的程式碼長什麼樣，現在可以直接看到了 (連結)
Dropbox 存儲系統的設計者 James Cowling 發了一個推文，分享在打造基礎設施系統時，驗證機制的重要性，特別是當系統規模化起來，有良好的驗證跟測試是避免出問題的重要把關 (連結)
現代前端開發多是以框架為主進行，然而很多人可能在用框架的同時，忽略了背後的本質。這週看到 Plain Vanilla 的系列文章，在談如何不靠框架，純用 HTML、CSS、JavaScript 來實作 (連結)
前幾期雙週報有分享一篇實作 undo & redo 功能的文章。最近在 E+ 社群中，讀者 Benson 分享了自己實作出來的版本，分別用 index 與 stack 兩種實作方式。推薦感興趣的人可以看在 GitHub 上的專案原始碼，以及給星星支持 (連結)
最近看到法國政府推出的一系列開源專案，其中一個是開源版的類似 Notion 的工具，推薦感興趣的讀者，可以看看這類共編文件工具的原始碼，特別是其中本地優先 (local-first) 的實作 (連結)。對本地優先概念不熟的讀者，可以參考這篇 (連結)
Notion 的共同創辦人 Akshay Kothari 分享了一張圖，比較了兩間公司，一間在社群聲量很大，結果實際表現卻反而比較差 (連結)。這讓人警惕，在選公司時，不要只是看社群上的那些比較大聲的聲音。關於選公司我們先前也寫過相關文章，推薦讀者參考 (連結)
在軟體工程師的求職過程中，很多人可能會問該不該花心思在寫求職信 (cover letter) 上。有些公司完全不看，但有些公司看重。這週知名軟體公司 37signals 的執行長 Jason Fried，最近寫了一篇短文《Cover letters? Yes!》談到為什麼他們看重求職信(連結)。如果對求職主題感興趣，ExplainThis 也有製作一門求職相關線上課，推薦可以參考 (連結)
文末彩蛋
上個月看到一個非常簡短但是精闢的觀點 — Sleep is a debugging tool。
許多在職涯上有企圖心的人，可能會時時刻刻處在衝刺的狀態，竭盡所能把握每一分鐘，把行程最佳化到不留一點空隙。然而，在衝刺之餘，好好休息是同等重要的。
先前我們寫過一篇貼文在講「好好休息」這件事，談到當過度忙碌時，很難去創造新東西。有研究指出，對大腦來說，有 downtime (直觀理解起來，應該是指放空的意思) 很重要。因為當不刻意追求做某事時，大腦仍會持續運作，甚至開始一些神奇的探索，而很多創意與創新，會在這些片刻發生。
因此，假如平常在工作上，遇到某個解不開的 bug，或許可以先稍微休息一下，說不定某個本來沒想到的解法，就會在休息時突然在腦中跳出來～