靈活需求管理（一）：從使用者想法到Product Backlog

如何從最初的客戶想法到持續維護的 Product Backlog， 大家的做法各有千秋。這裡分享我們的一些做法，見下圖：

第一步：獨立需求。這裡是從願景開始，根據角色、行為、資料對象拆分為獨立的需求

第二步：粗顆粒細化需求。這裡的目的是為了分析成本考量，但并不是類似 Use Case那樣的細化，隻需要包含 90％的使用者使用場景即可，有很多做法，其中一個是選擇 3個 examples，一個 happy path，另兩個是使用頻率較高的異常流程。這裡主要涉及的是商業規則

第三步：價值 /成本分析，這裡要分析價值、成本，在此基礎上再次拆分故事，最後完成優先級的排序

第四步： Velocity分析，目的是可以明白團隊完成的速度

第五步：制定釋出計劃，根據釋出目标、團隊完成的速度，選擇故事組，這裡要考量釋出目标會形成故事的耦合和依賴

第六步： PO組和開發團隊分步進行故事細化和故事開發，這裡要考量的是 Product Backlog的持續管理、大團隊 PO團隊和開發團隊的協作方式等。

故事分為兩種：一種是獲得客戶需求的故事，另一種是準備進入開發的故事。前者不需要細節，後者需要更多的細節。在開發團隊進行疊代的過程中， PO團隊同步在進行下兩個疊代的需求細化，即 PO團隊一定會比開發團隊領先兩個疊代。在 PO的疊代過程中，可以和開發團隊的核心人員在一起讨論，讨論的内容包括： PO提供更多的選擇，由開發團隊從技術的角度回報，然後限制 PO的選擇。這個過程最好在疊代開始之前完成。開發團隊在質疑需求的時候，可以從以下角度： Who（使用該需求的角色）是否有更多，他們對應的屬性？、做什麼、業務規則、業務資料、互動界面、品質标準等