導讀：小白進入產品經(jīng)理行業(yè)，總會有些迷茫，想要尋求前輩的經(jīng)驗。對本文將從產品的整個策劃流程進行寫作，包括需求調研分析、范圍層和結構層梳理、交互原型設計幾個工作節(jié)點，根據(jù)時間比例個人總結為532工作法。

一、目的

不知不覺已經(jīng)整整畢業(yè)5個月，成為產品界菜鳥新人5個月了，通過這篇文章總結一下5個月來自己從0-1的成長，也總結積累一下個人的工作方法，為之后進階為產品小白菜打下基礎。

說實話，剛接觸產品策劃這個崗位時我是比較慌、恐的?；攀且驗槟吧抑笆亲霎a品運營的，主要的業(yè)務是如何讓產品更好的為公司創(chuàng)造價值，是使用產品這個介質，不是創(chuàng)造介質，對我而言產品策劃是個陌生的領域；恐是因為未知，我不知道我能在產品這條路上走多遠，也不知道這條路到底適不適合我，只能帶著未知堅定而又慌恐的向前走。

從進入公司通過MNI項目從0到1進行產品策劃，轉正后又通過已有的項目進行從1-N的迭代優(yōu)化，這5個月對我而言真的是翻天覆地的變化，產品領域博大精深，涉及的知識領域數(shù)不勝數(shù)，這5個月看的書籍堪比我大學四年的數(shù)量。我也在實踐中初步總結出了屬于自己的工作方法，其中包括需求調研分析、范圍層和結構層梳理、交互原型設計幾個工作節(jié)點，按照時間比例我個人總結為532工作法。

二、工作方法

做過產品的人都知道B端和C端有本質上的區(qū)別，C端重視體驗，且是一類用戶多種屬性，而B端重視效率，是多種角色、多種業(yè)務，重視對業(yè)務邏輯和流程的把握。如果想B端產品設計好，那么需求的分析和調研是最重要的部分。

1. 需求調研分析

需求調研分析是很考驗產品專業(yè)的一項技能，可以說需求調研分析做好了，產品策劃工作就做好了一半。我一般會用策劃周期一半的時間去做需求調研分析，這就是“532工作法”中的“5”。

需求調研有多種方法，如問卷、訪談、崗位實踐、數(shù)據(jù)分析等，不過對于B端個人推薦訪談和實踐的方法。

1）需求分析

當你接到一個需求的時候，不能直接就去想要做成什么功能，一定要先通過調研的方式把握需求的產生原因、涉及的業(yè)務邏輯和流程、以及想要得到的效果（涉及管理層面的規(guī)范和標準，一定要不能光看業(yè)務，業(yè)務只是管理的執(zhí)行表現(xiàn)，管理層面的規(guī)范邏輯才是核心）。

以本質思維為思考方式，以追問法進行自問自答自分析，舉個例子，現(xiàn)在有1需求是想做一個采購管理的功能，用來解決采購流程不規(guī)范、采購數(shù)據(jù)追溯困難的問題。

那首先設置幾個問題，

1. 這個需求是要解決什么問題？
2. 要解決的問題涉及到了哪些業(yè)務？
3. 現(xiàn)有的業(yè)務流程是怎樣的？所涉及的相關人員都有哪些？
4. 想要的效果是怎樣的？

那么我們自己回答一下這些問題，

1. 這個需求要解決采購流程不規(guī)范、數(shù)據(jù)追溯困難的問題
2. 涉及到了物品采購業(yè)務
3. 現(xiàn)有的業(yè)務流程是先向采購員提出物品采購需求，通過后采購員進行線下的比價議價，采購負責人負責線下審批比價單，通過后采購員進行下單、向財務請款，最后收貨給到申請人；所涉及的相關人員有申請人、采購員、采購負責人、財務
4. 想要的效果是將此業(yè)務流程規(guī)范化、將線下進行僅有部分人可見的業(yè)務數(shù)據(jù)放到線上，可供業(yè)務流程上的相關人員進行協(xié)作，可快速追溯數(shù)據(jù)，讓監(jiān)察能隨時監(jiān)管

那么分析過需求，對需求的產生原因、涉及的業(yè)務流程和要得到的效果有一定了解后，就可以進行調研進行驗證了

2）需求調研

需求調研的目的是為了進一步理解需求，驗證、補充完善預先分析的結果，調研的方法我基本上會選用訪談的方式。

訪談一般對于初級的產品來說是比較困難的，一是級別不夠，很難能將所有的相關人都一起訪談，二是經(jīng)驗不足，可能無法通過一次/幾次訪談就能調研透徹。所以個人建議是初級的產品可以通過自己部門領導去組織訪談會議，同時預先做好分析，多維度總結一些要提問問題。

就我個人而言，訪談步驟基本上是

1. 預先估算一個會議時間，把會議室先預先定出來
2. 然后聯(lián)系部門領導和其他相關人，根據(jù)重要的人的時間調整會議安排
3. 訪談過程：詢問需求背景—涉及的業(yè)務有哪些—現(xiàn)有的業(yè)務流程是怎樣的—涉及哪些角色—各個角色在其中起到哪些作用—各個角色所涉及的業(yè)務細節(jié)—想要達到一個什么樣的效果/規(guī)范—提出自己的解決思路和完善流程的想法—總結會議的共識和后續(xù)跟進的相關事項和人員

調研不是通過一次訪談能徹底解決的，訪談會議基本上能解決大部分的問題，但不能解決全部問題，需要后續(xù)有更多的交流，個人建議是涉及相關人較多/需要確定的共識性問題組織相關人員進行訪談會議，相關人較少/僅涉及部分業(yè)務的問題盡量通過聊天產品進行文字交流。

3）需求梳理

需求梳理是需求調研分析的收尾部分，也是最重要的部分。這是一個承上啟下的部分，需求梳理不好前面的需求分析、需求調研就會沒有任何用處。

就我個人而言，一般情況我會根據(jù)相關業(yè)務流程去做需求梳理，以要解決的問題為中心，以業(yè)務流程為框架，以角色涉及的需求為填充。通過梳理需求，分析出解決方案，并根據(jù)業(yè)務核心程度簡單判定優(yōu)先級，同時判斷難易程度。

個人使用的需求調研分析的表格字段：序號、提書方、提出人、業(yè)務場景、業(yè)務需求、解決方案、難易程度、優(yōu)先級、備注

2. 范圍層和結構層梳理

范圍層指的是解決需求所需要擁有的能力，結構層是能力外在體現(xiàn)的功能。需求梳理階段的分析出的解決方案是初步的解決方案梳理，具體的范圍層和結構層的梳理需要更加精細化。這一步是需要根據(jù)需求調研梳理出將要做的系統(tǒng)能力和功能，還需梳理出需要關聯(lián)的外部系統(tǒng)，關聯(lián)方法、功能權限、數(shù)據(jù)權限、字段權限、審批流程、審批權限等等。這一步我一般會用策劃周期10分之3的時間去做，這是“532”工作法中的“3”。

具體步驟如下：

1. 首先梳理出業(yè)務需求所需的能力導圖，這一步一定要細致，能力基礎決定上層建筑
2. 然后根據(jù)能力去分解功能、設計功能，一定不能通過需求直接設計功能，那一定會有疏漏，一氣呵成永遠比縫縫補補要好得多
3. 梳理字段，將功能所涉及的字段一個不漏的梳理出來，不要偷懶、不要偷懶、不要偷懶
4. 梳理系統(tǒng)權限和流程，權限梳理一定要考慮數(shù)據(jù)的敏感性和角色的權限，有必要的話要將功能、字段、數(shù)據(jù)區(qū)分開，流程設置的話要考慮后續(xù)是否會有相似的路程，可以單獨設計出一個配置項，后續(xù)可復用

范圍層和結構層梳理最好是輸出思維導圖，比較清晰，在設計原型的時候超級方便。

3. 交互原型設計

交互原型設計包括三部分：原型、交互、規(guī)則。原型是結構層的外部體現(xiàn)，交互是與用戶做交流的系統(tǒng)表達，規(guī)則是在這個系統(tǒng)上的玩法以及與其他系統(tǒng)要怎樣玩。前面的工作如果都可以盡善盡美的做完，那么交互原型設計就會特別快，我一般會用策劃周期的10分之2的時間去做，這是“532”工作法中的“2”。

原型設計這里無法總結太多，我個人畫原型一般是畫低保真，規(guī)則要寫盡可能的完善，可參考一些阿里、騰訊的交互設計，B端對于交互原型沒有那么高的要求，只要高效、便捷就是好的，個人推薦采用簡潔的設計。（可以讀一讀《簡約至上》這本書。）

三、結論

我個人目前處在產品的初級階段，大多數(shù)情況只能考慮到業(yè)務和管理層面，我很清晰的能感知到。產品經(jīng)理一般有兩種模型要掌握，一是初級產品經(jīng)理要掌握的用戶模型（對于B端，此“用戶”多數(shù)指的是業(yè)務需求），二是高級產品經(jīng)理要掌握的交易模型。以后的日子還長，諸君共勉。

本文由 @神明大人吶 原創(chuàng)發(fā)布于人人都是產品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。