近年來，敏捷開發成為了企業的首選，也成為了不少從業者的標配，產品經理也不例外。那么產品經理該如何用敏捷思維管理項目？本文進行了總結分析，一起來看看吧。

一、談敏捷：IT行業的新常態

近年來，敏捷開發成為眾多企業的首選，到了幾乎成為從業者的標配。敏捷方法不僅幫助企業在多個方面構建競爭優勢、擴大價值，而且以其思維框架和行動指南的特性，在復雜的軟件開發項目中尤其發揮重要作用。

在不斷變化的VUCA環境中，企業為了生存和發展，急需通過快速試錯，以最小的成本迅速尋找到價值點, 很多企業為了生存，都在嘗試敏捷轉型，把企業內部的項目管理方式轉換成產品管理的模式，引入了新的職位，即產品經理 （Product Owner， 簡稱 PDO）。

二、敏捷與項目管理：一個復雜的關系

引入敏捷的企業在培訓中常將其與傳統的瀑布模型對比，說明在何種情景下敏捷模式更為適用。然而，僅了解敏捷與瀑布模型的不同并不足以應對所有情形。敏捷起源于復雜的軟件開發管理領域，其關注的“產品”通常是為了解決業務問題而開發的IT功能。對于多數制造業而言，“產品”則是他們向客戶交付的實物，如藥品、汽車或手機等。

值得注意的是，敏捷在IT部門可能被解讀為對項目需求的一種響應方式，而非純粹的產品管理。這通常反映了企業的歷史背景、員工能力、經營特性及組織結構等方面的局限。

1. 敏捷與傳統項目管理的必要性

雖然現代企業中敏捷方法包含了諸如站會、規劃會議、迭代評審和回顧會議等豐富的元素，甚至定義了多種角色如敏捷教練或產品經理，但這并不意味著可以完全廢棄傳統項目管理方法。

2. 傳統項目管理的不可替代性

• 應用范圍的廣泛性：并非所有項目都適合采用敏捷方法。例如，組織一場結婚典禮、建造跨海大橋或舉辦脫口秀比賽等，這些項目由于其特定的需求和結構，可能更適合采用傳統項目管理方法。
• 宏觀與微觀的不同維度：項目管理注重宏觀戰略，明確目標、資源限制和具體的時間框架；而敏捷則聚焦于具體的操作和戰術層面，如實施細節和用戶反饋。
• 成熟度和交付保障：傳統項目管理方法因其成熟度高和能夠保障最終的交付效果，被廣泛接受和應用。與此同時，許多企業在探索敏捷轉型過程中可能會遇到挑戰，因為在軟件開發管理中不存在所謂的萬能“銀彈”。

通過以上對比和討論，我們可以看出，雖然敏捷方法極具吸引力和實用性，但傳統項目管理依然不可或缺，兩者在現代企業管理中應當相輔相成。

三、案例分享

案例1：缺少關鍵的干系人

我在一家汽車制造企業的IT部門工作，該部門已推行敏捷轉型多年，我們已經圍繞產品為中心定義并開展工作。最近，業務部門啟動了一個項目，涉及兩個不同部門的產品A和產品B。這兩個產品需要集成來滿足新的業務需求。

項目審批后，產品A和產品B的經理開始制定各自的backlog和planning。然而，某日產品A的PDO報告稱，產品B的PDO提出了一個新的需求，這超出了我們團隊的職責范圍，且現有資源無法滿足，需要引入產品C的支持。遺憾的是，最初的需求分析中并未考慮到產品C。

在問題被指出后，我被召集來尋找解決方案。兩個團隊的敏捷主管已被通知，視此為一個需解決的障礙。我的建議是召集一個項目啟動會議，包括業務代表和所有相關的IT產品經理。在會議中，我們需要明確項目目標、識別所有關鍵干系人、澄清依賴關系和管理潛在風險，以便達成共識并共同探討可行的解決方案。

案例2：前端開發的高保真原型圖問題

在另一個案例中，公司批準了一個戰略項目，雖然項目規模不大，但業務部門對此非常重視。由于項目緊迫且業務部門內部管理分散，需求澄清進展緩慢。

為加速開發進程，產品經理（PDO）與前端團隊（FT）溝通，希望他們開始基于部分已確認的高保真原型圖進行開發。然而，FT拒絕開始工作，他們堅持按照敏捷規范操作，需要PDO確認全部高保真原型圖后才能進行。

這一爭議在我威脅進行“投訴”后得到了解決，FT同意開始開發已確認的部分。此案例揭示了雙方在理解對方需求和工作方式上的差異。若PDO能在項目開始時召開一個項目啟動會，向所有相關方明確項目背景、管理層期望及潛在風險，這種誤解和延誤本可以避免。