故事是這樣的

筆者有不少朋友都很認真地在其所在環境，於日常工作中實踐敏捷開發。而過程中總免不了遇到一些困難。以下是我其中一位朋友 Jasmine 的真實故事...

Jasmine 的公司原本是以工廠產線的方式在進行產品開發。他們有一個「衝量」的政策，其 KPI 叫做「每三個月要產一款遊戲」。據她們大部份同事的了解，在此政策下，每三個月一到，你就是要有一款遊戲。在此前題之下，能做到多好玩就做成多好玩，畫面能做多 fancy 就做多 fancy，但無論如何，三個月一款遊戲的 KPI 是不容挑戰的限制。

「有限的時間，不變的資源，最大化價值，那不 Scrum 要幹嘛？」Jasmine 心裡這麼想著。於是，本著 fail fast 的精神，跟大多數的人一樣，她們也就這樣直接開始 Scrum 了。

一開始，大家受益於 Scrum 的「週期」特性，都覺得開發的目標變明確了，士氣大增。但時光飛逝，轉眼過了兩個月，開案前就建好的待辦清單還有一大串都還沒做。這時，身為 PO 的 Jasmine 開始感到不安，這樣下去一定做不完，但同時她又不希望大家加班，這該怎麼辦？

Jasmine 很久以後跟我說了這段故事，我是覺得合理，因為人又沒變，目標也沒變，成員的程度也沒有突然提高，本來就不會因為你跑了個 Scrum 就突然從海綿寶寶變成馬蓋先，對吧？但這都是後話了…

總之，當下 Jasmine 靈機一動：「啊！都說 Stakeholder 的參與很重要，那我來問一些資深前輩的意見吧！」

不問還好，一問了以後，公司內這些前輩們這才發現：「原來我可以給意見啊！」便紛紛給出自己獨到的見解，而 Jasmine 身為新手 PO，自然是這也加進來，那也加進來，把原本就做不完的 Backlog 加得更長了不說，重點是這些意見有些還彼此矛盾！

故事聽到這，我不禁好奇這些「前輩」怎麼來的？「就那些 component teams 的主管們啊！」Jasmine 回道。我一聽心頭一驚，不出意外馬上要出意外了。果真，後來就發現團隊開始做一些 Backlog 上沒有的東西，PO 一問之下才知道是身為 component team 的「前輩」私下叫該 RD 改的。也難怪！你讓他覺得他可以出主意嘛！那他還不出爆你？

幸好，我的好朋友 Jasmine 也是有在持續改善流程的。總之，為了解決這新衍生出來的「Stakeholder 意見太多導致原本做不完的產品更加做不完」的問題，她與團隊討論出一個做法：讓這些 Component Team 的 Leader 們組成華麗的「Stakeholder 天團」，以藉此整合意見，才不會有各自私下給出彼此矛盾的意見，讓團隊無所適從的問題。

這個「Stakehokder 團」可不得了！成團以後意氣風發，每天遊走在各產線之間到處賜教，給每個產線他們彙整過，工作多年的寶貴意見。每個產線都雨露均沾，大家在開發時，都受到「Stakehokder 天團」大量的功力灌溉，每個人都如沐春風，功力大增一甲子。

...當然沒有！

「導入敏捷」以後，原本不加班的也都開始加班了。最慘的是好不容易做出來的東西，送到客戶那，還被客戶批評是「千篇一律、沒有創意」。

「我不是都照足 Stakeholder 的意見了嗎？為什麼還是改善不了產品與流程？」Jasmine 不解問道。

PO 的權責

做產品我不是專家，她們公司的領域，我相信更擅長的大有人在。只是聽完這一串故事，我發現一個地方明顯的有問題：「PO 的權責」。

我們先來看看 Scrum Guide 怎麼定義 Product Owner（PO）的：

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team... may vary widely across organizations, Scrum Teams, and individuals.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

上面原文有點長，筆者試著用自己的方式來解讀如下：

儘管在不同組織中細節有所不同，但 PO 的主要職責，就是要透過安排團隊的工作，讓產品的「價值最大化」。

於此同時，成功的 PO 有一個特性，就是得到整個企業的尊重，尊重 PO 對產品所做的所有決定，包含 Product Backlog 的順序，以及 Sprint Review 中大家看到的產品內容。

最後，PO 是一個個人，而不是一個委員會。PO 的工作是把 stakehoklers 的需求透過 Product Backlog 表現出來。但！這些需求要怎麼安排，依舊是 PO 的決定。如果 stakeholders 想插手，那就只有一條路：「試著說服 PO」。

被架空的PO、被取交集的意見

按照 Scrum Guide 的定義，對產品的樣貌、進度、演進等等議題有一個 Whole Picutre，並有最終決定權的人只有一個人，那就是 PO。

Scrum Guide 這麼定義是有其原因的。我是 PO，我擁有最終決定權，同頭產品的成敗也是我的責任。權責相當，自然我要去盡一切努力讓產品價值越來越高。

而我的朋友 Jasmine 的 Scrum 卻不是長這樣。就我聽她的故事，有以下事情不太合理：

1. 在產品「開案的第一天」就決定好所有功能。如此一來，其實 PO 也就不用管 Feature 在 Product Backlog 裡的順序了。為什麼？因為你提前做好最重要功能也不能先上線，而且有寫過 Code 的人就知道，把 Feature 照順序安排並分段交付，對 RD 來說是會有一些 Redundancy 要處理的。如果這些 Features 做完後不能馬上上線驗證價值，這時這些處理 Redundancy 的付出就是一種浪費。
2. 有一個固定的 Deadline，同時也有一個固定的功能清單。同上一點，身為 PO，最大的工作目標就是提高產品價值。如果你不管怎麼安排順序，目標都是「把 Product Backlog 消化完」，那你其實沒有在提升價值。更精確的說，你正在把原本可以拿來「不斷提升價值」的時間，浪費在「不確定會不會中，但不在期限內做完不行」的事情上。
3. 想要滿足所有 stakeholders 的所有需求。這也是對 PO 來說最致命的一個思維模式。stakeholder 何許人也？他負責產品成敗嗎？並沒有，負責產品成敗的是 PO 與團隊。試想，今天一個人來請你出主意，不管你說什麼他都會照做，掛了也不用你負責，你會怎麼做？你還不卯起來天馬行空地瞎說？這還不是最傷的。你認為，這個天團所有人的「交集」，有可能多有變化？
4. 為解決 stakeholder 的意見相互衝突的問題，甚至組了一個權力大如山的「stakeholder 天團」來整合意見。這才是最傷的。試想，同樣一群人組成的天團，在每一個產品都去用力的給意見，並且每一個 PO 都會使命必達地滿足。你認為，同樣一群人，在差不多的時間點，在 A 產品整合出的意見，跟在 B 產品整合出的意見，again，有可能多有變化？

滿足所有 Stakeholders 的所有需求示意圖

你是 PO 還是 PM？

姑且不管這裡的 PM 是指 Product Manager 還是 Project Manager，「管理時程」也都不是 PM 唯一的工作。Scrum Guide 定義了一個角色名為 Product Owner，顧名思義，這個人應該要「擁有」這個產品。按照 Agile 界常見的說法：「你說這會中，那從現在開始，這個產品的研發成本，老闆出一半，你 PO 出一半，你幹不幹？」

當然，我們不就是沒錢才給老闆請嗎？但不出錢可以，把 Product 當成是「自己的」，總該做得到吧？對產業做研究，為產品找方向，規劃短、中、長期的產品樣貌（越遠可以越模糊無妨），對 stakeholders 的意見心中要有「度」，不要照單全收，讓你身為 PO 的「權」與「責」能夠相匹配。

這樣，才不會像我的朋友 Jasmine 一樣，忙得焦頭爛額，到頭來被 stakeholder 嫌做得慢，被客戶嫌做的東西千篇一律，最慘的是還被 RD 抱怨「Scrum 有個 P 用，我們還不是要加班」。那就沒意思了。

謎之聲：「你是 PO 還是 PM？還是 Stakeholders 的傳話筒？還是行走的 Google Calendar？」

Reference

1. Scrum Guide (https://scrumguides.org/scrum-guide.html#product-owner)