產品版本規劃的幾大關鍵步驟

產品經理對於如何作版本迭代規劃，有時總會產生無力感，要麼是計劃難以肯定下來，要麼是制定好的計劃沒法執行下去，這個問題的緣由很複雜。在項目初期，咱們缺乏對產品的全局概念和總體把握，內部意見很難統一；再者，沒有一個完整的用戶體驗或者價值流導向，對於每一個迭代沒法合理定製出可交付產品增量。

以前咱們講過如何構建 產品路線圖，路線圖能夠給PO和團隊總體方向的指導，但更具體的內容，須要用戶故事地圖的方式，經過橫向的框架和縱向的任務，將一個產品完整的展現出來。而後，再經過故事點估算和優先級的排序，來肯定版本迭代計劃。

版本迭代實際上是一個路線圖，展現了將要實施哪些功能以及什麼時候完成這些功能的指望。一般遵守團隊本身的節奏，有的是一個Sprint 一個Release，有的將多個Sprint歸爲一個Release中，以下圖所示。還有的在每一個功能完成後當即發佈，這也一般被稱爲持續部署或持續交付。

​ ​

根據產品開發的策略，它能夠由功能驅動，目標是一旦開發出預期的功能模塊就發佈; 或者由日期驅動，過了預約的檢查點就發佈。

具體如何作呢？咱們能夠分這個步驟來完成。

1. 建立用戶故事地圖

和客戶一塊兒，釐清產品的用戶角色，並儘量多地寫出用戶的行爲，以及每一個用戶行爲下須要作的事情，而後按照用戶行爲從左到右講故事。當你們把本身所能想到的故事地圖都放上去以後，再合併增減故事，最後會造成一個二維故事地圖。

​ ​

2. 構建產品發佈路線圖

整個故事地圖會包含不少故事點，但在必定時間完成全部功能是不太可能的，團隊要綜合考慮商業價值、市場現狀、實現難度等方面因素，肯定接下來幾個發佈的內容，以及每一個發佈預期能達成的目標。

​ ​

3. 快速估算

用戶故事建立好後，咱們能夠對地圖中的全部任務進行快速估算，以便於可以知道咱們整個Release要發佈產品的所需大概工做量。不一樣於Sprint中對故事的估算，這裏更粗略更快速，能夠用故事點或者T恤size（S, M, L , XL）來制訂咱們的估算標準。

4. 制定Release計劃

前面工做完成後，咱們對於總體產品和開發時間會有一個大概的估計，那麼就能夠設計Release計劃了。咱們能夠按照咱們的估算，設計一個Release須要發佈哪些特性，而後包括幾個Sprints，下圖爲Release計劃示例。

​​

再將故事按照優先級和價值進行排序放回到每一個Sprint裏，能夠利用一些迭代規劃的在線工具，以下圖把右側產品Backlog的內容，自由拖動到左側的Sprint中。

​ ​

5. 產品發佈日曆

在計劃會議以後，最終肯定詳細信息，進行任何最後調整，而後與全部利益相關者共享產品發佈日曆。

​ ​

本文做者：Kaya

首發於Worktile官方博客，如轉載請註明出處。

原文連接： 如何作產品的版本迭代規劃？