Retrospective 在做什麼？產品經理如何運用回顧會議優化團隊默契｜EP89

Retrospective 是敏捷流程中的回顧環節，對產品經理來說是一個可以回顧過往、反思的時刻，這篇會記錄 Retro 的重點，以及產品經理可以如何運用 Retro，讓產品團隊提升開發效率。

一、Retro 不只是回顧，更是優化默契

但對 PM 來說，如果只是記錄問題與讚美進步，不一定能讓改善團隊遇到的問題，因此一個有價值的 Retro 會包含：

• 這個 Sprint 遇到哪些問題？重來一次如何更好？
• 哪些行為下次不要再發生？哪些行為下次要先執行？

透過 Retro 調整「團隊工作默契」，讓所有人協作更順暢，更順暢的意思像是：

• PM 寫 PRD 文件時，在驗收標準要更仔細，對於待確認事項要有備註，避免 RD 開發到一半才發現需求被調整
• RD 進開發前，要先開一張 task 盤點現有機制

上面這種工作默契，會需要一次又一次的 Retro 讓大家都養成相同習慣。

一場好的 retro，就像產品經理對團隊成員的用戶訪談，不要只聽表面，要能從每位成員的故事背後挖出真實動機與痛點，將「抱怨」轉為「優化」。

⠀⠀

二、Retro 進行方式

⠀⠀

對剛開始帶 retro 的產品經理來說，以下是幾個可以參考的流程：

⠀⠀

（一）Retro 的流程（以 60 分鐘為例）

1. 目標說明（5 分鐘）：說明這次 retro 目的，通常會透過便利貼或看板工具，讓大家接下來可以留言個人看法。
2. 思考時間（10 分鐘）：讓每位成員針對 3 個方向留言「(1) 做得好的地方、(2) 可以改進的地方、(3) 需要討論的問題」。
3. 分享討論（40 分鐘）：大家各自分享每個看法，並一條條確認哪些是工作流程提醒，哪些要列入持續追蹤項目。
4. 總結行動（5 分鐘）：針對要追蹤的項目列出具體行動，指定 Owner 與 Deadline。

⠀⠀

（二）當團隊很安靜怎麼辦

• Product Owner 或 Scrum Master 可以先自己分享想討論的議題，引發共鳴後，再讓大家各自分享，例如先拋幾個想法「我觀察到這週需求到第 3 天仍沒有定案」、「我發現 QA 測試量能不足」。
• 或是先幫大家回顧一下這個 Sprint 做的事情，例如「我們這週做了 A/B/C Story」。
• 或是也可以讓大家匿名留言（但有時會需要當事人補充細節，因此不一定每個團隊都適合）。

⠀⠀

三、透過引導追問，發現團隊問題

⠀⠀

接續上述的 Retro 的「需要討論的問題」，Product Owner 或 Scrum Master 可以透過追問讓大家一起集思廣益，確認要如何優化團隊默契。

⠀⠀

提問一：重來一次會怎麼做？

有時 Retro 會提出工作痛點，為了讓團隊跳脫情境限制，可以讓大家想像回到計畫初期時，要多做哪些事，例如詢問：

• RD 開發前可以多做哪些事，減少改壞舊有機制？
• PO 寫在 Planning 之前，可以多做哪些事，確認需求更明確？
• 哪些決策是緊急做的？若重來一次會有更好選擇嗎？
• 若你是他，你會先做什麼事？（換位思考）

⠀⠀

提問二：如果這個項目會失敗，原因會是什麼？

有時開發會被壓 Deadline，為了讓大家提早認知到風險，可以透過負面顯化（Negative Visualization）來做練習風險控管，讓團隊刻意去思考最壞的情況，以利提早辨識被忽略的風險，例如詢問：

• 這些 Story 底下的 Task，是否都有抓 Buffer？
• 哪些 Story 有相依性？若其中一個 Delay 是否會導致 QA 測試延後？
• 有哪些項目需要提前確認？API 是否有先確認能否打通？

⠀⠀

提問三：好的地方可以被複製嗎？

有時成功也需要被檢討，這樣才能將成功案例複製給其他人，例如詢問：

• RD 有做哪些事讓這個 Sprint 開發更順利？其他 RD 可以參考嗎？
• PO 文件有多寫哪些細節，讓大家看完更理解需求？

⠀⠀

提問四：現在的問題是否之前就有跡象了？

Retro 場合不一定只看到該 Sprint 的問題，有些是長期累積的小問題，只是一直沒有人提出，例如詢問：

• 這個情況是這個 Sprint 才出現的問題嗎？
• 問題出現時，是否 Sprint 過程中已有人提出、但沒有被處理？

⠀⠀

四、打造心理安全的環境，讓團隊願意說實話

⠀⠀

上述提到了 Retro 進行方式，但 Retro 最怕流於「抱怨大會」、「檢討當事人錯誤」，久了就沒有人願意說實話了。

為了讓反思更有系統，PM 需要建立以下幾個原則：

1. 提出建議，而非單純批評：
   （Ｏ）「之後在 Planning 會議前，請 PO 先確認哪些需求是確定的，哪些是尚未定案的，針對不確定的項目可以先被住，這樣 RD 就知道哪些先跳過」
   （Ｘ）「PO 需求為什麼不定義好」
2. 討論事情，而非討論當事人：
   （Ｏ）「下次開發前記得先確認新舊版的相容性」
   （Ｘ）「王大明做事細心一點，請勿再犯」
3. 討論解法，而非一昧防備：
   （Ｏ）「大家之後遇到若要修改 OO 程式碼，要留意 ABC 情境」
   （Ｘ）「這不是我的錯啊」

在開過數十次 Retro 後，我發現願意讓團隊說真話的關鍵是 PM 要能自己先認錯，像是我有時會在會議直接說「我漏盤點到 OO 情境，下次我會先在 Story 備註說這項待確認，確保自己記得」，若刻意營造出 PM 不可被挑戰的形象，久了團隊成員就不會想說實話。

⠀⠀

五、Retro 後的行動要被紀錄和追蹤

⠀⠀

很多 Retro 的行動項目最終都石沉大海，原因是輸出不夠具體或沒有追蹤，過往我們團隊針對要追蹤的項目，都會列出：

• 具體行為（Action）：不是「工作要仔細」，而是「Story 待確認項目請另外開 Task，確保當事人記得」。
• 責任清晰（Owner）：每項行動都要指定負責人，例如 PO、RD、UX。
• 時間明確（Deadline）：什麼時候要做完，什麼時候檢查。

但也不是每項都要這樣列出追蹤項目，有些主要是放進會議紀錄即可。

⠀⠀

六、結語

⠀⠀

產品經理透過 Retro 會議不只可以知道團隊問題在哪，從流程、決策、角色到文化，每一個細節都值得被反思。

如對這系列文章有興趣可以再觀看：

• 如何用 AI 快速產出 PRD 與 Figma：從專案點子到設計稿的流程步驟｜EP88