實現一份產品待辦列表的限制系列之一｜PO對應團隊還是特性？

前言

最近我碰巧翻到一篇十年前寫的舊文，叫“PO對應團隊還是特性？”；我發現它可以被連線到實現一份產品待辦列表的限制這一話題。那時的思考觸碰到了一些因素，但依然模糊。過去這些年我對該話題的思考有所改善，因此決定寫一個關於它的系列文章。同時我也決定把這篇舊文作為這個系列的第一篇。

專題目錄

01

PO對應團隊還是特性？

02

特性負責人和子領域產品負責人的經歷

03

來自PO在澄清上的限制

04

來自PO在優先順序排序上的限制

05

來自團隊在領域開發上的限制

PO對應團隊還是特性？

PO對產品成功負責；PO也是團隊工作的唯一入口。在一個單團隊的環境裡，PO一直跟那個團隊工作，所有事情都很清晰。

然而，在一個多團隊的環境裡，事情變得更復雜了。當團隊數量太多時，一個PO跟這個產品裡所有團隊工作變得困難。這導致有多個PO跟不同團隊工作。在產品層面仍然有一個PO，他建立了一個包含多個PO的PO團隊。一個PO通常跟超過一個團隊工作，但不會是所有團隊。因為一個大特性可能被多個團隊一起開發，就有兩種關聯PO和團隊的模式出現。

PO對應團隊

固定PO和團隊之間的對應關係。對每個PO來說，他一直跟那幾個團隊工作。自然他也會管理產品待辦列表中與他團隊的工作相關的部分。

PO對應特性

並不固定PO和團隊之間的對應關係，而是根據團隊工作的特性來改變。在這種模式裡，PO是對產品中的特性負責。哪些團隊工作在那些特性上，PO就跟哪些團隊工作。

我一直建議PO對應團隊，並感到PO對應特性有些不對勁。這篇文章試圖澄清為什麼，不僅為你，也為我自己。

PO對應特性的好處和問題

讓我們先來理解一下PO對應特性試圖獲得的好處。主要有兩個：

PO可以在產品的某個部分和一些特性上專業化。任何團隊能工作於任何部分的產品雖然理想，剛開始卻並不一定可行。這一點同樣適用於PO。PO對應特性使得他們可以在產品的某個部分上專業化；

整個特性都由一個PO管理，從而減少相關團隊的協調開銷。

PO對應特性的最明顯問題是，如果一個團隊同時需要工作於多個特性該怎麼辦？如果你允許多個PO對接同一個團隊的話，就又把諸如衝突的優先順序、部分分配之類的傳統問題給帶回來了。

但是PO對應特性也不一定就意味著多個PO對應一個團隊，還是可以做到在任何時候誰是團隊的PO都是清晰的。如果團隊工作於兩個特性，負責更重要特性（基於價值、大小等因素）的那個PO可以在相應迭代中作為團隊的PO。其他PO則需要跟團隊PO工作以讓他們的內容排進那些迭代中。那樣一來，當團隊工作於不同特性時會有PO的切換。雖然對團隊來說在任何時候只有一個PO，在交接階段兩個PO還是可以一起工作。

以上安排是否就沒問題了？我不認為如此。PO對應特性有兩個更深層的問題。

PO對應特性加強了對當前特性的焦點，而對流動和長期持續性有所損害。如果我們想要讓團隊在迭代中達到高效，我們需要在特性進入迭代前將它準備好。這要求逐步梳理待辦列表和未來的特性。如果我們想要讓版本更可預測，我們需要主動應對風險和不確定性。這要求提早投入來預研。如果我們想要持續交付高質量的產品版本，我們需要降低改動成本。這要求逐漸償還在遺留系統中的技術負債。然而，PO對應特性會更偏向於短期的專案思維。

PO對應特性打破了反饋迴路，而反饋對學習和持續改進至關重要。當PO對應特性時，PO不太可能和之前做特性的團隊一起從諸如不切實際的承諾、犧牲完成的定義、圍繞需求的無效協作等錯誤中學習。

簡而言之，PO對應特性經常導致失去短期與長期的平衡，而對於PO這一角色而言，只是最大化一個迭代或者一個特性的投資回報並不夠，而是需要持續地在產品的生命週期裡都做到。

PO既對應團隊又對應特性

我們如何能把PO對應特性的那些好處實現到PO對應團隊的模式中呢？形成產品領域是關鍵。

一方面，領域需要足夠大以容納大多數特性。即使那些特性的工作會散佈到多個團隊，整個特性還是能夠在一個領域內管理，從而讓協調變得容易。另一方面，足夠大的領域依然小於整體產品，因此PO還是可能在領域內專業化。

關於一個PO能夠工作的團隊數量，有人說不超過2個，也有人說可以到10個，我認為的有效點是5個左右。一個PO對應5個團隊既能有一定的專業化又能讓特性協調簡便。

寫於2011。4

作者：Yi Lv呂毅

國內首位CST、LeSS（大規模框架）認證師、敏捷教練及顧問。他的工作焦點一直在大規模產品開發上，尤其是幫助組織從LeSS中獲益或是直接匯入LeSS。其中的一段經歷被作為LeSS案例記錄了下來：華為 – 沒有Scrum的LeSS（

https：//yihuode。io/articles/324）

他相信LeSS打開了通往產品開發領域中學習型組織的階梯。