“ Product Owner（PO）其實是敏捷交付裏面最重要的角色之一，然而也是最難的角色。”
曾經在Facebook擔任過產品經理的馬丁內斯在他的書《混亂的猴子》裏寫到：
“在Facebook，產品經理產品經理就是一把大便傘，就是那把擋住髒東西的傘。因爲Facebook內部的干擾信息太多了。比如，部門和部門之間互相排擠，層級制度太複雜，審批決策的週期太長，等等。有些需求，從作者提出想法，到最後扎克伯格拍板，前後用了一年多的時間。這個緩慢的節奏，還有複雜的外部信息，對開發人員的干擾太大了。所以，作爲產品經理，他必須要把所有的壞消息都擋在外面，讓技術人員安心搞開發。所謂大便傘，就是一個壞消息的屏障。”
這也許就是對類似產品經理這樣的PO的角色的最生動的描述。
作爲交付團隊，我們都期望有PO幫我們擋“大便”，但這樣的超人很難在現實中存在。
01
—
“我們什麼都想要”
受到疫情影響，A公司的業務受到較大打擊。由於第一季的收入銳減，業務部門也要大幅削減IT的支出。IT部門因此受到牽連，要收縮人員編制。
由於IT的人手變少了，年頭計劃的項目很多都無法繼續，需要業務部門決定在現有預算下，把資源集中投放到哪些項目。
然而經過幾周的討論，業務依然無法給出清晰的決定。“所有項目對我們都很重要，我們都想要。”但對於IT部門來說，巧婦難爲無米之炊。雙方卡死了。
02
—
PO的窘境
如果業務部門連在預算有限的情況下，做哪些項目、不做哪些項目這麼大的決定就難以做出，那麼可以想象，要PO對產品、項目裏更具體、更細節的需求或用戶故事做決定，就更難了。
Product Owner（PO）是代表業務或產品、項目干係方，要爲產品、項目中的需求或用戶故事根據其業務價值做出優先級排序這樣的業務決策的角色。
這個業務決策看似簡單，實則不然。主要的困難就在於業務干係人可能來自不同部門、不同地區，他們都有各自的利益需要維護，因此難以達成統一的優先級。
我們期望有一個人可以擋在交付團隊前，擺平各個業務部門和干係方，讓交付團隊聚焦在排序好的有限需求中，踏踏實實地完成交付。然而現實中這樣的期望往往會落空。
得到的結果，往往也是什麼都要做，使得交付團隊疲於奔命。在這種情況下，產品、項目交付哪有不翻車的道理？可以說，優先級不清晰，或者優先級經常變化，是所有交付問題的萬惡之源。
03
—
解決之道
對於這一難題，其實我也沒有什麼標準答案。這裏只能拋磚引玉，以供大家一起探討。
我想到的解決之道有三個：
重新定義業務產品
PO難的其中一個原因是對接的業務干係人衆多，“衆口難調”，而且他們之上又沒有一個絕對的領導掌握這些細節作出決策。
我們需要和業務部門重新定義業務產品，滿足以下三個條件：
拋開現有組織架構、系統架構的限制，對接目標客戶，簡化決策關係；
新的業務產品要能建立共同的使命和願景；
新的業務產品必須有一個絕對領導，這個領導的利益是和這個產品緊密捆綁的，TA也掌握大部分細節。
這個過程，主要就是要重塑權力關係、簡化決策。
當這些新的業務產品定義好後，IT團隊和系統架構也要進行重構，以實現與業務產品對齊，逐步與相關業務人員形成跨職能的自組織團隊，實現產品化交付。
量化業務價值
也就是計算“延遲成本（Cost of Delay）”——計算每個請求如果逾期會造成的損失，折算成金錢，這樣便可以量化所有請求的優先級。
延遲成本可以量化所有請求，從而基於它對所有請求進行排序，得到一個大家都必須認可的總列表。當然延遲成本的計算和校驗並不容易。有成功實踐的朋友可以在留言區分享。
服務等級
對於不同的請求類型，賦予不同的服務等級，區別處理。
在看板方法中，可以結合請求的服務等級做出不同的響應。常見的服務分類有：
加急類（Expedite）——常見於一些時效性特別強的需求，或者對產品重大缺陷的修復。這一類請求將被視爲最高優先級，因此可以無視最大在製品數（WIP）的限制，直接進行作業。然而這樣的請求，很容易對看板的正常工作造成衝擊，因此加急類的任務個數，通常都僅設置爲1。
固定交付日期類（Fixed Delivery Date）——推薦安排一定的產能，來處理一些固定交付日期的請求。對於這一類的請求，需要交付團隊在開發之前對請求的工作量進行估算，並與PO確定目標交付日期，在開發過程中定期的確認進度。一旦發現進度落後到有可能無法完成的情況，則需要交付團隊對請求重新進行評估。如有必要，這類請求可以升級爲加急類。
標準類（Standard）——最普通的請求。推薦大部分的產能都應用於此類請求。交付團隊無需對請求的工作量進行估算，直接按照先進先出的順序進行處理。但對於超過兩週工作量的請求，建議先進行拆分。
無形類（Intangible）——主要針對一些用戶價值有限的附加功能。推薦安排在此類任務上的產能應該低於標準類。
這裏重點在固定交付日期類，交付期限可以作爲一個優先級排序的重要參考因子。
04
—
總結
客戶和業務總是“貪婪”的。業務部門、PO不肯做決定，對所有項目、需求採取“不拋棄、不放棄”的原則是各種交付問題的“萬惡之源”。業務部門組織關係複雜，利益不統一是其中一個重要原因。
重新定義業務產品，重塑權力關係是一個解決之道；通過計算每個需求的延遲成本，量化業務價值，是一個方法；在看板上建立服務等級，以目標交付期限作爲優先級參考，也是一條出路。
近期必讀：
關於作者
劉華（Kenneth）
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
敏於思 捷於行
堅持每週輸出一篇高質量文章
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言。