記得第一次接專案管理時的窘境，以下如有巧合，純屬真人真事：

一場 1.5 小時的會議開完，大家口頭上都說好沒問題，結果一週後再問，沒人開始動。
我傻眼

工程師聽懂了技術方案，但行銷卻以為時程還有彈性，最後大翻盤。
我難過

客戶明明在簡報現場點頭，但隔週又改口：「我們沒有說要這樣做啊。」
我頭痛

開完會，等於有共識？事實上，訊息傳達 ≠ 共識，更不等於承諾。

專案能不能推動下去，關鍵在於：會議結束後，是否真的有人「帶走責任」，並在期限內交付成果。換句話說，如果彼此沒有共識，就算簡報做得再漂亮、資訊再完整，都只是瞎忙。

訊息傳達完不等於共識形成

在專案管理中，單純「把話說完」並不代表團隊已理解或同意。許多人誤以為分享了簡報、發了訊息，事情就會自動推進。實際上，若沒有確保對方理解、認同並付諸行動，訊息只是一串文字，沒有任何推力。

共識形成是將「我說過」轉變為「大家同意並開始做」的過程，它不只是資訊傳遞，更是一種責任鎖定和期望管理。

共識的本質：三者缺一不可

從專案管理的角度來看，共識要成立，至少包含三個要素：

1. 結論：這次會議或討論的決定是什麼？
2. 理由：為什麼選這個，而不是別的？
3. 下一步：誰負責什麼，何時要交、交付的成果是什麼？

缺少其中任何一塊，就很容易在事後回馬槍：

• 沒有結論 → 大家以為還在討論中。
• 沒有理由 → 遇到新阻力時，團隊缺乏支撐，輕易被推翻。
• 沒有下一步 → 決策變成說說，沒人知道誰該做什麼。

很多會議之後的行動失敗，本質上不是沒討論，而是「沒有被鎖定下來」。

Recap ：1 分鐘完成共識鎖定

我曾跟一位高效 PM 前輩學到一個方法：三句話 Recap。

它的精髓是，在會議最後 1 分鐘，把討論的結論、理由、下一步快速總結，讓大家沒藉口說「我不記得」或「你沒講」。

三句 Recap

1. 結論決策：一句話講清楚今天決定了什麼
2. 理由權衡：一句話說明最關鍵的原因
3. 下一步行動：一句話鎖定 Owner、期限、交付物

這三句話不只是形式而已，而是讓資訊被記錄、被聽懂、被行動化的最低標準。

舉例：不同場合的 Recap

決策會議

1. 結論：採用選項 A，兩週內交付設計提案。
2. 原因：技術端最容易實作，可最快驗證關鍵假設。
3. 下一步：Owner 是小森，9/30 前要完成 Prototype，需涵蓋可點擊的三個核心流程。

技術同步

1. 結論：先走 A 案（現成模組），API 僅必要調整。
2. 理由：太趕，來不及做完整測試 (兩週內就得有可操作版本)，需避免相依性 bug 而讓系統掛掉。
3. 下一步：後端 Alex 於 10/20 前完成 API 定義；前端 Max 10/24 接入，10/27 整好提供初測版本給 PM 薇琦。

客戶簡報

1. 結論：我方將於三週內釋出 Beta 版，優先解決對帳痛點。
2. 理由：此版本能解決對帳的核心問題。
3. 下一步：11/2 我方將上線 Beta，目標把對帳月結時間降到 1 小時內。

不同場合說的話語可能不同，但結構觀念都是相同的。

常見的「假共識」坑

很多 PM 以為自己已經 Recap 過，但其實只是「假共識」。常見的錯誤有：

1. 只講結論，沒說理由

   → 團隊成員表面同意，但心裡其實沒 buy in，一遇到阻力就動搖。

2. 只講下一步，沒說明決策依據

   → 工程師雖然照做，但遇到新需求時會質疑：「為什麼要優先這個？」

3. 沒鎖定 Owner

   → 大家都以為別人會做，最後沒人做。

4. 過度模糊

   → 當 PIC 說「我們盡快交付」、「之後找時間處理」這種說法，等於沒說。

共識的敵人不是分歧，而是模糊。

話雖如此，當我的角色是設計師，遇到 PM 講的太含糊時，往往不敢輕易諾，偶爾也會打模糊仗 (已在反省中…)

依不同的訊息載體做微調

不只要 Recap ，還要根據不同載體做調整。

Line 等即時訊息（字越精簡越好）

快速、重點、關鍵字醒目。

稍早會議結論：採 A 案，兩週交付設計
✅ 小森 9/30 前交 Prototype（含三個核心流程）

Email（3 段式）

適合需要上下文的情境。

主旨：今日雙週會的會議紀錄及後續跟進

本次會議決定採用A案 (因技術端最容易實作，可快速驗證假設)，需於兩週內完成後續設計。

請小森於 9/30 前完成可點擊的 Prototype（含三個核心流程）。
如有問題，請於下班前回覆。

不確定時直接口頭確認

最能避免誤解。

我們採 A 案，因考量技術端最容易實作。
請小森 9/30 前交付 Prototype。

以上理解對嗎？

共識不只是說完，更要被記錄

Recap 如果只是口頭講過，很快就會被遺忘或扭曲。所以必須留下痕跡，讓團隊能隨時追溯。

實務做法

• 時間節奏：會後盡快 Recap，最好不要拖超過黃金 24 小時。
• 記錄位置：Decision Log、會議紀錄、專案文件，都能作為共識載體。
• 回覆機制：明確設時限，例如「明天下班前未回覆，視為同意」。 (aka. 不淮拖拖拉拉)

Decision Log 範例

AI 如何輔助 Recap 共識

三種常見應用

1. 會議錄音轉逐字稿（Whisper-based 工具 / Otter.ai）

   讓你不用邊開會邊記錄，專心參與討論。

2. 自動總結（ChatGPT / Notebook LM）

   把冗長逐字稿轉成三句話 Recap 草稿，再由 PM 微調。

3. 格式化紀錄

   直接產生可貼進專案管理工具的表格格式，例如 Decision Log。

實戰小技巧

• 在會議後，把逐字稿丟進 AI，下 prompt：

  讀取逐字稿後，請用三句話 Recap 會議重點 (結論、理由、下一步)。
  另外，加上 Owner、期限、交付物，以表格呈現。
  
  ##逐字稿##
  //貼上逐字稿
  

• 要對外發 Email，可以請 AI 自動轉換成正式書信格式。

• 在 Slack/Teams，可以要求 AI 自動縮短字數，確保訊息簡短又清楚。

需要特別注意的是，有些討論內容具有保密性(例如有簽 NDA 等)，這類資訊不宜使用雲端工具處理，建議改用本地端工具以確保資料安全。

共識有時會來回修正

共識不見得能「一次定稿」，有時候會需要來回修正。例如：

• 需求變更：原本三週交付的功能，被客戶臨時追加。這時需要重新 Recap，確保團隊理解新的優先順序
• 跨部門衝突：行銷希望提早上線，工程卻認為測試不足。這時 PM 要用 Recap 把分歧點與妥協的退化方案說清楚
• 突發事件：產品測試爆出重大 bug，導致計畫延遲。如果沒有新的 Recap，團隊很快就會出現不同版本、奇奇怪怪的「小道消息」，導致人心惶惶。

從單向傳達到雙向共識

許多生產力工具雖然能協助我們快速紀錄與整理資訊，但真正的共識仍需由人來引導與確認。共識不僅是資訊的同步，更是彼此承諾的交換。當我們能把 Recap 說清楚、記錄下來、落實到責任人手中，專案才真正開始往前跑。

PM 的溝通力，不在於做了多少簡報、開了多少會議，而在於能否讓每場會議的結束，成為一連串行動的起點。