產品經理在敏捷開發下的反思：會議如何優化、如何避免踩雷｜EP84

敏捷開發（Agile）在軟體產品公司已漸漸成為主流，其中 Scrum 是最常被應用的方法，但相較於瀑布式開發（Waterfall），Scrum 真的比較好嗎？跑敏捷的團隊需要具備什麼特質？這篇想以產品經理的角色，記錄在敏捷團隊的觀察與心得。

一、Scrum 框架與產品經理的角色定位

Scrum 框架簡介

Scrum 包含三個核心角色：

• Product Owner：產品負責人，也可以先理解為產品經理，負責定義產品價值，協調開發優先級。
• Scrum Master：敏捷教練，有時是團隊中的技術組長 / 資深工程師來擔任，負責確保團隊在流程上保持正軌，持續優化開發流程。
• Development Team：開發團隊，包含設計師、前端、後端、QA 工程師等，負責執行開發任務。

Scrum 常見會議

• Planning：規劃會議，每個 Sprint 的第一天早上 10–12 點，由 PO 布達這個 Sprint 要執行的任務，並由開發團隊負責估點和技術評估。
• Stand-up Meeting：每日站立，每天的早上 10:00 - 10:15，團隊成員分享昨天做的事、今天要做的事、以及是否有任何阻礙要討論。
• Review / Demo：回顧會議，每個 Sprint 最後一天，由開發團隊展示這 2 週的開發成果，並邀請利害關係人參與。
• Retrospective：反思會議，開發團隊針對這個 Sprint 的狀況進行討論，優化流程，讓下個 Sprint 可以更順暢。

⠀⠀

實際 Scrum 的跑法

上述是 Scrum 的基本跑法，但每天公司肯定不同，甚至同間公司不同組有可能都不太一樣，因此我想介紹我的團隊的跑法。

在會議的進行方式，我們多了幾種會議讓團隊更順暢：

• Pre-Refine：
  主要是 PO & RD Lead & QA Lead 參與，PO 提出下個 Sprint 預計要開發的 User Story，讓 RD Lead & QA Lead 評估顆粒度 / 時程 / 技術可行性 / 測試複雜度等，確保 PO 的 User Story 符合可行性，且沒有遺漏重要細目，並在 Refinement 會議前，也會請 RD Lead & QA Lead 補充一些技術知識或參考文件在 Story 內，給實作的 RD 和 QA 參考，加速 Refinement 會議。
• Refinement：
  Planning 才說明 Story 容易造成開會時間冗長，因此我們將 Refinement 單獨拉出來，讓 PO 布達下個 Sprint 要做的 User Story，讓前端 / 後端工程師初步提問，但因為 Pre-Refine 已經有和 RD Lead & QA Lead 介紹過了，因此 Refinement 主要是讓所有 RD 和 QA 再次確認執行面有無問題。
• Pre-Planning：
  Planning 的估點也是一項耗時的任務，因此我們將估點這段再拆出來，讓 RD 和 QA 針對 User Story 進行討論，若有任何疑問都先開待討論的 Task 給 PO，後續 Planning 時，PO 可以更快決定該 Sprint 可以做到哪。
• Planning：
  因為估點都在 Pre-Planning 已完成，因此 Planning 只針對開發團隊的點數確認 Sprint Goal 或調整開發順序，並由 PO 解答開發團隊針對 User Story 的疑問，確認是否有要再補需求，若都沒問題，就會在該場會議定案這個 Sprint 的內容。

上述流程有些團隊是濃縮在一場 Planning 進行，但我們團隊後來發現拆成多次會議，可以盡可能確保 User Story 的執行細節都有涵蓋到，也減少誤解，避免 Planning 開完才發現要補需求。

⠀⠀

二、產品經理的日常職責與時間分配

⠀⠀

在 Scrum 中，產品經理 aka 產品負責人（Product Owner, PO）負責定義產品願景目標、管理產品開發優先順序，並確保團隊交付的成果符合市場與客戶需求，這些具體要做什麼呢？

產品經理的職責與任務

• 產品願景的場景宣達：
  身為最懂產品的人，需要時時和不同利害關係人進行產品講述，包含功能描述、場景描述，根據業務和客戶的不同情境，介紹產品的哪個面向可以滿足對方，因此也常需要偕同 AM / Sales 釐清客戶需求，或是向 AM / Sales 介紹功能操作方式。
• 面向業務的產品窗口：
  產品經理負責收斂市場需求、客戶反饋和業務目標，確認哪些需求要做與不做，並轉化為具體的待辦事項，根據價值和風險進行排序，確保收進來的需求是符合公司利益、長期產品目標。
• 開發清單的優先排序：
  每個 Sprint 都是 2 週，也代表產品經理要持續規劃下 2 週的開發項目，並且確認每一項的優先順序，為什麼 A 要先做？為什麼不先做 B？產品經理心中要有一把尺，且要能說服自己和開發團隊。
• 產品目標的交付防線：
  產品經理需清晰理解功能的目標，包含支援與不支援，哪些可以妥協、哪些務必開發涵蓋到，當團隊提出「這個操作流程有點複雜、開發起來會很久，我們能簡單做嗎」，身為 PO 必須掌握團隊交付什麼給使用者，避免開發團隊自行刪減需求。
• 產品團隊的跨組橋樑：
  產品經理需與開發團隊內的每個人保持良好關係，包含設計師、前端、後端、QA 工程師，以及其他利害關係人（AM / Sales / MKT / CS），確保當有需求異動時，可以即時同步給所有開發團隊成員，或是當有資源 / 時程要協調時，產品經理可以主動擔任協調者。

⠀⠀

日常工作的時間分配

Scrum 每 2 週為 1 個 Sprint 的跑法，讓產品經理需要不斷在短時間做決策，很難有長時間的研究，因此工作時間也滿常被壓縮，以我自己為例：

• 30% 產品規劃：針對下個或下下個 Sprint 進行需求釐清，並開始撰寫 PRD、User Story。
• 20% 開發釐清：針對這個 Sprint 的開發狀況，和 RD / QA / UX 討論需求變更，像是開發到一半發現有情境漏掉，因此要增加需求，或是針對開發細節要釐清。
• 30% 各式會議：包含 Scrum 本身的會議（Stand-up、Refine、Retro、Planning），還會有 PO 週會、設計方案討論會議、產品小組進度會議，再加上零星與 Sales / PJM / AM 等會議。
• 20% 維運異常：使用者在操作功能時，可能會發生操作失敗的狀況，因此會透過 AM / CS 反應給 PO，讓 PO 去釐清是 bug 還是操作問題，有時還需要後續開單請 RD 壓資料 / 改 code。

不得不說在 Scrum 框架下的節奏非常快，因此針對每項變動或紀錄，都要很立即在 Slack、看板工具同步給大家。

⠀⠀

三、敏捷開發的踩過的地雷

⠀⠀

接下來這段我想記錄我自己在敏捷開發踩過的新手地雷：

⠀⠀

▍1. 沒有定義好驗收標準 （Acceptance Criteria）

⠀⠀

⚠️ 地雷：User Story 沒說做完的定義，也沒提到做完後會期望使用者怎麼操作，導致前端切出來的畫面，和 QA 要測試的項目，和 PO 想像的畫面，三者都不同，變成要再重新定義需求。

每個 Sprint 只有 2 週，意味著產品經理需要很清楚知道每一張 User Story 的範圍和交付標準，例如「做了哪幾步驟才算是這個功能的完成？錯誤情境是否都要阻擋？文案欄寬是否都要和 Figma 一致？」

以我的團隊的協作方式，PO 寫完 User Story 後，也要寫上上述的驗收標準，在 Refinement 要和 RD 和 QA 都走過一次流程，確保大家對於操作順序都一致。

寫完驗收標準後，再由 QA 去展開更細節的測試項目，並讓 QA 拿著測試項目和 RD 一一校對。

⠀⠀

▍2. 太多需求都想要在同個 Sprint 塞進去

⠀⠀

⚠️ 地雷：各方利害關係人持續開需求，希望這個 Sprint 塞進去，想要在下次 Release 一起跟上線，但開發量能有限，導致開發到一半發現 Story 做不完，又要一個個去說明延後原因。

在 Pre-Planning 估點的意義就在於確保下個 Sprint 可以接幾張 User Story，當利害關係人有眾多需求，PO 需要協調好優先順序，向開發團隊確認好順序，再依照團隊可負擔的時間「多抓 Buffer」，最後向各個利害關係人說明各自的上線時間。

例如開發團隊若針對 10 張 User Story 估點完後，評估可以在這個 Sprint 做完 6 張，有時要先保守抓 5 張；或者是 RD 和 QA 預計 4 月底可以 Release，PO 有時要對外喊 5 月中，也讓團隊有緩衝時間。

因此跟業務們說明交付時間時，就要說 A/B/C 三項預計 4 月底，但 D/E 預計 5 月中。

⠀⠀

▍3. 需求畫面還沒定案就急著想進開發

⠀⠀

⚠️ 地雷：軟體開發難免會有隕石或急件，有時迫於各方壓力，在 Figma 畫面還沒定案，就可能要先進開發，但開發到一半又要改 Figma，導致前後端都要重新調整，甚至 QA 的測試項目也要改。

在 Refinement 或 Planning 階段，當需求畫面還沒 90% 定案，PO 需要跳出來喊停，先讓團隊進行其他張 User Story，不然開發到一半若開發團隊有問題，有時 PO 自己也回答不出來要定哪個版本。

讓開發團隊重工是相當浪費時間的一件事，除了原本的要重新調整，重工的時間其實可以拿來做別的 Story。

⠀⠀

▍4. 需求情境沒盤點完整，導致開發到一半要加需求

⠀⠀

⚠️ 地雷：在規劃新功能時，若有些介面或 API 沒盤點到，可能 QA 要測試時會發現為什麼有些地方沒改，或是有些功能是單筆 / 批次，常常是兩種操作情境都要一起新增或修改。

盤點需求一直是一件很吃經驗的事，PO 也很難每次都將 User Story 寫的超級完整，特別不是每位 PO 都了解整個系統的細節，因此我們團隊的作法是透過眾人智慧來解決有缺漏這件事。

在 Pre-Refine 會議，讓 RD Lead & QA Lead 先檢查過一次，在 Pre-Planning 會議，讓 RD & QA 直接討論做法，順便看哪邊有遺漏，因此最終在 Planning 會議上，通常就會比較精準知道 User Story 最終的開發大小。

⠀⠀

▍5. 開發進度沒透明同步，業務抱怨開發太慢

⠀⠀

⚠️ 地雷：業務們的需求會一直來，有時做 A 業務的需求，B 業務就會反應他的功能什麼時候才會排到，因此產品經理要不斷向利害關係人同步開發清單，確保重要的需求不論做與不做，都有被安排或回應。

PO 作為產品團隊的對外溝通窗口，要時時和每個利害關係人保持好關係、同步好團隊的進度，因此我在和不同人溝通需求時程時，都會盡可能喊一個緩衝的時程。

例如針對 A 業務，他手上的 a 功能也許團隊可以 4 月中就開發完，但為了幫團隊留緩衝，我會喊 4 月底完成，同時也會讓他知道我們現階段正在做什麼功能、為什麼要等這麼久才上線，確保他理解我們也正在處理 B / C 業務的需求。

四、產品經理在敏捷開發的心態

⠀⠀

相比瀑布式開發可以長時間做需求分析和規劃，敏捷開發要在短時間蒐集資料，快速下決策，比較偏「快速吸收、快速迭代、快速試錯」，因此有些心態是我最近正在收斂的。

• 保持產品開發清單的彈性：
  80% 的需求都是事前確定的，但難免會有 20% 遇到客戶插件 / bug 修復等急件，因此有時在 Planning 要臨時抽換 User Story，這時都要保持彈性，並及時向團隊說明原因。
• 隨時思考產品需求的範疇：
  User Story 開完並不是就結束，PO 要不斷思考使用者情境有沒有漏，有時 RD / QA 都看過沒問題，但實際可能還是漏了什麼功能沒改到，因此 PO 做為交付物的把關者，要不斷思考功能做完最終的樣貌是什麼（Acceptance Criteria），要交出什麼東西給使用者。
• 相信眾人智慧大於個人智慧：
  隨著系統越來越龐大，很難有一個人可以知道所有系統邏輯和相依性，因此 PO 在寫完 User Story 後可以在會議前找 RD / QA 討論，確保就盡可能涵蓋，也減少 Refinement 和 Planning 後又加需求，雖然無法 100% 避免，但可以大幅降低頻率。
• 管理各方利害關係人的期待：
  跑敏捷開發並不是開發的速度就會比較快，因此當有些利害關係人期待每個 Release 都有新東西時，要管理好各方的期待，確保有同步到每個 Sprint 的工作內容，避免讓主管覺得怎麼有些 Sprint 產出較低。

⠀⠀

不同角色對於 PO 的期待都不一樣，目前聽到的像是：

• 希望 PO 把 User Story 寫清楚，不要每次開發到一半又要改需求
• 希望 PO 把外部關係人都安撫好，不要讓大主管針對進度施壓
• 希望 PO 和 UX 把 Figma 畫清楚，有時 Figma 各欄位限制沒有標記清楚
• 希望 PO 把 User Story 的關聯和價值說清楚，不然不知道為什麼要做
• 希望 PO 把優先順序訂好，不要全部都要做、又要同時間上線

這些其實每個團隊都不一樣，有些團隊希望 PO 主導強勢一點，有些希望 PO 柔和一點，因此也看 PO 和開發團隊的協作默契。

⠀⠀

五、總結

⠀⠀

產品經理在 Scrum 中的核心價值在於將市場需求轉化為可交付的產出，並確保每個 Sprint 都能為用戶和業務創造價值，具體貢獻包括：

• 提升產品迭代：通過迭代反饋，產品更貼近用戶需求。
• 加速上線時間：短週期交付，讓產品更快進入市場。
• 促進團隊協作：作為溝通橋樑，幫助團隊聚焦目標。

從管理產品待辦清單到參與 Sprint 各項會議，再到與利益相關人溝通，產品經理需要不斷在快速迭代取得平衡，才能持續在 Scrum 中生存。

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

• 策略型產品經理與接案型產品經理的差異｜EP83