產品經理是如何去做版本迭代規劃的

來自專欄 從繁去簡

在產品的整個生命周期中，一定會遇到各種各樣的需求蜂擁而至，包括部門內部由於運營需要而提出的需求，領導心血來潮提出的需求，也有通過用戶投訴或反饋得來的需求，以及通過你個人對自身產品和競品的體驗以及產品的數據分析得來的需求。

同時你還得負責項目的跟進，新版本的規劃等等，在這個過程中你既要面對項目研發過程中的諸多問題，又時時刻刻面臨需求的不斷轟炸，這時候我們就會感覺到事務非常的多且雜亂。

所以，理清楚產品的整個規劃的流程就非常重要，這套流程能夠幫助自己理清思緒，讓你知道你現階段應該做什麼，接下來要做些什麼，這樣才能讓自己的工作非常有條理，也會讓產品的迭代更有節奏。

這是我總結的產品規劃的流程圖

需求管理

需求管理是做產品的人最首要也是最核心的任務，一款產品遇到的所有的需求最終都將彙集到我們產品人這邊過來，如果沒有及時做好需求的記錄和把控，就很容易造成需求的遺漏，重複記錄等，最後講導致產品規劃的混亂。

產品需求的產生主要有以下四種方式

1.產品研究

產品人每天至少需要對自己的產品以及競品反覆體驗在30分鐘以上，並記下體驗過程中得出來的需求點。

2.用戶反饋

每天定期查看產品的用戶反饋後台，自建渠道包括qq群，貼吧，社交媒體是否有用戶投訴反饋，清楚問題之後記下需求點，若是屬於bug或者急需解決的需求，立刻反映給開發解決，若是屬於不緊急的需求，則列入版本迭代規劃中。

3.用戶訪談

如果所在公司有資源，可以定期召集目標用戶群體進行訪談，如果沒有，也可以召集公司或者部門同事進行訪談，詢問他們需求點在哪裡，記錄下來。

4.數據分析

產品人需要每天或者至少一周對產品進行全面的數據分析，輸出數據日報或者數據周報，總結產品遇到的問題，得出需求點，記錄下來。

通過每天的需求收集，會生成以下的需求管理表

產品版本迭代規劃

每個特定的時間都需要對產品的現狀進行一番梳理和總結，理清楚產品上線後的效果是怎麼樣的，接下來的方嚮應該怎麼走。

做產品一定不能盲目地去加各種各樣的需求，或者毫無目的地去做版本迭代。每個版本的需求一定都是基於產品目前的現狀，市場的情況，最後基於產品發展的目的而去做的。、

目前我給自己定了兩個時間點去做產品的版本迭代規劃

第一個時間點：每個月的月底

在每個月的月底都需要對產品進行總結，發現產品的問題，規劃產品未來的發展。

第二個時間點：上一版本開發結束前

為了保證產品開發的節奏，需要在上一個版本開發結束後，馬上可以與技術對接新版本的需求和原型，所以在上一版本開發結束前至少一周，就必須要對產品進行總結，作出接下來的版本需求規劃，這樣才可以保證新版本需求的輸出，且留有一定的時間完成產品原型的設計。

產品規劃包括以下兩點內容

1.月度數據分析

先對本月產品的數據情況進行分析總結，得出問題點，輸出數據月報

2.需求匯總分析

在上文已經提到，我們每天都通過四種方式去採集各種各樣的需求，現在就是運用它們的時候了。

我們就需要把之前收集到的所有的需求點以及數據月報得出來的需求點進行打包，結合數據月報得出來的結論進行綜合分析，然後思考接下來半年的版本迭代規劃。

例如我們接下來半年需要分為幾個版本去迭代，每個版本分別要花多少時間開發，以及每個版本應該做哪些需求。

當然，有一些需求是無法確定什麼時候做的或者是半年以後才有可能去做的，那麼就把這些需求列入到「待定版本需求」中去。

做完產品版本規劃之後，我們就已經把之前收集到的所有需求都封裝到上面那幾個表格中去了。

接下來我們依然需要每天進行需求的收集，但是收集到的需求不能馬上添加到這幾個表格中，而是仍然需要等下一個時間點來了之後，再次重複上文所說的產品版本迭代規劃之後，再將收集到的需求添加到表格中去。

原型設計

半年的版本迭代規劃做完後，對接下來新版本要做什麼需求就非常清晰了，所以接下來就需要將新版本規劃好的需求進行落地了。這一點就不需要我多說了，原型階段應該是最簡單的，每一個入門級的產品經理必經的階段。這個時候的原型不需要做得很細，只要能夠理清需求的邏輯就可以了，因為原型主要是用來和技術對接的，把需求講清楚就可以了，更細節的產品邏輯需要通過完整的需求文檔來描述。

技術對接

完成新版本的原型設計之後，此時上一版本的需求技術估計也差不多開發完了，那麼接下來就是召開技術的對接會議，當然，撕逼是免不了的啦，你之前規劃好的版本迭代計劃一定會因為各種技術實現原因而大動刀子。

經過技術對接會議之後，我們需要將產品的需求點以及需求原型通過郵件發送給技術，讓技術評估需求的問題點以及實現難度。評估結果出來之後，產品部門內部需要進一步地討論，此時我們要做的就是去調整版本規劃表的需求劃分，例如有些需求這個版本不能實現的，就下移到下一個版本，有些需求壓根不能實現的，就直接刪除，有些需求實現難度太大的，就可以直接放到待定版本需求裡面去。

需求文檔

經過技術的評估，產品部門內部討論之後，新版本的需求和原型基本就定下來了，此時並不能馬上就把需求和原型遞交給技術就完事了，因為原型畢竟是通過原型軟體畫出來的，不是通過文檔寫的，很多產品的細節邏輯無法很清晰地通過大量的文字寫出來，這樣會導致技術需求理解不清楚，這樣後面就會導致各種各樣的問題，不僅如此，在產品開發的過程中一定會遇到各種需求變更的情況，每一次對需求的修改都需要做一次記錄，這樣方便項目組查看，也有利於後續對需求變更記錄的追蹤。所以，總體來說，詳細的產品需求文檔是必不可少的。

項目跟進

項目跟進之前，產品人需要和技術去溝通需求實現的時間節點，例如前端的哪些需求在哪個時間點能完成，後端的哪些需求在哪個時間點能完成，將溝通後的結果輸出成項目里程碑，產品人要做的就是盯著技術是否按照項目里程碑上面的時間節點完成需求的開發，如果不行，該趕就得趕，該撕逼還得撕逼，隨時準備為項目順利上線犧牲。