誰來當Product Owner

June 30 10:20~12:19

 

一年多前有一次機會Teddy去觀察某個Scrum團隊運作，這個團隊是公司內部的研發團隊，主要的工作是開發後端管理平台讓公司維運人員使用。此外團隊還要提供API，讓其他部門的開發團隊可以透過API來和後端管理平台整合。這個團隊當時正準備啟動一個新專案，支援客戶（公司內部另一個部門）新的業務需求。

當Teddy參加完第一個sprint planning meeting之後，發現了一個有趣的現象，就是「沒有人願意承認自己是Product Owner」。

***

Teddy ：請問你們的Product Owner是誰？

團隊：應該是客戶吧，因為他們有權決定需求的先後順序。

Teddy ：那你們的客戶有寫story嗎？

團隊：沒有耶，story是我們大家分著一起寫出來的。客戶不會寫，應該也沒時間寫story，他們還有很多事情要忙。

Teddy ：那你們怎麼知道要寫那些story？

團隊：因為這個專案不是一個全新的專案，而是已經開發好幾代的系統，現在只是要在上面加一些新功能。我們大致上知道有那些功能要做，只是誰先做以及一些需求上的細節需要跟客戶確認。

Teddy ：所以你們自己先把你們認為要做的story寫出來，然後利用sprint planning meeting的場合跟客戶確認？

團隊：差不多是這樣。

Teddy ：那請問如果這個案子失敗了，要由誰負責？

團隊：這…很難說耶。案子失敗了我們的考績和客戶的考績都會受影響…

Teddy 內心獨白：所以就是說…沒有人需要負責？

Teddy ：那你們團隊為什麼不指定一個人來當Product Owner呢？

團隊：不行啦，需求的內容和優先順序又不是我們決定的…

Teddy ：你們可以把客戶當成stakeholder，然後在團隊成員中指派一人當Product Owner。雖然說需求的內容和優先順序是由客戶（stakeholder）決定，但是一但你們指派了團隊成員當Product Owner，也可以想成Product Owner參考stakeholder的意見來決定需求的優先順序。請參考下圖。

 

團隊：可是這樣就變成我們要承擔案子的成敗，這樣也不合理啊。我們的人變成Product Owner之後，說不定客戶就偷懶，以後就不來參加sprint planning meeting了…

喬了老半天，結果這個案子還是在「不知道誰是Product Owner」的情況下繼續進行。

案子最後是有順利完成，從「結果論」來看，這種「不知道誰是Product Owner」的情況好像也沒什麼重大缺點。但是Teddy內心還是覺得，就算是要採用這種「不知道誰是Product Owner」的運作模式，開發團隊還是應該要指派一人作為「地下 Internal Product Owner」，由此人來統整從stakeholder與開發團隊而來的需求，並且要安排足夠的時間給「Internal Product Owner」，讓他可以扮演好這個角色。

***

最近重讀Alexander的《Notes on the Synthesis of Form》，再回頭思考這個問題。假設在導入Scrum之前，開發團隊與客戶的溝通模式，可能是下方左圖或右圖的狀態：溝通複雜度過高（光是找到對人的來問問題就花了很多時間）或鮮少溝通（結案的時候才一翻兩瞪眼）。

         

 

如果是採用「標準版」的Scrum，團隊中會包含一位Product Owner（PO），由他來和客戶溝通需求。兩個子系統（客戶和開發）內部的溝通複雜度可以很高（內聚力很高），但子系統之間的溝通複雜度由Product Owner隔開（降低不必要的耦合）。

在「不知道誰是Product Owner」的情況下，Product Owner的責任由客戶與團隊共同分擔。其實開發團隊還是有一個主要的人扮演著「Internal Product Owner」的角色，只是扮演這個角色的人不願意公開承認（雖然再度違反了Scrum的規範，在這種情況下此人通常是由ScrumMaster兼任）。

***

Product Owner是一個很辛苦的工作，在某些專案中，要找到願意且有時間、有能力接受挑戰來擔任Product Owner的人的確是非常困難。公司內部IT部門協助其他部門的專案開發就是一個很典型的例子，接外包案的專案也有類似的問題。Teddy目前的經驗，在這種「不知道誰是Product Owner」的情況下要成功，最好要把握以下幾點原則才不至於逆練九陰真經練到走火入魔：

• 要把客戶洗腦到能夠接受專案採用value-driven的方式開發。
• 客戶要一起參加sprint planning meeting (part 1)與sprint review。
• 團隊指派一人作為「Internal Product Owner」，並給他足夠的時間來扮演好這個角色。
• 把客戶的考績跟自己的考績綁在一起（目標一致，大家在同一艘船上）。

***

友藏內心獨白：Alexander的書真的有提到內聚和耦合的觀念啊。