Retrospective 在做什麼？產品經理如何運用回顧會議優化團隊默契｜EP89
Retrospective 是敏捷流程中的回顧環節，對產品經理來說是一個可以回顧過往、反思的時刻，這篇會記錄 Retro 的重點，以及產品經理可以如何運用 Retro，讓產品團隊提升開發效率。
一、Retro 不只是回顧，更是優化默契
一個 Sprint 通常是 2 週，而 Retro 通常會在 Sprint 的最後 1 或 2 天，由 PO、RD、UX、QA 等所有團隊成員一起檢討做得好與做不好的地方。
但對 PM 來說，如果只是記錄問題與讚美進步，不一定能讓改善團隊遇到的問題，因此一個有價值的 Retro 會包含：
- 這個 Sprint 遇到哪些問題？重來一次如何更好？
- 哪些行為下次不要再發生？哪些行為下次要先執行？
透過 Retro 調整「團隊工作默契」，讓所有人協作更順暢，更順暢的意思像是：
- PM 寫 PRD 文件時，在驗收標準要更仔細，對於待確認事項要有備註，避免 RD 開發到一半才發現需求被調整
- RD 進開發前，要先開一張 task 盤點現有機制
上面這種工作默契，會需要一次又一次的 Retro 讓大家都養成相同習慣。
一場好的 retro，就像產品經理對團隊成員的用戶訪談，不要只聽表面，要能從每位成員的故事背後挖出真實動機與痛點，將「抱怨」轉為「優化」。
二、Retro 進行方式
對剛開始帶 retro 的產品經理來說，以下是幾個可以參考的流程：
（一）Retro 的流程（以 60 分鐘為例）
- 目標說明（5 分鐘）：說明這次 retro 目的，通常會透過便利貼或看板工具，讓大家接下來可以留言個人看法。
- 思考時間（10 分鐘）：讓每位成員針對 3 個方向留言「(1) 做得好的地方、(2) 可以改進的地方、(3) 需要討論的問題」。
- 分享討論（40 分鐘）：大家各自分享每個看法，並一條條確認哪些是工作流程提醒，哪些要列入持續追蹤項目。
- 總結行動（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 需要建立以下幾個原則：
- 提出建議，而非單純批評：
（Ｏ）「之後在 Planning 會議前，請 PO 先確認哪些需求是確定的，哪些是尚未定案的，針對不確定的項目可以先被住，這樣 RD 就知道哪些先跳過」
（Ｘ）「PO 需求為什麼不定義好」 - 討論事情，而非討論當事人：
（Ｏ）「下次開發前記得先確認新舊版的相容性」
（Ｘ）「王大明做事細心一點，請勿再犯」 - 討論解法，而非一昧防備：
（Ｏ）「大家之後遇到若要修改 OO 程式碼，要留意 ABC 情境」
（Ｘ）「這不是我的錯啊」
在開過數十次 Retro 後，我發現願意讓團隊說真話的關鍵是 PM 要能自己先認錯，像是我有時會在會議直接說「我漏盤點到 OO 情境，下次我會先在 Story 備註說這項待確認，確保自己記得」，若刻意營造出 PM 不可被挑戰的形象，久了團隊成員就不會想說實話。
五、Retro 後的行動要被紀錄和追蹤
很多 Retro 的行動項目最終都石沉大海，原因是輸出不夠具體或沒有追蹤，過往我們團隊針對要追蹤的項目，都會列出：
- 具體行為（Action）：不是「工作要仔細」，而是「Story 待確認項目請另外開 Task，確保當事人記得」。
- 責任清晰（Owner）：每項行動都要指定負責人，例如 PO、RD、UX。
- 時間明確（Deadline）：什麼時候要做完，什麼時候檢查。
但也不是每項都要這樣列出追蹤項目，有些主要是放進會議紀錄即可。
六、結語
產品經理透過 Retro 會議不只可以知道團隊問題在哪，從流程、決策、角色到文化，每一個細節都值得被反思。
如對這系列文章有興趣可以再觀看：
