一些產品負責人的怪味道:Scrum Product Owner常見的誤區/Yves Lin

在先前的〈傳說中的Scrum產品負責人,以及他的責任與工作〉中,筆者簡單的談了Product Owner(簡稱PO,中文翻為產品負責人)的重要性、以及我們該如何幫助PO成功。那麼,現實中的PO會遇到哪些問題呢?

[embed]https://medium.com/@smokingtuna/yves-lin-63f645a156e3[/embed]

一些常見的PO怪味道(smell)包括:

  1. 我們團隊有N個PO(N>1);

  2. 我們團隊有N個「產品待辦列表」(Product Backlog,N>1);

  3. 我們的Scrum Master也兼當PO;

  4. 我們的PO很忙;

  5. 我不知道為什麼要做這些項目;

  6. 我們直接拿某某Scrum軟體來管理Product Backlog。

這些怪味道會給團隊帶來什麼影響呢?

1. 我們團隊有N個PO(N>1)

Scrum唯一的中心點,就是「產品」;所有的人事物都圍繞著產品發生,而產品的願景就顯示在Product Backlog上,而PO則是Product Backlog的守護者。

Scrum方法之所以限定PO只能由一個人擔任,是為了讓產品資訊能集中、決策必須有效率、而且能對產品完全當責。所以,多於一個的PO會造成開發團隊「不知道要聽哪個的」、產品資訊分散、而且決策緩慢等後遺症。

2. 我們團隊有N個Product Backlog(N>1)

Scrum解決時程的方法,是讓最高價值的項目先被完成,而如果只有一份Product Backlog,先後順序就很清楚。

如果有多於一個Product Backlog,要看出先後順序就非常困難,而且容易誤解;即使一個團隊負責兩個以上的產品,PO也應該將Product Backlog合併成一份。

3. 我們的Scrum Master也當PO

如果Scrum Master加PO,正確的名稱應該叫「Team Lead」或「PM」。Scrum之所以把對產品的PO和對人的Scrum Master分開,是因為權力的過度集中不利於自組織團隊(self-organized team)的生成和發展。

我認為這一點是最嚴重的問題。因為有利於自組織團隊的環境,是跑Scrum最大的價值;如沒辦法誕生自組織團隊,不如不要跑Scrum。

4. 我們的PO很忙

PO是客戶需求的代表。按照敏捷宣言原則第4條,業務人員與開發者必須在專案全程中天天一起工作,所以開發團隊應該要能隨時找到PO,以釐清客戶需求。

如果PO太忙,表示開發團隊很難瞭解需求;這樣的風險,就是開發出來的軟體不符合需求。

5. 我不知道為什麼要做這些項目

敏捷開發靠的是所有人的自發性。如果不瞭解為何而戰,就得不到對工作的成就感、甚至影響自發性。

要知道如何讓開發團隊瞭解為何而戰,可以看看〈PO傻傻搞不清楚需求〉和〈寫一個動人的故事〉這兩篇文章。

6. 我們直接用某某Scrum軟體管理Product Backlog

Product Backlog的功用,是溝通產品的願景;而在使用Scrum軟體(Excel除外)管理Product Backlog時,通常會讓Product Backlog變成一份只有PO看的文件。

這樣一來,PO會花上很多時間試圖去完善Backlog項目的內容,而用於Product Backlog內容精進(refinement)的互動也會減少很多;原本應由開發團隊和PO協作的「what」(戰術目標),會變成PO自己一人的演講。

這樣的副作用,是導致開發團隊自以為瞭解需求,但其實並不清楚。

本文作者關於敏捷變革的譯作。

本文已獲作者授權並經本站重新編輯,未經書面許可禁止轉載。本站文章提供付費授權轉載或出版,請參閱授權說明、或來信 ask@tuna.to 洽詢。如果您喜歡這篇文章,請多按下方的「拍手」圖像幾次、或是分享到社群網站上!