對于產(chǎn)品新人來說，如果沒有好師傅帶，單槍匹馬很難形成好的產(chǎn)品思路。有時候和研發(fā)溝通，雙方都無法理解對方的想法，或者自己在寫需求的時候，不是東丟點就是西漏點，老是被開發(fā)追著走。今天我就簡單說一下個人的需求分解經(jīng)驗，希望能夠幫助到一些經(jīng)驗不夠豐富或者還沒有形成自己產(chǎn)品思路的產(chǎn)品經(jīng)理。

第一步：理清需求（use case）

我相信每個產(chǎn)品經(jīng)理都是上帝創(chuàng)造的奇葩，能想敢想，希望影響世界，甚至改變世界。作為一個產(chǎn)品狗，我深深滴體會到腦洞之大給自己帶來的困擾：必須要無時無刻攜帶手機，沒有手機的時候手邊沒有紙和筆直接讓我抓狂?。?/p>

好了不說廢話，繼續(xù)正題。產(chǎn)品經(jīng)理時時刻刻都有可能想出一些零零散散的點子，然而在沒有理清思路之前，很少有人知道我們想干嘛，所以第一步，我們需要理清需求。

理清需求就是把我們想做的事情，或者說我們認為用戶可能會需要的功能有條不紊的羅列出來，用文字OK，不過我更建議使用腦圖，不管是手繪也好，Xmind也好，MindManager也好，工具只是形式。

（很多人一上來就問Xmind和MindManager哪個好用？其實這個真的無所謂，只要能達到目的，用啥都一樣，如果真的還停留在糾結哪個好用這個問題上，那么我只能說，你還沒到考慮這個問題的時候，真正需要考慮這個問題的時候，你已經(jīng)知道哪個更適合自己了。）

用腦圖做什么呢，舉個例子：

假如現(xiàn)在不管哪個地方（備忘錄，紙上，某道，某象） 我記錄了如下東西，或者我的客戶突然告訴我，他們想做如下東西：

商品

（千萬不要直接拿去和研發(fā)談，不然我不敢保證你不會被打死）

現(xiàn)在需要做的，就是理清需求?。“褕鼍傲_列出來，像醬紫：

商品是用來做什么的呢？系統(tǒng)發(fā)布商品，用戶購買商品咯！

所以場景展開就應該是醬紫：

現(xiàn)在拿這個去和程序猿談，他們基本知道了這東西是干嘛的，但是他們還是會對這個東西的可行性保持高度懷疑，因為這樣說了之后，他們還是不知道應該做什么，這個時候，我們就需要進入下一步： 整理故事

第二步：整理故事（user story）

講故事需要有一個核心主題（主線），現(xiàn)在我們的主線就是商品。

講故事怎么講？舉個栗子：

那天我打開手機，進入了“我的產(chǎn)品”APP，進入了商品列表，我看到了許多商品，我把商品添加至購物車，并選擇了進入購物車結算，我看到了每個商品的結算價和總價值，感覺這些東西值得購買，于是我點擊了確認下單，系統(tǒng)給我生成了訂單，把我?guī)У搅擞唵未_認頁，我點擊確認支付，系統(tǒng)又把我?guī)У搅酥Ц俄撁?，我輸入了正確的支付信息后，系統(tǒng)提示我我的訂單已經(jīng)完成了支付，并且我還看到了一條已經(jīng)支付的訂單記錄。

簡而言之，如下：

到這里，購買商品的這個故事就講完了，這個故事完整嗎？完整。這是一個清楚的故事嗎？不是。

講好故事就能做好產(chǎn)品，一個完整的故事包含時間地點人物，一個清楚的故事，在于細節(jié)。所以如果我們將上面這個故事加入更多的描述，這就會變成一個清楚的故事：

那天我打開手機，進入了“我的產(chǎn)品”APP，我看了首頁長什么樣，哪里有按鈕，我點擊了進入了商品列表，頁看到了許多商品，這些商品都是什么樣的，怎么展示的，我把商品添加至購物車，并選擇了進入購物車，我看到購物車里的商品長什么樣，我看到這些商品的總金額之后，覺得這個價格還不錯，于是點擊了確認下單，系統(tǒng)過了沒多久就把我?guī)У搅擞唵未_認頁，于是我點擊了確認支付，系統(tǒng)又把我?guī)У搅酥Ц俄撁?，我輸入了正確的支付信息后，系統(tǒng)告訴我我的訂單已經(jīng)完成了支付，并且我還在訂單列表里面看到了一條已經(jīng)支付的訂單記錄，我一眼就能看到我買了什么東西，每個東西是多少錢，最后我總共付了是多少錢。

于是我們的表格變成了這樣：

至于怎么樣講一個好故事？繪聲繪色地講是一種方式（視覺效果），切入人心地講是一種方式（用戶心理），抓著重點講（核心流程），當然還有很多其他的方式，如果講故事的人能夠靈活地把多種方式柔和在一起，又能夠?qū)⑺麄儼l(fā)揮得恰到好處，那講出來的故事一定會是一個好故事。

第三步：分解故事（functional requirement）

對于一部分產(chǎn)品經(jīng)理來說，第三步其實不是必須的，因為經(jīng)驗豐富的產(chǎn)品經(jīng)理知道，在第二步中，需求已經(jīng)表達得夠清楚了。對于另一部分產(chǎn)品經(jīng)理來說，可能由于公司制度的規(guī)定或者與研發(fā)、項目管理人員工作范圍沒有劃分得特別清楚，就不得不做功能需求描述，總之如果產(chǎn)品經(jīng)理本身入行不深或者對產(chǎn)品的架構不是特別清楚，我很建議接著往下看。

在第二步中，我們已經(jīng)清楚地講完了一個故事，分解之后我們發(fā)現(xiàn)里面涉及到的關鍵物其實就只有幾個：APP前端（首頁、商品列表、訂單列表）、支付等等。所以在產(chǎn)品架構上，為了保證這些東西都得以實現(xiàn)，必須要保證有一個APP前端系統(tǒng)，這個系統(tǒng)由首頁，商品列表，訂單列表組成，除此之外，還需要有一個系統(tǒng)支持支付，為了方便管理，后臺還需要將用戶的訂單記錄保存或者展示。于是功能需求可能就是這樣：

然后故事分解完了，功能需求列表也搞完了。

以上是個人在從業(yè)期間內(nèi)學習并總結出的一套比較完整的產(chǎn)品思路，希望能夠幫助到各位還沒形成自己的產(chǎn)品思路又很苦惱迷茫的同仁！

#專欄作家#

康小胖，人人都是產(chǎn)品經(jīng)理專欄作家，產(chǎn)品經(jīng)理。專注專注O2O電子商務，堅決擁護用講故事的思維做產(chǎn)品，關注電子商務及移動互聯(lián)網(wǎng)，愛好圓珠筆涂鴉。

本文系作者獨家授權發(fā)布，未經(jīng)本站許可，不得轉(zhuǎn)載。