6.1 敏捷開發 (Agile) 核心觀念：節奏與交付
現代科技公司的產品開發幾乎都採用敏捷 (Agile) 精神，其中 Scrum 是最常見的框架之一。PM 必須理解其節奏，以達成高效協作。敏捷的核心原則
- 小步快跑，持續交付： 產品應以短週期 (通常 1-4 週) 迭代交付，而不是漫長的瀑布式 (Waterfall) 開發。
- 擁抱變化： 敏捷認為需求在開發過程中會不斷演變，PM 必須靈活應對，並將變化納入流程。
- 面對面溝通優於文件： PM 應盡量直接與團隊溝通，而非僅依賴 PRD。
Scrum 流程中的 PM 角色 (產品負責人 Product Owner)
6.2 PM 如何與工程師高效溝通：專業與尊重
PM 和工程師 (Engineer) 之間的關係是產品成功的關鍵。PM 必須扮演好「翻譯者」和「防守者」的角色。
與工程師協作的黃金法則
實戰技巧： 在需求評估 (Refinement/Grooming) 會議上，PM 應與工程師一起拆解功能，確保他們對需求有相同的理解。
6.3 專案風險與變更管理：控場力
即使是敏捷開發，風險和變更 (Scope Creep) 仍然存在。PM 必須具備高度的控場能力來管理不確定性。
專案風險管理 (Risk Management)
變更請求 (Change Request, CR) 流程
當外部環境或高層要求在 Sprint 中途變更或增加功能時，PM 必須走標準化流程：
- 紀錄 (Document)： 清楚記錄變更內容、發起人、要求日期。
- 評估 (Assess)： 與工程師評估變更帶來的額外工時 (Effort) 和對既有排程的衝擊 (Impact)。
- 取捨 (Trade-off)： 如果要增加新功能 A，必須從目前的 Sprint 中移除價值相等的舊功能 B 或 C，並溝通延期的可能性。
- 批准 (Approve)： 獲得關鍵利益相關者對新排程和取捨的批准。
PM 鐵律： 永遠不要在沒有成本 (Cost) 的情況下接受額外的需求。要用「排程、品質或資源」進行交換。
