剛入行的產品經理，往往一提到任何功能，任何需求，立馬啪啪的打開電腦，看我給你把原型畫出來了，厲害吧？

做了一陣子產品經理之后，一提到任何東西，任何需求，立馬用思維導圖給你整出一大篇的功能列表，多的電腦屏幕都顯示不下了；接著搞出一個看似精美比較保真的原型圖，幾十上百頁的PRD文檔，然后扔給RD，就按這個開發(fā)吧，這個就是我們產品的1.0版本（RD同學估計此時心中一萬只羊駝奔過。。。）。

上面講到的兩個例子，是我在近年來工作中遇到大多數產品經理做事的方法。

這里講的產品經理是指哪些入門1-3年左右的初級PM，大牛們看到這里就可以飄過了。

為什么標題要寫“產品經理如何做好需求版本控制”呢？

就拿剛才的例子來說：前一個產品經理只重視了需求的實現，而忽視了去審視需求，調研需求，需求規(guī)劃等等環(huán)節(jié)；后一個產品經理想到了需求與需求之間的關聯性、擴展性，但是忽略了需求的無限性，這其中都忽視了如何去控制需求。

什么是需求的無限性呢？那就是任何一個小需求，如果你順著邊兒去想就能夠發(fā)散出幾十甚至幾百個跟這個需求相關的小點。而如果產品經理不去做相關的需求調研，了解需求五層結構中最底層的核心目標是什么，嘩啦嘩啦全都給一次性實現出來，那么注定這個事情對團隊、甚至對公司都會是一個大坑。因為投入了大量的團隊資源去做了非常多無用、無意義的功能，卻沒有對主線的核心需求產生價值。

那么，產品經理應該如何做好需求控制呢？以我個人的經驗，我認為應該從以下幾個方面著手：

首先：一定要明白產品要解決的核心問題。

作為一個產品經理，應該是自上而下的去看待需求問題。從公司做這個產品或者這個功能要達到什么目的，解決哪方面的用戶需求，要實現什么樣的商業(yè)目的等方面著手。弄清楚我們這次到底是要干什么的。如果這些問題沒搞懂做出來的東西要么會被老板罵，要么會被同事罵；自己當老板的產品經理估計會肉痛白花出去的錢，打擊創(chuàng)業(yè)的自信心。

其次：構思需求的完整解決方案，建立需求列表。

當你了解清楚需求背后的真實目的的時候，實現這個需求可能有很多種方法。有的需要開發(fā)進行實現，有的不需要開發(fā)進行實現，這里講的是需要開發(fā)來實現的需求。產品經理應該和團隊以及相關部門溝通，想出一套完整的解決方案。這個解決方案可能會有很多相關的功能點、功能細項。沒關系，這個時候能想的都想出來，其他人其他部門提出的建議也都包含進來，形成一個需求表（Feature List），留待整個團隊一起來討論。

根據公司情況量體裁衣，做好需求版本規(guī)劃。

經過前2個步驟，可能你的需求表上密密麻麻的列出了幾十上百，幾百上千的功能點和要解決的問題。這個時候不要著急，根據團隊的情況，公司的實力、公司給予的資源，來對產品的版本進行劃分。也就是說1.0做什么、1.1做什么、1.2做什么，切忌不要想著一股老的全給做了。

有些PM看著競品或是對手公司做了很多領先于自己功能，一下子就急了，恨不得下一個版本當中全部趕上。實際上這樣做的結果反而適得其反，一個是弄的開發(fā)團隊不堪重負，做出來的東西沒質量，不穩(wěn)定，bug一大堆；另一個是一上線之后用戶罵聲一片，打擊整個團隊的士氣，影響公司對此項目前途的看法。

另外，就算是產品1.0如果功能較多也可以分成幾個小版本進行開發(fā)，注意把握好開發(fā)進度以及節(jié)奏。

曾經看到過一個故事用在此處可能有一定的啟發(fā)意義：這個故事講的是有一個人連續(xù)吃了7個包子吃飽了，于是乎大家紛紛去研究這第7個包子到底如何神奇，用的什么材料什么秘方啊。而忽視了前面6個包子的重要性。反映到互聯網產品當中，那就是任何偉大或者好的產品都是一點一點積累起來的，沒有捷徑可走。一定要重視好版本迭代的重要性，真正做到跟用戶一起小步快跑。

一般而言，做產品版本規(guī)劃應該是根據團隊情況分配的工作量適中，一個版本解決1-3個需求即可，保證整個團隊能夠在一周之內迭代出一個版本。這樣的好處就是一月下來，一年下來，整個團隊效率處于良性運轉狀態(tài)，并且產品體檢相比較一月或者一年前也有較大的改觀，用戶也能感受到產品在慢慢的成長，增加對產品的信任感。

上線之后的版本勿隨意修改

很多時候在某個版本上線之后，還是會出現一些問題以及用戶的反饋。這個時候我建議不要在當前的版本中去修復這些問題（重大bug除外）。因為如果這樣做了，肯定是會影響產品的迭代周期的。所以我建議把這些問題或者建議又放入需求列表中，下一個版本中再根據具體的情況決定改進哪些，其余的留著后面去改進，不要想著一次把所有的事情做完。

充分運用好運營或者市場團隊

這2個團隊往往處于一線，與用戶親密接觸。他們有時候反應上來的問題非常有用，非常接地氣，產品經理一定要重視好（如果有可能，我覺得其實產品以及運營部門可以合為一個部門，這個根據每個公司或者產品的情況略有不同吧）。因為這些需求可能隱藏著用戶最真實的使用情況，對產品最真實的看法。但是也不要完全信任這2個部門提出的需求，原因太多了，因為有時候用戶需求不等于產品需求，有時候某個需求可能包含他們對kpi的訴求…總之需要自己根據數據情況，根據一切看似假象的線索去分析這些需求。

以上講的這些東西，看似簡單，卻是考量一個產品人功力重要的一環(huán)，也許只有在慢慢的實踐中才能得其中奧妙吧。

本文由 @jimie 原創(chuàng)投稿，并經人人都是產品經理編輯。未經許可，禁止轉載。