前幾天有人問我：“你做產(chǎn)品有沒有什么方法論？” 當時我愣了幾秒鐘，意識到其實我是有方法論的，但是從沒有認真總結(jié)過。也就是說：對于怎樣做產(chǎn)品這件事，我并沒有形成一套適用于自己（也可能給他人有借鑒意義的）的思維方式。既然如此，那現(xiàn)在我應(yīng)該總結(jié)一下echo的產(chǎn)品方法論。

方法論一：產(chǎn)品滿足的本質(zhì)需求和商業(yè)目的起碼在當下，應(yīng)該明晰。

首先，為何會有一個產(chǎn)品被創(chuàng)造出來？其背后必然是有一個或多個需求，凡是未看到需求而盲目生產(chǎn)出來的產(chǎn)品都是耍流氓。因此，做產(chǎn)品之前不做需求分析顯然是不可行的。然而，無論在任何以營利為目的的商業(yè)實體中做產(chǎn)品，該產(chǎn)品總應(yīng)該實現(xiàn)該實體的商業(yè)目標，或是賺取利潤，或是提高流量，沒有任何商業(yè)目的的產(chǎn)品，也是無法獲得生存下去的理由的。

由于我所在的互聯(lián)網(wǎng)金融行業(yè)在過去的幾年里似乎比較熱門，常常會聽到有人說：“哎，我們家也想做個互聯(lián)網(wǎng)金融平臺，你看怎么做一下比較好？我們有這個資源那個資源。”那我就想問一句了：“做互聯(lián)網(wǎng)金融為了達到什么樣的商業(yè)目的呢？你想拉流量？放貸賺錢？賣理財產(chǎn)品賺錢？”通常問到這以后，對方就陷入沉吟，或者賴皮的說：“你幫我想一個吧！”

事實上作為產(chǎn)品經(jīng)理，給企業(yè)規(guī)劃產(chǎn)品目標確為本職工作，但對于沒有具體需求卻已預(yù)先定好解決需求的工具的老板，我只能說一句：“臣妾做不到啊~”要么我需要知道有什么需求，要么我需要知道有什么商業(yè)目的；對于需求不明目的不明，卻規(guī)定好你必須用互聯(lián)網(wǎng)金融這個工具的商業(yè)機構(gòu)，我想說的是，老喬下凡也幫不了你什么。（嘿嘿嘿，事實上這種公司還真不少?。?/p>

方法論二：產(chǎn)品的規(guī)劃應(yīng)該由用例發(fā)起，用例驗證。

鑒定好了產(chǎn)品的需求或商業(yè)目的之后（起碼是當前已經(jīng)確定），應(yīng)該進入產(chǎn)品的業(yè)務(wù)架構(gòu)階段。

現(xiàn)在到處在講究MVP，一夜之間產(chǎn)品做得挫都可以堂而皇之得稱之為為了敏捷開發(fā)，快速上線。好一塊遮羞布！我在產(chǎn)品業(yè)務(wù)架構(gòu)這一步的主要執(zhí)行方式是實用主義至上，先用例后功能。

技術(shù)出身的產(chǎn)品經(jīng)理一定知道用例是什么，但其他背景的產(chǎn)品經(jīng)理對于用例可能比較陌生，但可以這里把用例理解為“用戶故事”，即做這個業(yè)務(wù)的所有人，在這個業(yè)務(wù)中的行為是什么。每個用例都有一個明確的目的。例如投資者這個業(yè)務(wù)主角，他有一個關(guān)鍵用例稱為”投資“。“投資”用例中，可能包括投資者的實名認證和綁卡；而“綁卡”則一般不會稱為一個單獨的用例，因為，一般來說投資者不可能單純?yōu)榱私壙ǘ壙ǎ覜]有下一步目的的。我們的目標，是為了找出所有系統(tǒng)相關(guān)人員在這個產(chǎn)品的所有目的。這個“目的”，其實正對應(yīng)著第一步的“需求”。

從零到一規(guī)劃一個產(chǎn)品的工作通常是這樣：你需要憑空想象出一件物體，并假設(shè)這個物體已經(jīng)制造出來了。這時，你需要向他人描述這個物體，描述它是做什么用的；描述它的形狀、質(zhì)地、硬度、大小，它是不是有什么氣味，搖晃一下聽會發(fā)出什么聲音；或者使使勁韌性如何。描述完畢后，會有人（開發(fā)兄弟們）把這件物體制造出來。也許你覺得在腦中已經(jīng)想到了這件物體的每一個零件，在制造的過程中還是會有各種各樣的問題。按照我一個老朋友的話說：“尼瑪做實現(xiàn)的不是你啊！”如果用例不走通，功能當然也會設(shè)計的相當殘缺。如果不幸已經(jīng)進入了研發(fā)流程，那么當程序猿拿著走不通的流程來問你的時候，如果你是男生恭喜你，你還能下跪求原諒；如果你是個妹子，你說你該怎樣吧。

說到這里有人會疑惑，既然產(chǎn)品的業(yè)務(wù)架構(gòu)如此繁瑣，那MVP到底還存在嗎？我想說，一定還是存在的。一個產(chǎn)品的功能可以簡單，比如只有一個功能，滿足一類使用者的一類業(yè)務(wù)目的，但這個業(yè)務(wù)目的的滿足，一定是完善的。打個比方，如果你有兩枚一元硬幣，要你交出一半，你是給出一個硬幣，還是用刀把兩枚硬幣都切成半圓，然后給出兩個半圓？MVP需要你給出一個硬幣，而不是兩個半圓。即“可使用的最小產(chǎn)品”而不是'殘缺的大產(chǎn)品“。很多時候我們MVP給不出來的原因并不是我們規(guī)劃的太細了，而是，我們把產(chǎn)品規(guī)劃的太大了。

產(chǎn)品的業(yè)務(wù)架構(gòu)做的差不多了，這時候各種文檔也應(yīng)該出齊了。我并不覺得文檔出的越齊就代表產(chǎn)品做得越好或做的不齊就沒法開發(fā)。文檔齊不齊和研發(fā)測試團隊的默契程度、專業(yè)背景都有關(guān)聯(lián)。但是為保證產(chǎn)品能夠順利迭代，以及人員變動不會給產(chǎn)品帶來影響，最好保持較完善的需求文檔或主用例文檔。

有的團隊在產(chǎn)品規(guī)劃出來之后還面臨著拆分任務(wù)。即拆分功能點給不同的產(chǎn)品經(jīng)理進行進一步完善的工作。在這點上我認為功能點任務(wù)的拆分，在產(chǎn)品這方面應(yīng)依據(jù)技術(shù)任務(wù)的拆分來做。例如某個功能點，是研發(fā)小組A來實現(xiàn)，則應(yīng)匹配產(chǎn)品經(jīng)理A，功能點B由研發(fā)小組B來實現(xiàn)，則應(yīng)對應(yīng)產(chǎn)品經(jīng)理B。這樣可以有效避免產(chǎn)品經(jīng)理的跨研發(fā)小組溝通，以及技術(shù)部門之間需求協(xié)調(diào)不暢的問題。產(chǎn)品功能的協(xié)調(diào)問題，在產(chǎn)品組內(nèi)解決，功能模塊間的通信與耦合，在技術(shù)組內(nèi)解決，涇渭分明。

方法論三： 沒有一勞永逸的產(chǎn)品架構(gòu)，早期產(chǎn)品可能隨時被推翻。因此應(yīng)盡量簡單。

按照三段式理論，現(xiàn)在應(yīng)該是方法論的最后一點，研發(fā)中的需求變更和產(chǎn)品迭代問題的處理方法。

在互聯(lián)網(wǎng)行業(yè)中我們都應(yīng)該習(xí)慣了“只有變是永遠不變的”。初入行時，還常常為變來變?nèi)サ男枨蠛徒?jīng)常白做的功能感到惋惜，而現(xiàn)在已經(jīng)能泰然面對了。

當我們在上述的第二步業(yè)務(wù)架構(gòu)時，一般就應(yīng)該對產(chǎn)品的生命周期及未來一兩個版本的迭代有基本的預(yù)估，這樣在第三步時，可以有效避免產(chǎn)品持續(xù)迭代中的荒腔走板。如果產(chǎn)品在老板（或“未知力量”）的影響下，發(fā)生了重大變更，那事實上可以認為是研發(fā)一個新產(chǎn)品，而不是在當前產(chǎn)品上的變更了。

鑒于此，MVP其實是非常重要的，這意味著我們必須有一個非常簡易且擴展性強的業(yè)務(wù)架構(gòu)，而設(shè)計出這種架構(gòu)的前提又是對業(yè)務(wù)的高度熟悉。因此，在互聯(lián)網(wǎng)行業(yè)，尤其是互聯(lián)網(wǎng)金融行業(yè)中，如果要適應(yīng)快速的業(yè)務(wù)變動，對于產(chǎn)品經(jīng)理的要求，應(yīng)該是對業(yè)務(wù)理解到能抽象的程度，所以，我們時時刻刻都應(yīng)該檢視自己，金融到底學(xué)的怎么樣？對金融的本質(zhì)有多少的理解，而不僅僅拘泥在”這個按鈕應(yīng)該放這還是放那？“這種UI層面的問題上。

產(chǎn)品經(jīng)理是互聯(lián)網(wǎng)職業(yè)中入門門檻最低的一個職位，但是，在互聯(lián)網(wǎng)金融領(lǐng)域，它的入門門檻就不是那么低了。所以，當你做來做去還是覺得自己業(yè)務(wù)能力沒有什么提升的時候，我覺得問題主要出現(xiàn)在：你把自己的職能范圍縮得太小了。而為什么縮小，可能是你的潛意識把你的學(xué)習(xí)能力圈在舒適區(qū)了，你說呢？

?

本文由 @echo回聲?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。