本文是一個系列文的上篇，分成上下文是為了方便大家的閱讀和理解，本篇是寫的關于我自己的產品方法論，也是在做這個需求的時候自己定義并遵守的一個規(guī)則和指導思想，內容偏理論，可能太干。

此需求也是我近期的工作內容之一，所以具有實戰(zhàn)性也很新鮮，希望會對一些2B的產品會有一些啟示，也希望有供應鏈及跨境電商行業(yè)的產品大佬一同交流學習。

很早之前我就想寫兩個內容，一個是自己的產品方法論，一個是關于WMS的背后的故事。

產品方法論是因為我每次看別人的文章的時候都覺得頭頭是道，有條不紊，而自己做需求，做一些產品相關的工作的時候總是今天用“華山派的功夫”，明天用“武當的功夫”，后天“可能就完全不會功夫了”……所以我想自己寫點東西給自己一些指導，一些約束。

WMS的背后的故事是因為我目前主要負責的就是這個模塊，我也對這個領域是最熟悉的，當然雖然說最熟悉，但是我依然覺得這一塊我做得很一般，還遠沒有踏入行業(yè)的門檻。

寫這些是為了總結自己的一些產品心得，同樣的網絡上這方面的資料和信息太匱乏了，如果我的東西能給別人一點幫助，那也是一個莫大的榮幸。

結合上述幾個理由，我決定說干就干，既寫下我的產品方法論，也寫下我對WMS這一塊的心得感悟。

我的產品方法論

產品方法論是指我在日常完成一個需求設計的一個過程中所使用的一些步驟和方法，其實這個方法論是我現寫的，這也是我在前面提到自己沒有嚴格的約束、規(guī)范去指導自己做這些東西的原因之一，因為沒有方法論，所以今天想起來了就會用“華山派的功夫”，要是沒想起來可能就會用“武當的功夫”，甚至為了偷懶直接就沒有什么功夫。

所以會導致每次做不同的需求的時候，會有千奇百怪的差異，有時候會心血來潮寫Mindjet分析，有時候會寫文檔記錄，有時候會用Excel表進行跟進和梳理，有時候啥也腦子里過一遍就定了方案……

為避免上述問題的持續(xù)發(fā)生，我決定去制定這些方法論，同時也嚴格去執(zhí)行、落實，其中對這些方法論進行必要的迭代升級。下圖就是我制定的屬于我自己的「產品方法論」，主要是在適用在“需求分析及設計”環(huán)節(jié)。

第一步：背景

背景這個東西一般我在寫需求文檔或者寫TAPD的時候都會寫上去，因為很多時候我們都會忘記為什么要做這個功能，或者時間一久就會忘記當時做這個的理由和原因是什么了，所以寫背景，一方面是為了以后翻起舊賬的時候可以做參考；另一方面是在需求評審或者分配開發(fā)任務的時候，讓開發(fā)和測試能夠認同這個需求，有共同目標和共同的認知。

畢竟如果團隊成員都不知道為什么要做這個，做這個的意義是什么，那么久而久之需求就會變成一項苦差事，大家就沒有奮斗和拼勁了。

背景除了上述說到的功效，還能在寫背景的過程中對需求進行一個初步評估，結合各種方法論和一些指導，比如我們常聽到的：“用戶訪談，調研”，“市場調研”，“需求析”，“SWOT”，“5W1H”等……

總之這個環(huán)節(jié)就是要確定需求是能做的，是有價值的，讓大家認同這一點，才能接下來去落實具體的方案。產品做完了這一步，才能進行第二步的工作。

第二步：方案制定

方案制定是一個大環(huán)節(jié)，也是「需求設計」環(huán)節(jié)中最重要的一環(huán)，我一般根據產品生命周期會將產品工作流程分為這幾個大塊：

1. 需求的收集與評估；
2. 需求的設計與評審；
3. 需求的研發(fā)與測試；
4. 需求的上線與跟進。

本文所講的產品方法論其實是針對「需求的設計與評審」這一環(huán)節(jié)來寫的，其他環(huán)節(jié)也重要，但是本文重點突出「需求的設計與評審」這一塊。

一般來說，做一個需求的時候，需求提出者會給出“問題型需求”和“方案型需求”，那么什么是“問題型需求”，什么是“方案型需求”？

拿WMS中的一個多SKU流水導出的需求來舉例，“問題型需求”應該是這樣提出的：

我在導出SKU的流水時候，會發(fā)現每次只能導出一個SKU，或者每次只能導出一個貨主的全部SKU的流水，我希望有一個功能，能讓我自己選擇要導出的SKU，這樣既不用一次性導出去挑選想要的，也不會用分多個批次導出每個SKU的流水然后拼接到一起。

而“方案型需求”一般會這樣提出：

我在導出SKU的流水時候，會發(fā)現每次只能導出一個SKU，或者每次只能導出一個貨主的全部SKU的流水，我希望你們能做一個功能，讓我在界面上勾選我想要的SKU信息，然后進行導出，這樣的話我想要哪幾個SKU就能導出哪幾個SKU，就很方便了。

注意看上面的需求描述，其實大體上來說都是在描述一個事，但是“問題型需求”側重的是表達自己遇到的問題，以及自己想要的結果。

而“方案型需求”則會表達出自己期望的操作方式或者解決手段，往往很多時候，需求提出者并不懂技術，也不懂系統的一些架構，限制等，所以他們提出的這種要求，有時候是能滿足的，有時候卻不能滿足。

但是，如果產品經理沒有仔細去分辨其中的原因，就會先入為主的被這種“方案型需求”代入其中，一直想用需求方描述的方式去解決這個問題，當遇到瓶頸的時候還是會一股腦的想要按照需求描述的去實現，而難以跳出來去尋找其他的方案。

其實也許用另外的一種交互或者手段一樣能達到這種要求，所以當一個需求提出的時候，我們應該仔細地去分辨，它是“問題型需求”還是“方案型需求”。當需求是一個“問題型需求”的時候，我們會不受約束地去想到多種方案和辦法，這樣更加有利于迅速和準確地解決問題。

方案制定包含很多內容，但是核心點就是：出一個方案，這里的方案可以是初步的，不成熟的，但是一定是要具有可行性的，能被大家認同的。

所以我一般會出一些流程圖，業(yè)務分析介紹圖等和開發(fā)或者是業(yè)務干系人進行初步溝通，看看這種方案從理想化，抽象化的角度是否具有可行性，是否能解決需求方的問題。

方案的制定一樣的會有很多成熟的方案論，例如“用例圖”，“泳道圖”，“任務拆解”，“需求剖析”，“對比分析”，“用戶調研”，“數據佐證”等等……

這里一樣不展開講了，此環(huán)節(jié)的關鍵目標是：制定出一個初步的需求解決方案，最好是通過了一些業(yè)務干系人的認可。

第三步：產品結構圖

產品結構圖，產品信息結構圖，產品功能結構圖，基本上算是逼死產品小白三座大山了。

首先是從字面意思就有點繞，都是結構，都長得很像，但是又不像；其次就是網上的解釋五花八門，大家各自有各自的認知和理解，誰也不能說服誰；最后是到底用哪個，大家也沒有準信，全部都寫，都整理出來太麻煩，費時間，不整理出來又怕被人說自己不專業(yè)，是個“野雞產品”……

于是乎，產品小白們，卒！

在這一塊我個人的理解是產品結構包含了產品信息結構和產品功能結構，「產品信息結構」就是指為了解決這個需求那我做出來的頁面或者功能它有什么信息，例如WMS多批次收貨功能中的信息：

• 一共有幾個界面，每個界面分別能展示什么信息等；
• 一個有多少字段，字段的限制、規(guī)則、解釋等；
• 展開與縮起的信息分別有哪些，優(yōu)先級順序是怎么樣的；
• 功能帶來的交互，文案，提示，以及涉及的一些異常機制等；

而「產品功能結構」則是突出此需求需要用到什么功能，功能是放在什么位置，起什么作用之類的，繼續(xù)的拿WMS多批次收貨功能來舉例，它的功能結構包含有：

• 每個界面的功能，有什么按鈕，按鈕的作用；
• 每條數據應該有什么狀態(tài)，不同的狀態(tài)有什么不同的功能；
• 功能會帶來什么作用，產生什么后續(xù)的結果；
• 功能引發(fā)的一系列聯動，例如記錄日志、其他系統的聯調，多個模塊間的聯動等；

總體來說，你會發(fā)現產品信息結構和產品功能結構并不能百分百切割獨立，其中還是會有一些重疊的部分和互相作用（信息是功能，功能也是信息）的部分，所以我一般會將這兩個東西放在一個Mindjet中，取名就是「產品結構圖」，甚至會在里面加上一些特殊的業(yè)務說明和一些背景介紹等，因為它們可能既不是功能，也不是結構，但是卻構成了產品結構圖。

我推薦大家不明白的可以去看「人人都是產品經理」中的兩篇文章，它們的訪問量和閱讀量都很高，具有一定的指導意義。

此環(huán)節(jié)主要的作用就是：抽象化需求，形成明確的方案，這種方案是躍然于紙的感覺，大家可能看到了你的產品結構圖基本上就能腦補出你做的東西大概是怎么樣子了。

模塊四：原型或文檔

最后一步是關于原型和文檔，這一塊也是所有產品最熟悉的環(huán)節(jié)了，因為基本上的需求都會走到這一步，不管怎么樣，原型不畫那文檔總要寫吧。

這一塊我的方法論反而是比較成熟和穩(wěn)定的了，一般針對原型來說，我都是低保真中突出重點，因為我們團隊沒有UI，所以基本上我如果要對UI有什么特殊要求，我就要在低保真的原型中重點突出這個需求，同時也要進行私下的溝通或者驗收，以防止開發(fā)沒有看到或者沒有重視這個問題。

而原型設計其實就是對上一步的抽象化的方案進行實例化，做過開發(fā)或者能理解面向對象的人就很容易get這個意思。需求的設計和梳理其實都是抽象化的，畫原型和寫文檔就把這個需求的方案從抽象化的類變成實例化的對象。

類是對象的抽象，而對象是類的具體實例。所以從這一點我們也就可以理解，為什么很多時候產品面試的時候并不會很看重一個人的產品原型繪制的能力呢？

因為原型繪制只是一種表達的手段，你的原型畫的很好看，很漂亮，這是一個優(yōu)勢，但是如果你不能很好的達成它最原始的目的，那么這個漂亮和好看并沒有多少實用性。而它的原始目的就是：實例化前一步的產品結構圖，填充它，讓開發(fā)和測試可以更加清晰明了的知道具體的方案是怎么樣的。

原型只是一個手段，文檔也只是一個手段，如果你能空用嘴巴講清楚這個需求，其實你也一樣是一個優(yōu)秀的產品，但是嘴巴講出去的東西沒有根據，沒有日志，以后要追溯的時候就不那么好使了，這個時候咱就得以筆代嘴，多寫點文檔。so，對產品的文檔能力有一定的要求，其實一點不過分，因為太重要了。

最后

方法論這個東西就是“我之蜜糖，彼之砒霜”的玩意兒，有時候你遇到了相似的問題的時候就會發(fā)現這個東西賊好用，但是如果你一直遇不到相似的問題那么就會覺得這個東西寫的毫無意義，也毫無水平。所以每個人的方法論都有一定的局限性，希望我的這篇陋文能給你一些啟發(fā)。

如果你有何高見或者斧正之處，請留言指出，謝謝！我們下一篇再見！屆時，我會結合本文所講的產品方法論，PO出我實際工作中出的一些流程圖，產品結構圖等，以便讓大家更加方便和直觀，接地氣地了解我所說的「產品方法論」到底是什么！

#專欄作家#

vitamin，微信公眾號：皮醬叨逼叨；人人都是產品經理專欄作家?？缇畴娚坦渹}儲物流產品一枚，主導過在線教育類產品，歡迎互相交流學習！

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議