在談完 LeSS 的產品和組織結構後, 接下來我們要談的是 LeSS 中的角色. 它和 Scrum 很像, 也有三個角色：產品負責人, ScrumMaster 和團隊 我們就一一來介紹他們.

LeSS 和 Scrum 中 Product Owner 的角色有什麼不同呢? 我們先來看看 Scrum Guide 2020 中的描述

Product Owner 負責將把 Scrum Team 的工作所打造出來的產品價值最大化。如何做到這一點可能會依組織、Scrum Teams 和個人的不同而有極大的差異。

Product Owner 也負責對 Product Backlog 進行有效的管理，包括：
● 開發並明確的描述溝通 Product Goal；
● 創造並清楚的描述溝通 Product Backlog items；
● 對 Product Backlog items 進行排序；和，
● 確保 Product Backlog 是透明的、可見的與可理解的。

Product Owner 可以自己做上述工作，或者也可以將職責委託他人，然而，Product Owner 仍肩負最終責任。

而在 LeSS 的規則中定義如下

(1) 對整個產品只有一個產品負責人(Product Owner)和一個產品待辦列表 (Product Backlog)
(2) 產品負責人不應該獨自處理產品待辦列表的梳理工作；藉由讓多個團隊直接和客戶／用戶以及關係人直接互動, 來進行梳理的工作
(3) 所有的優先級排序都通過產品負責人來決定，但是澄清盡量由團隊和客戶／用戶以及關係人來直接溝通進行

在 Scrum 中產品負責人最重要的兩個任務是 a. 決定產品待辦列表內條目 (Product Backlog Item) 的優先順序. b. 梳理產品待辦列表內條目的內容. 但是到了 LeSS 中, 上述 b 中釐清需求的事情, 變成是團隊主要工作, 產品負責人會參與, 但是不見得是他要主導. 由團隊主動釐清需求內容.

圖片來源: Youtube: Exploring the Role of the Product Owner & ScrumMaster through LeSS, https://www.youtube.com/watch?v=QDGbWBzjHtM&t=4s

(1) 確保團隊真的了解

如果都是產品負責人跟 Feature Team 講解, 這樣比較像是單向溝通, 有時候很難確認 Feature Team 是否真的了解. 讓 Feature Team 主導釐清, 產品負責人來支持, 這樣可以確保 Feature Team 對需求有掌握度.

(2) 讓團隊了解客戶

在 LeSS 中團隊是需直接面對客戶, 不是讓產品負責人轉傳客戶的資訊, 這樣可以避免傳話遊戲的問題, 也讓團隊有機會觀察客戶背後沒有說的需求. 唯有真的和客戶在一起, 做出客戶想要的系統的機會會更高.

(3) 分散產品負責人的負擔

產品負責人要面對這麼多團隊, 要寫需求給這麼多人開發, 基本上這樣做, 產品負責人只會變成是瓶頸, 需求不出來, 開發絕對快不起來. 因此, 團隊能夠直接和客戶釐清需求, 可以幫忙減輕產品負責人的負擔.

所以在 LeSS 中, 以下是事情不該是產品負責人負責, 最好是委託團隊去做：

(1) 釐清需求問題

理由如同上述所說. 不再贅敘.

(2) 跨部門協調

在大規模開發時, 很多時候團隊之間需要協調, 像是用到相同的元件, 有些功能之間有相依性等等, 這些都是在一線實作的人才會知道, 第一時間產品負責人不會知道, 這些問題不太可能都要產品負責人去協調, 安排開會時間. 有些可能是技術問題, 產品負責人也不一定懂. 所以由團隊自己來會比較有效率. 如果是跟需求有關, 可以邀產品負責人一起參與, 讓他知道可能的改變, 或許他是需要因此調整優先順序的. 但是這都是讓團隊發動的.

(3) 行政管理庶務

例如像是開會通知, 借會議室, 記錄開會討論內容, 這些可以團隊內找人輪流分擔, 如果都是產品負責人來說, 他就沒有時間去做更有價值的事.

(4) 替人傳話

有時候團隊的成員會希望產品負責人, 幫忙傳話給其他部門, 或者是客戶. 他們可能怕自己的地位不夠, 但是這樣傳話可能會花更多時間, 也可能造成原意失真. 最好是團隊自己直接溝通. 如果你覺得需要產品負責人也知道結果, 可以事後把結果通知給他知道. 或者這是 email 時, 可以把他放到 mail loop 中也是可以.

比較完 Scrum Guide 和 LeSS 對產品負責人的責任不同後. 接下來我們聊聊要如何找產品負責人, 根據 LeSS 的分類, 產品負責人負責的產品可以分成以下三種

(1) 外部的產品開發

通常是業務單位或產品事業群因應市場的需求, 或者是老闆有個想法, 因此就有這個產品的誕生. 通常產品負責人會從這些單位出來 (但絕對不是老闆出來當), 會是一個不錯的選擇.

(2) 內部的產品開發

公司內部也會有些問題, 需要內部團隊, 像是 IT 部門, 來幫助他們. 這時候最好找實際在這些問題工作很久, 有很多處理經驗的人來擔任. 他不但貼近用戶, 本身也可能是個好用戶.

(3) 專案的開發

公司會接到外部客戶提出需求, 希望公司能夠提出解法, 幫助他們解決問題, 幫助他們在商業上成功. 產品負責人最好來自提需求的公司或單位, 他需要實務經驗豐富, 並且貼近那些真實的用戶.

圖片來源: https://less.works/less/framework/product-owner

在 LeSS 中提到, 產品負責人和團體中其他成員, 有以下五個重要關係：

圖片來源: https://less.works/less/framework/product-owner#FiveRelationships

(1) 產品負責人 和 團隊

從 Scrum 的角度來說, 產品負責人 和 團隊 應該要關係最緊密的. 但有時候可能不是這樣的, 有時候這兩個可能是最熟悉的陌生人, 平時只靠 email 聯絡, 開會完後可能就不再見面. 這樣要能高效也不容易. 在 LeSS 中, 以下幾件事情是產品負責人 和團隊要多注意注意

a. 產品未來走向
對於團隊成員來說, 他們想要知道產品的方向是什麼, 以及未來大概要做哪些功能. 這部分往往是產品負責人會忽略的, 或者是沒有時間去整理這些資訊. 敏捷開發中, 影響地圖 (impact mapping) 和故事地圖 (story mapping) 便可以幫忙這件事情.

b. 回顧會議
雖然 Retrospective 會議, 產品負責人不一定要參加, 但是這是個可以聽到第一線聲音的機會. 你可以從中了解他們的問題, 並且有機會加強彼此的關係.

c. 合作關係, 而非發包
有些公司產品負責人是將工作發包給可以承接的團隊. 所以一個是甲方, 一個是乙方的關係. 通常甲乙方的關係往往就是不對等, 甲方通常會欺凌或是壓榨乙方. 因此如何營照團隊的感覺, 是雙方都應該重視的.

(2) 產品負責人 和 客戶/實際用戶

產品能不能成功, 客戶或實際用戶的回饋和參與, 是非常關鍵的事情. 很多工程師在實施 Scrum 時, 比較偏重工程實踐的落實, 或者是團隊自己本身的關係, 卻不擅長去經營客戶關係. 因此, 產品負責人要在這幾方面下功夫

a. 頻繁發布

每次迭代最好都能交付些價值, 讓客戶可以使用某些功能, 一方面讓客戶放心, 認爲團隊總是有幫他們解決一些問題. 另一方面, 產品負責人也可以藉此得到回饋, 看看這些功能是否有效, 以及早調整後續方案.

b. 讓客戶參與

隨時要客戶參與開發的活動, 這樣才能讓團隊和產品負責人即時知道他們的反應. 像是 PBR (Product Backlog Refinement) 會議, Sprint Review 會議等等, 在釐清需求和需求做完展示時, 聽聽他們的想法, 不是只是一開始找他們, 而是隨時隨地讓他們加入.

c. 即時回饋

很多時候團隊會開發來不及, 或者是對需求內容有些調整, 或是他們之前提出的問題已經有進展, 這些資訊產品負責人要第一時間通知客戶, 讓他們知道事情又變, 或是有進展, 讓他們覺得團隊和他們是一起的. 不是到最後才知道發生什麼事情.

(3) 產品負責人 和 管理高層

產品負責人要為產品的成敗負責, 但是要讓管理高層覺得你是負責成敗的關鍵角色, 也讓要他們覺得這個產品很重要. 因此, 產品負責人要向上管理.

a. 教育產品價值

產品負責人應該是全公司對產品最了解的人, 因此他有義務對所有人宣傳產品價值, 尤其是公司高層和客戶, 讓他們知這這個產品可以帶來什麼價值, 可以解決什麼問題, 可以幫助客戶如何成功. 得到他們的支持, 會幫助團隊獲得更多助益.

b. 溝通產品方向

有時候高層會對產品有些想法, 雖然不一定正確, 但是有機會和你想的不同, 這時候產品負責人花時間和他溝通, 說明相關背景資訊, 或者了解他們的考量, 互相交換對方不知道的部分, 這樣才不會太多意外發生.

(4) 客戶/實際用戶 和 團隊

在 Less 中, 團隊需要直接和客戶釐清需求, 並非是產品負責人釐清好需求, 在轉告給團隊知道. 為了讓這件事情可以做好, 產品負責人可以幫忙

a. 整理和聯繫雙方關係

有時候產品相關的利害關係人很多, 可以幫團隊先把這些資訊整理下來, 讓他們知道可以去找誰. 因為團隊大多是工程背景出身, 比較不擅長溝通, 因此可以幫他們先開個頭, 把大家連在一起, 之後就可以交給團隊去處理.

b. 提醒雙方要注意的事情

產品負責人對客戶和團隊都很熟, 對於雙方可能習性或是不能碰觸點應該都很清楚, 或者是怎樣溝通, 對方比較容易聽進去, 這些都可以先跟對方說, 讓雙方溝通比較順暢.

(5) 產品負責人 和 ScrumMaster

產品負責人是要確認團隊做對的事, 而 ScrumMaster 是要確認團隊用對的方法做事. 因此, 產品負責人要和 ScrumMaster 溝通, 如何才能團隊有對的方法, 做出對的事情. 例如: 實例化需求 (Specification By Example). 怎樣讓團隊和產品負責人早期就把需求釐清清楚. ScrumMaster 是這個流程的引導者, 幫助產品負責人能講對需求.

產品負責人可能對 LeSS 或 Scrum 不是很了解. 或者在某些警急的狀況下, 例如插件, 需求不情楚, 品質低落等等, 要如何才能把 LeSS 給跑正確. 這時候就會需要 ScrumMaster 的建議.