近年來，敏捷開發(fā)成為了企業(yè)的首選，也成為了不少從業(yè)者的標配，產(chǎn)品經(jīng)理也不例外。那么產(chǎn)品經(jīng)理該如何用敏捷思維管理項目？本文進行了總結(jié)分析，一起來看看吧。
一、談敏捷：IT行業(yè)的新常態(tài)
近年來，敏捷開發(fā)成為眾多企業(yè)的首選，到了幾乎成為從業(yè)者的標配。敏捷方法不僅幫助企業(yè)在多個方面構(gòu)建競爭優(yōu)勢、擴大價值，而且以其思維框架和行動指南的特性，在復雜的軟件開發(fā)項目中尤其發(fā)揮重要作用。
在不斷變化的VUCA環(huán)境中，企業(yè)為了生存和發(fā)展，急需通過快速試錯，以最小的成本迅速尋找到價值點, 很多企業(yè)為了生存，都在嘗試敏捷轉(zhuǎn)型，把企業(yè)內(nèi)部的項目管理方式轉(zhuǎn)換成產(chǎn)品管理的模式，引入了新的職位，即產(chǎn)品經(jīng)理 （Product Owner， 簡稱 PDO）。
二、敏捷與項目管理：一個復雜的關(guān)系
引入敏捷的企業(yè)在培訓中常將其與傳統(tǒng)的瀑布模型對比，說明在何種情景下敏捷模式更為適用。然而，僅了解敏捷與瀑布模型的不同并不足以應對所有情形。敏捷起源于復雜的軟件開發(fā)管理領(lǐng)域，其關(guān)注的“產(chǎn)品”通常是為了解決業(yè)務問題而開發(fā)的IT功能。對于多數(shù)制造業(yè)而言，“產(chǎn)品”則是他們向客戶交付的實物，如藥品、汽車或手機等。
值得注意的是，敏捷在IT部門可能被解讀為對項目需求的一種響應方式，而非純粹的產(chǎn)品管理。這通常反映了企業(yè)的歷史背景、員工能力、經(jīng)營特性及組織結(jié)構(gòu)等方面的局限。
1. 敏捷與傳統(tǒng)項目管理的必要性
雖然現(xiàn)代企業(yè)中敏捷方法包含了諸如站會、規(guī)劃會議、迭代評審和回顧會議等豐富的元素，甚至定義了多種角色如敏捷教練或產(chǎn)品經(jīng)理，但這并不意味著可以完全廢棄傳統(tǒng)項目管理方法。
2. 傳統(tǒng)項目管理的不可替代性
- 應用范圍的廣泛性：并非所有項目都適合采用敏捷方法。例如，組織一場結(jié)婚典禮、建造跨海大橋或舉辦脫口秀比賽等，這些項目由于其特定的需求和結(jié)構(gòu)，可能更適合采用傳統(tǒng)項目管理方法。
- 宏觀與微觀的不同維度：項目管理注重宏觀戰(zhàn)略，明確目標、資源限制和具體的時間框架；而敏捷則聚焦于具體的操作和戰(zhàn)術(shù)層面，如實施細節(jié)和用戶反饋。
- 成熟度和交付保障：傳統(tǒng)項目管理方法因其成熟度高和能夠保障最終的交付效果，被廣泛接受和應用。與此同時，許多企業(yè)在探索敏捷轉(zhuǎn)型過程中可能會遇到挑戰(zhàn)，因為在軟件開發(fā)管理中不存在所謂的萬能“銀彈”。
通過以上對比和討論，我們可以看出，雖然敏捷方法極具吸引力和實用性，但傳統(tǒng)項目管理依然不可或缺，兩者在現(xiàn)代企業(yè)管理中應當相輔相成。
三、案例分享
案例1：缺少關(guān)鍵的干系人
我在一家汽車制造企業(yè)的IT部門工作，該部門已推行敏捷轉(zhuǎn)型多年，我們已經(jīng)圍繞產(chǎn)品為中心定義并開展工作。最近，業(yè)務部門啟動了一個項目，涉及兩個不同部門的產(chǎn)品A和產(chǎn)品B。這兩個產(chǎn)品需要集成來滿足新的業(yè)務需求。
項目審批后，產(chǎn)品A和產(chǎn)品B的經(jīng)理開始制定各自的backlog和planning。然而，某日產(chǎn)品A的PDO報告稱，產(chǎn)品B的PDO提出了一個新的需求，這超出了我們團隊的職責范圍，且現(xiàn)有資源無法滿足，需要引入產(chǎn)品C的支持。遺憾的是，最初的需求分析中并未考慮到產(chǎn)品C。
在問題被指出后，我被召集來尋找解決方案。兩個團隊的敏捷主管已被通知，視此為一個需解決的障礙。我的建議是召集一個項目啟動會議，包括業(yè)務代表和所有相關(guān)的IT產(chǎn)品經(jīng)理。在會議中，我們需要明確項目目標、識別所有關(guān)鍵干系人、澄清依賴關(guān)系和管理潛在風險，以便達成共識并共同探討可行的解決方案。
案例2：前端開發(fā)的高保真原型圖問題
在另一個案例中，公司批準了一個戰(zhàn)略項目，雖然項目規(guī)模不大，但業(yè)務部門對此非常重視。由于項目緊迫且業(yè)務部門內(nèi)部管理分散，需求澄清進展緩慢。
為加速開發(fā)進程，產(chǎn)品經(jīng)理（PDO）與前端團隊（FT）溝通，希望他們開始基于部分已確認的高保真原型圖進行開發(fā)。然而，F(xiàn)T拒絕開始工作，他們堅持按照敏捷規(guī)范操作，需要PDO確認全部高保真原型圖后才能進行。
這一爭議在我威脅進行“投訴”后得到了解決，F(xiàn)T同意開始開發(fā)已確認的部分。此案例揭示了雙方在理解對方需求和工作方式上的差異。若PDO能在項目開始時召開一個項目啟動會，向所有相關(guān)方明確項目背景、管理層期望及潛在風險，這種誤解和延誤本可以避免。
本文由 @紅杉閣學者 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自 Unsplash，基于 CC0 協(xié)議
該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權(quán)，不承擔相關(guān)法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
