在敏捷開發過程中，每兩週都會有一場回顧會議（retro），PO、UX、RD、QA 會針對該 Sprint 進行檢討和反思，這篇想記錄以產品經理（PO）的角度常被提到的檢討點，一方面是幫助自己成長，另一面是更濃縮自己的產品想法。
誰適合看這篇文章？
✔ 對產品經理、產品企劃、產品策略、產品規劃有興趣的朋友一、說明整個專案全貌
為什麼要做這個？對客戶的效益是？
在每個 Sprint 開始時，PO 若能先向團隊說明整個專案的全貌，讓每一位成員了解專案的來龍去脈，包含「客戶提出的需求、我們要做的範疇、最終產品長相」等，就能讓團隊更理解每一位的角色，而團隊成員也可以提出他們認為的「Better Solution」。
例如，如果專案的最終目標是開發一個新功能，身為 PO 就需要向團隊展示這個功能的背後操作脈絡，包含為什麼現有功能無法滿足？為什麼新功能就能滿足？上線後要怎麼維護？
另外我在與 RD 相處的過程中，也能了解到有些 RD 希望累積自己的履歷作品，希望都開發到「大功能」，因此 PO 在說明專案時，雖然不是每次的功能都很大，但都要能說清楚這次的新功能、或是修改舊功能的重要性。
Note：我現在佈達專案時，都會盡可能準備一頁式簡報和流程圖，確認使用者的操作路徑、以及要解決的商業場景，除了讓 RD 確認是否每個環節都有開發到，也能讓 QA 確認要測試的範疇。
二、訂定優先級
要明確：先做什麼？後做什麼？
在每個 Sprint 開始時都會有 Refinement 和 Planning，PO 需要訂出優先級，讓團隊知道哪些是最重要的，哪些可以稍後再處理，甚至哪些不用處理。
優先級最重要的是影響「交付時程」，什麼時間點必須要上線哪些項目（Must have），確保每一位團隊成員都知道現在最優先的任務。
同時，優先級訂出後，當團隊遇到問題時，也可以根據優先程度迅速做出決策「現在要做 vs 先不做」，減少不必要的討論。
Note：我早期曾發生沒有將優先級說明清楚的情況，導致 RD 會開發一些事後看來不緊急的項目，導致整體專案延遲交付，後來漸漸了解到一定要確保每一位成員都知道優先順序。
三、Planning 要準確預估工時
要花多久？多少人天？
在 Planning 會議，PO 會先說明每一張 Story 的大項目，接著每一位成員要針對 Story 裡面的每張卡片（Task）進行工時預估，例如 A Task 要 3 小時、B Task 要 1 小時，全部都估完才知道做完一張 Story 要花多少時間。
工時預估的好處是在 Planning 當下，其實就會知道整體專案會不會延遲，例如 1 位 RD 每天有 5 小時在開發（已扣掉會議），1 周最多就是 25小時，若有 2 位 RD 就是 50 小時 / 週，因此若 Task 寫完工時要 60 小時，當週就有極高的機率開發不完，需要由 PO 協調開發順序，或捨棄一些項目，或向利害關係人討論延後上線時程。
但要提高工時預估的準確性，PO 也有一項任務是「確認每一張 Task 做完後，可以交付整個 Story 的需求」，主要是避免在規畫時沒有盤點完整個範疇，導致後續要一直請 RD 補開發遺漏的項目，
Note：之前沒有仔細在一開始訂好工時，導致很常到 Sprint 後期才發現開發不完或測試不完，因此後來和團隊成員養成 Sprint 開始就要把工時列完的習慣。
四、每個成員都要能說出 Sprint 目標
這個 Sprint 要做什麼？
在每個 Sprint 的開始，PO 說明完每一個專案項目後，要再統整一次 Sprint Goal，確保每個成員都能清楚知道大家的目標。
不僅能讓團隊成員了解到自己的開發重點，也能避免漏開發，或是突然在處理不緊急的項目。
Sprint Goal 盡可能要是使用者流程，像是「透過 A 功能，修改 B 欄位」，這樣 QA 在測試時，也可以根據這個目標，確認開發內容都有正確交付。
Note：之前我的 Sprint Goal 沒說清楚，就會導致 QA 在測試時，會不確定到底這個功能算不算這個的範圍，算不算沒做完。
五、PO 確認時要收集更多資訊再做決策
根據什麼判斷？有跟誰討論過？
在 Sprint 開發過程中，PO 需要不斷做決策，但不一定每個決策都需要立即做出，有些決策需要 PO 回頭確認需求，或和利害關係人討論時程後才能決定，才能減少後續的修改和返工。
像是 RD 開發到一半，發現有技術債需要解，需要多花 2 天，但若不解也可以，PO 就需要確認現況影響程度；或是 UX 畫了一個流程，但 RD 開發起來比較費時，想協調一個更簡易的操作流程，PO 也需要進行決策；又或是 RD 開發延遲影響交付，到底要不要分段交付，也需要進行決策。
Note：之前太快做決策，事後都需要和 RD 再反悔，因此現在都告訴自己「3 秒鐘想不到答案，就回去好好想 10 分鐘，利弊都先確認過一次」。
六、總結
這篇主要是整理近期在組內的 Retro 紀錄，作為產品經理還有太多要學習的內容，之後再陸續紀錄不同事項，如有興趣可以再觀看：
非常謝謝你的閱讀！上述單純以我的職場生活來整理，未能涵蓋所有案例。
如果文章有一點啟發或幫助，可以留言或來信讓我知道 👏
．撰寫於：2024/06/01 (六)。
．撰文者：張家惟 Evan Chang，evancwchang@gmail.com
