目錄
敏捷專案管理興起之後，很多人會發現在敏捷的架構下，專案經理的職稱不見了。「專案經理」與「專案成員」的角色，被「產品負責人」、「Scrum Master」與「開發團隊」所取代。
那麼，產品負責人的工作是否與專案經理相同呢？
要回答這個問題，我們可以將專案經理的工作以下表來簡要摘述，說明一下敏捷團隊中原來專案經理的角色是如何被分攤的。
專案經理的主要工作與敏捷團隊的對應工作承接者
| 專案經理的主要工作 | 敏捷團隊的對應工作承接者 |
|---|---|
| 對專案團隊外部的所有溝通協調工作，包括：公司內的各個部門、上級主管、公司內外部的相關人員、客戶、供應商、各種利益關係人等 | 產品負責人 |
| 專案本身的規劃、預算與進度掌控，包括專案的願景、範圍、產品地圖（Product Roadmap）的規劃、發布時程的安排、產品待辦清單的梳理、各種任務的優先等級排序、預算控制、投資報酬率估算等 | 產品負責人 |
| 專案團隊內的工作分配、開發與執行過程的細部規劃、日常協調工作、監督管理等 | 團隊成立初期或運作上較不成熟時可能會由Scrum Master從旁協助，在團隊運作漸上軌道後，由團隊成員自主管理，按時召開Sprint規劃會議、每日站立會議、Sprint審查會議、以及Sprint回顧會議。 團隊運作越上軌道，Scrum Master介入越少。 |
從以上表格可以發現，在敏捷專案管理的架構下，專案經理的工作得到相當大的簡化，團隊內部的人員管理工作轉由團隊成員自主管理，並設立新的功能角色-Scrum Master來輔助。
簡單來說，相對於傳統專案經理的工作，產品負責人更著重在專案的規劃層面，更聚焦在「對外」的事物，而把「對內」的人員管理工作盡可能地減少。
延伸閱讀：敏捷團隊的靈魂人物，成為敏捷教練之路
產品負責人的6個主要職責
由於敏捷的架構本身具有相當的靈活性，所以每一家公司的產品負責人，隨著專案特性或公司文化的不同，職責上可能還是存在一些差異。
一般來說，產品負責人具有以下幾個主要職責：
職責1：規劃產品願景
產品負責人必須非常清楚專案的最終目標是什麼，什麼該做？什麼不該做？對於最終用戶或是投資人而言，專案將帶來哪些價值？
身為產品負責人最難說出口的關鍵字就是「不」（No）這個字。每個需求單位都希望自己的需求能優先被滿足，都希望專案的成果越多越好，都希望開發速度越快越好。
產品負責人必須要有說「不」的勇氣，決定專案最後的產出是什麼。決定不做什麼有時要比決定做什麼更加困難。
職責2：排序及維護產品待辦清單
資源永遠沒有充足的時候，產品負責人必須決定哪些工作優先處理？哪些可以延後？
在安排工作時程時，除了考慮既有資源，也要考慮各種利益相關者（stakeholders）與用戶的需求，以及開發團隊的能耐，在各種約束條件下取得一個平衡的結果。
職責3：管理專案的預算
每個專案都會有預算的限制，不管是傳統的專案管理或是敏捷專案管理都是一樣的。
最主要的差別在於傳統的專案管理有一個完整的計畫，可以很清楚的掌握專案完成的百分比，依完成的比例動支預算。而敏捷專案管理會優先完成最具有商業價值的部分，預算的花費不一定是照專案進度等比例的支出，產品負責人必須在預算控制上花費更多的心思。
這或許可以解釋在敏捷架構下，產品負責人必須把團隊內部管理的工作全部轉給Scrum Master及開發團隊自主管理的原因，因為這樣產品負責人才能更專注在專案的規劃與管理上。
職責4：規劃每個迭代的發布日期以及產品上市
相對於傳統的一次性交付成果，敏捷專案會在過程中以多次交付成果的形式，來更貼近用戶的需求。
身為產品負責人，你必須計畫每次展現給用戶或利益相關者的價值是什麼。當然，身為產品負責人都希望能不斷提供用戶或利益相關者更多的驚喜，但你必須考慮開發團隊的實際能力，權衡各種可能限制，仔細計畫每個Sprint（或稱為迭代）的成果展示。
專案完成時，產品負責人也需要規劃一個成果發表會，將最終成果移交給用戶。
職責5：讓利益相關者參與到專案之中
敏捷專案管理一個很大的特色就是在開發過程中的互動。
互動的對象可以是最終用戶、需求規劃者、高層的管理者，或是所有與專案相關者。透過過程中的互動，讓專案的成果能更接近眾人的期望。人們經常要看到成果後，才會發現自己真實的需求所在，所以產品負責人必須在專案全程，讓與專案成敗相關的所有人，也就是所有的利益相關者參與進來，以確保專案的進度在正確的方向上。
值得一提的是，不是所有利益相關者都願意在專案開發過程中，每一到兩週就參與一次Sprint審查會議，針對專案的階段性成果提供回饋，產品負責人必須花費一些心思，才能讓所有利益相關者定期參與到專案開發的過程中。
如果利益相關者無法親自出席，必要時產品負責人必須代表利益相關者決定是否接受開發團隊的階段性工作成果。
職責6：出席Scrum相關會議並與團隊成員合作
雖然產品負責人不像傳統專案經理需要負責開發團隊的日常管理，但產品負責人與開發團隊的互動仍不可免。產品負責人必須參與開發團隊以下的會議：
1，Sprint規劃會議
開發團隊必須決定他們在每個Sprint（或稱為迭代，也就是每一個工作循環）該完成哪些工作。
產品負責人必須參與Sprint規劃會議，分享最新的產品待辦清單，讓開發團隊知道哪些工作需要先完成，以及用戶的需求與期望。
在會議中，產品負責人代表用戶與所有利益相關者來與開發團隊溝通，以用戶故事（User Story，也稱為使用者故事）的格式來表達用戶的需求。產品負責人也必須傾聽開發團隊的困難與疑慮，在會後將問題反映給利益相關者，或是尋求澄清，來做為一個內外部溝通的橋樑。
延伸閱讀：讓「使用者故事」替你聚焦工作任務
2，Sprint審查會議
這是開發團隊呈現成果，並與用戶或利益相關者當面溝通的機會。
產品負責人應該努力讓用戶或利益相關者能親自出席，讓他們與開發團隊能有面對面溝通的機會。如果他們不能出席，就由產品負責人代表接受或退回開發團隊的工作成果。
3，Sprint回顧會議
如果將Sprint審查會議視為對外的會議，那麼Sprint回顧會議就是對內的會議，產品負責人、Scrum Master以及開發團隊成員全員出席。
換句話說，在回顧會議上團隊檢討的是內部的運作流程，而不是產品開發上的問題。在會議上團隊通常會回答三個問題：
- 「什麼進行的順利？」
- 「哪些地方需要改變？」
- 「接下來該怎麼做？」
透過三個簡單的問題，不斷精進團隊的內部運作與工作銜接，這也是敏捷架構中落實「持續改善」精神的一個主要活動。
延伸閱讀：高績效敏捷團隊維持專案品質與效率的秘密—視覺化的「帆船回顧會議」
4，選擇性列席開發團隊的「每日站立會議」
產品負責人可以選擇性的「列席」開發團隊的「每日站立會議」。
在每次不超過15分鐘的工作進展報告中，產品負責人可以很快地掌握專案實際的進行狀況，瞭解開發團隊對專案需求的真實掌握情形，以及出現的障礙與困難。
延伸閱讀：一次搞懂每日站立會議(Stand up meeting)！全面提升敏捷團隊績效
總結
總結來說，產品負責人與專案經理的角色在很多方面都是類似的，尤其是在專案整體的規劃與控制，以及對外協調的部分。
最主要的差別可能是在對內部人員的管理方面，產品負責人的稱謂去掉「經理」兩個字，某種程度也反映出新的角色會更專注於「管事」，而把「管人」的工作交給Scrum Master及開發團隊去承擔。
這也代表者產品負責人在淡出人員的日常管理瑣事之後，相對於傳統專案經理，能更專注在有價值的工作上，提高專案的成功率，以及專案所能帶來的商業價值。
VUCA world we need!
『敏捷模式』 啟動企業數位轉型
「敏捷性」是什麼?
最簡單的定義，就是針對環境的變化，進行快速的偵測與回應，以維持或提升經爭優勢的能力。
「敏捷的企業」是什麼?
一群敬業的人不懈地專注於客戶價值；不斷改進其運作方式；並使用經驗主義，以可持續的方式迅速接受變革。如何轉型為敏捷企業，我們可以從：個人、團隊、組織三個面向來探討。
課程介紹
Individual 個人
Organization 組織
Team 團隊
您也有訓練需求嗎?
填寫訓練需求表單，我們將盡快派專人與您聯繫，提供相關培訓建議與資料，以協助您的企業人才持續發展。
