目的

在之前的《Product Servant》一篇中曾經提到，作為產品經理或產品總監，都應該有自己的方式來根據市場和使用者情況來管理產品的走向，其中前者更傾向於具體的功能，而後者則更傾向於市場方向的競爭力；前者要求細節，後者要求高度。那麼，這兩個人到底誰是傳統意義上的Product Owner呢？

另一個常常被問到的問題是：“我們只有一個產品經理，而有20多個開發人員，這一個產品經理能忙得過來嗎？”

再有一個問題則是：“PO只在迭代開發會上溝通需求，還是在迭代開發期間仍然與團隊在一起？”

還有一個問題則是：“PO在最後的評審會上才看到結果，萬一發現問題需要改正，是否會為時過晚？”

又有一個問題則是：“可以讓客戶代表參加計劃、評審活動嗎？”

……

這些諸多問題，都指向一個答案：“一個PO很難完成其所應履行的各種職責，我們需要一個PO團隊。”

結構

PO團隊整體上是一個上下分級、內外疏密的團隊。

所謂上下分級，就是說一定要有產品總監層面的人員參加，以便把控整個產品的走向。這種把控的結果，是能按照商業步調形成大的版本計劃。

若失去這種大的方向，就很難真正“按優先順序排序”，因為真正的優先順序，來自於對盈利性產品的持續盈利能力、新產品的價值判斷發展方向等商業目標的追求，而不是技術上的優先順序。

在總監層面的工作完成後，產品經理會在具體版本、計劃、需求開發、評審、釋出等工作中將商業目標落實到開發工作中。從時間上，保證產品進度符合商業步調，從空間上，保證產品需求符合目標客戶群。

在大型的PO團隊如遊戲的策劃團隊（常常佔總人數的1/4）中，還會有三層結構：主策劃（產品總監）-策劃組長（產品經理）-策劃人員（產品助理），負責一小部分故事的編寫與跟進（跟進活動見下文）。

所謂內外疏密，則是在開發過程中由客戶、市場、銷售、產品、開發、售後等綜合角度審視產品。

比如遊戲公司常常邀請運營部門或發行商參與產品的管理，消費電子則會邀請分銷商、售後部門等，目的是提供第一手的反饋。

產品研發團隊的代表也常常參加PO團隊，來幫助PO團隊把握產品演進的技術路線。研發團隊代表還會從整個商業路線圖中勾勒出技術路線圖，來判斷是否以及在何種程度上“為未來做準備”。（在《智慧敏捷系列》中曾經提到，準備太多會浪費；準備太少會返工。）

產品經理在整個過程中扮演穿針引線的作用，即作為各方的Servant，向上提供決策依據，向下提供目標指引，向外提供產品支援，向內提供使用者需求。

活動

除了常見的需求優先順序排序、計劃會講解故事、評審會評審需求之外，整個PO團隊還有很多工作，下面按照工作的大小、層次列舉一下。

• 產品初期
  • 產品總監：設定商業目標和路線圖
• 日常工作
  • 產品經理：制定釋出計劃，形成和描述故事
  • 研發團隊的代表：制定技術路線圖
• 迭代前
  • 產品經理：優先順序排序，選擇下個迭代的待開發列表（Willing List），選擇故事群，制定迭代目標
  • 產品經理/研發團隊的代表：預估故事，協助拆分故事
• 迭代中
  • 產品經理/產品助理：負責細化需求，跟進需求的完成情況（漸進式評審，見下）
• 評審會
  • 產品總監/產品經理：評審需求完成情況，提出意見，重新排序

漸進式評審

所謂漸進式評審，又叫跟進人制度，是為了防止迭代最後一天的評審會上發現了問題，由於第二天就想釋出了所以來不及改正，因而將評審改為每一個故事完成，都進行一次評審，若需要改正則提前進行。

一般需要以下實踐配合：

1. PO團隊人數較多，且有層次，能為每個故事設定跟進人，負責解釋和驗收這個故事。

2. 配合MoSCoW方法，按優先順序逐個完成故事，若M、S型別的故事評審後需要改進，則可能犧牲後面的W型別工作。

3. 中期評審會。有些團隊在為期30天的迭代的第20天左右，會開一個預評審會，以完成2中提到的工作。

點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》