實戰(zhàn)：產(chǎn)品經(jīng)理如何做好需求版本控制

做了一陣子產(chǎn)品經(jīng)理之后，一提到任何東西，任何需求，立馬用思維導圖給你整出一大篇的功能列表，多的電腦屏幕都顯示不下了；接著搞出一個看似精美比較保真的原型圖，幾十上百頁的PRD文檔，然后扔給RD，就按這個開發(fā)吧，這個就是我們產(chǎn)品的1.0版本(RD同學估計此時心中一萬只草泥馬奔過。。。)。上面講到的兩個例子，是我在近年來工作中遇到大多數(shù)產(chǎn)品經(jīng)理做事的方法。這里講的產(chǎn)品經(jīng)理是指哪些入門1-3年左右的初級PM，大牛們看到這里就可以飄過了。為什么標題要寫“產(chǎn)品經(jīng)理如何做好需求版本控制”呢？就拿剛才的例子來說：前一個產(chǎn)品經(jīng)理只重視了需求的實現(xiàn)，而忽視了去審視需求，調(diào)研需求，需求規(guī)劃等等環(huán)節(jié)；后一個產(chǎn)品經(jīng)理想到了需求與需求之間的關(guān)聯(lián)性、擴展性，但是忽略了需求的無限性，這其中都忽視了如何去控制需求。什么是需求的無限性呢？那就是任何一個小需求，如果你順著邊兒去想就能夠發(fā)散出幾十甚至幾百個跟這個需求相關(guān)的小點。而如果產(chǎn)品經(jīng)理不去做相關(guān)的需求調(diào)研，了解需求五層結(jié)構(gòu)中最底層的核心目標是什么，嘩啦嘩啦全都給一次性實現(xiàn)出來，那么注定這個事情對團隊、甚至對公司都會是一個大坑。因為投入了大量的團隊資源去做了非常多無用、無意義的功能，卻沒有對主線的核心需求產(chǎn)生價值。那么，產(chǎn)品經(jīng)理應該如何做好需求控制呢？以我個人的經(jīng)驗，我認為應該從以下幾個方面著手：首先：一定要明白產(chǎn)品要解決的核心問題。作為一個產(chǎn)品經(jīng)理，應該是自上而下的去看待需求問題。從公司做這個產(chǎn)品或者這個功能要達到什么目的，解決哪方面的用戶需求，要實現(xiàn)什么樣的商業(yè)目的等方面著手。弄清楚我們這次到底是要干什么的。如果這些問題沒搞懂做出來的東西要么會被老板罵，要么會被同事罵；自己當老板的產(chǎn)品經(jīng)理估計會肉痛白花出去的錢，打擊創(chuàng)業(yè)的自信心。其次：構(gòu)思需求的完整解決方案，建立需求列表。當你了解清楚需求背后的真實目的的時候，實現(xiàn)這個需求可能有很多種方法。有的需要開發(fā)進行實現(xiàn)，有的不需要開發(fā)進行實現(xiàn)，這里講的是需要開發(fā)來實現(xiàn)的需求。產(chǎn)品經(jīng)理應該和團隊以及相關(guān)部門溝通，想出一套完整的解決方案。這個解決方案可能會有很多相關(guān)的功能點、功能細項。沒關(guān)系，這個時候能想的都想出來，其他人其他部門提出的建議也都包含進來，形成一個需求表(FeatureList)，留待整個團隊一起來討論。根據(jù)公司情況量體裁衣，做好需求版本規(guī)劃。經(jīng)過前2個步驟，可能你的需求表上密密麻麻的列出了幾十上百，幾百上千的功能點和要解決的問題。這個時候不要著急，根據(jù)團隊的情況，公司的實力、公司給予的資源，來對產(chǎn)品的版本進行劃分。也就是說1.0做什么、1.1做什么、1.2做什么，切忌不要想著一股老的全給做了。有些PM看著競品或是對手公司做了很多領(lǐng)先于自己功能，一下子就急了，恨不得下一個版本當中全部趕上。實際上這樣做的結(jié)果反而適得其反，一個是弄的開發(fā)團隊不堪重負，做出來的東西沒質(zhì)量，不穩(wěn)定，bug一大堆；另一個是一上線之后用戶罵聲一片，打擊整個團隊的士氣，影響公司對此項目前途的看法。另外，就算是產(chǎn)品1.0如果功能較多也可以分成幾個小版本進行開發(fā)，注意把握好開發(fā)進度以及節(jié)奏。曾經(jīng)看到過一個故事用在此處可能有一定的啟發(fā)意義：這個故事講的是有一個人連續(xù)吃了7個包子吃飽了，于是乎大家紛紛去研究這第7個包子到底如何神奇，用的什么材料什么秘方啊。而忽視了前面6個包子的重要性。反映到互聯(lián)網(wǎng)產(chǎn)品當中，那就是任何偉大或者好的產(chǎn)品都是一點一點積累起來的，沒有捷徑可走。一定要重視好版本迭代的重要性，真正做到跟用戶一起小步快跑。一般而言，做產(chǎn)品版本規(guī)劃應該是根據(jù)團隊情況分配的工作量適中，一個版本解決1-3個需求即可，保證整個團隊能夠在一周之內(nèi)迭代出一個版本。這樣的好處就是一月下來，一年下來，整個團隊效率處于良性運轉(zhuǎn)狀態(tài)，并且產(chǎn)品體檢相比較一月或者一年前也有較大的改觀，用戶也能感受到產(chǎn)品在慢慢的成長，增加對產(chǎn)品的信任感。上線之后的版本勿隨意修改很多時候在某個版本上線之后，還是會出現(xiàn)一些問題以及用戶的反饋。這個時候我建議不要在當前的版本中去修復這些問題(重大bug除外)。因為如果這樣做了，肯定是會影響產(chǎn)品的迭代周期的。所以我建議把這些問題或者建議又放入需求列表中，下一個版本中再根據(jù)具體的情況決定改進哪些，其余的留著后面去改進，不要想著一次把所有的事情做完。充分運用好運營或者市場團隊這2個團隊往往處于一線，與用戶親密接觸。他們有時候反應上來的問題非常有用，非常接地氣，產(chǎn)品經(jīng)理一定要重視好(如果有可能，我覺得其實產(chǎn)品以及運營部門可以合為一個部門，這個根據(jù)每個公司或者產(chǎn)品的情況略有不同吧)。因為這些需求可能隱藏著用戶最真實的使用情況，對產(chǎn)品最真實的看法。但是也不要完全信任這2個部門提出的需求，原因太多了，因為有時候用戶需求不等于產(chǎn)品需求，有時候某個需求可能包含他們對kpi的訴求...總之需要