當Pattern遇到Scrum（3）：Product Owner

June 05 23:01~23:49

▲沒有破壞，就沒有建設。

Product Owner Pattern

今天談一個比較容易理解的角色：Product Owner。該模式的原文在此，有興趣想詳讀的鄉民可以參考，今天來看Context、Problem、Force、Solution這四個元素。

Context：Scrum團隊成員需要一個單一、組織良好且循序的產品清單項目（Product Backlog Item）列表讓他們可以專注於交付價值。缺少這個列表團隊成員可能做出客戶從不或很少使用的功能、在錯誤的時間點交付功能或根本沒有交付任何功能。

Problem：誰該對Product Backlog負責？

Forces：

• 由一群人負責規劃產品需求可以獲得各種不同的看法，特別是當這群人來自不同部門與不同背景。
• 一群負責規劃產品需求的人如果只是抱持著「被諮詢」的態度，沒有一個人被授權對各種意見做出最後決定並扛下責任，則整個產品需求決策過程會拖很久而拉長產品上市的時間。
• 如果好幾個負責規劃產品需求的人都是「老闆」，有權做出最後的決定，則很有可能這些人彼此的意見都喬不攏，最後導致冗長的討論與政治角力。
• 雇用專職的專案經理來管理專案開發活動與進度是很普遍的做法，但這種作法並不能解決問題。因為團隊開發的是「產品」並不是開發專案，而專案經理並不負責開發產品所需關注的投資報酬率（ROI）。

Solution：讓一位Product Owner（產品負責人）來排序Product Backlog項目、負責產品願景以及交付願景過程中所產生的價值（也就是投資報酬率）。

***

討論

看完上述內容，鄉民們可以試著思考下列三個問題：

1. 除了上面這四個forces以外， 關於「誰該對Product Backlog負責」這個問題，在你的專案中是否還存在其他不同的forces？
2. 你的Product Owner是否平衡了這些forces？
3. 套用Product Owner這個模式可能產生那些結果（Resulting Context）？

***

友藏內心獨白：沒人負責就做不出好產品。