產品經理如何用敏捷思維管理項目

0 評論 1485 瀏覽 2 收藏 7 分鐘

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

一、談敏捷: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能在項目開始時召開一個項目啟動會,向所有相關方明確項目背景、管理層期望及潛在風險,這種誤解和延誤本可以避免。

本文由 @紅杉閣學者 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!