從事產(chǎn)品行業(yè)也有一段時間了，體會過一頭霧水做項目的感受，這里也就想記錄分享一下遇到的一些問題和一些經(jīng)驗。
首先，這里主要介紹的是B端產(chǎn)品從0到1的搭建，比較適合剛剛接觸B端，在市場上找不到完全開發(fā)的成熟競品分析的新手們。
1.如何快速了解需求
我們都知道做為一個產(chǎn)品經(jīng)理，最重要的就是明確需求，但是在規(guī)劃B端產(chǎn)品的時候往往一開始就卡在了這里，因為B端產(chǎn)品的主要支持靠是業(yè)務(wù)，但是大部分時候，我們做規(guī)劃的產(chǎn)品經(jīng)理往往是不了業(yè)務(wù)需求的，這個時候如果集團(tuán)突然說要做了一個B端項目，我們很容易就陷入一個誤區(qū)----業(yè)務(wù)部門說什么我們就做什么（這點我剛接觸B端產(chǎn)品的時候深有體會，后來也為填這個坑付出過血淚教訓(xùn)），一定要警惕這里，很多業(yè)務(wù)部門提出的需求是在他們自己覺得現(xiàn)有的流程不行想按照自己的想法進(jìn)行調(diào)整的，這個里面就會有很多偽需求，所以一定要避開這個誤區(qū)，怎么做。
我個人用的最快的方法就是搭建業(yè)務(wù)流程圖，在不完全了解業(yè)務(wù)的情況下，我想快速熟悉并且明確業(yè)務(wù)，上手開始畫流程是最快的方式（這里指我個人呀，后來再遇到的項目屢試不爽）。
以下為搭建一個客服報事系統(tǒng)的業(yè)務(wù)流程圖，把報事的每個角色每個報事入口拆分，在進(jìn)行業(yè)務(wù)流轉(zhuǎn)，基本一套圖下來，這個業(yè)務(wù)也就熟悉的差不多了。
業(yè)務(wù)圖完成之后，接下來就是對圖做拆分，對現(xiàn)有流程進(jìn)行一個分析過程，然后找到流程中冗余或者可以優(yōu)化的部分，找出其中的偽需求，方便在接下來在進(jìn)一步的進(jìn)行需求分析。
2.定義功能清單
還是以客服報事為例，在理解業(yè)務(wù)需求后，我們結(jié)合業(yè)務(wù)部門的期望以前自己對這個業(yè)務(wù)的理解（注意這個理解一定不要自己想出來就定了，也需要跟業(yè)務(wù)部門溝通）有一個最大的建議就是我們在產(chǎn)品1.0時期主要以簡化不必要的流程做起，不要加太多個人主觀因素的優(yōu)化，先做一個簡單的迭代版本，不要想著一口氣做到最好。
在根據(jù)業(yè)務(wù)流程圖梳理清楚需求之后，我們可以開始著手做一份功能清單（我用的是思維導(dǎo)圖，有些可能更喜歡用excel，這個看公司要求），這個清單上會記錄我們這個產(chǎn)品在每個設(shè)備上應(yīng)該要具有什么功能，最終我們繪制原型的時候，就是根據(jù)這份清單來制作不同的功能模塊。這份清單也可以幫助我們的技術(shù)小哥哥們快速知道整個產(chǎn)品分多少個端口，大概有多少功能等等。
3.制作原型
在功能清單出來之后，跟著做原型就真的是一件很簡單的事情啦。需求都已經(jīng)明確化了（跟各業(yè)務(wù)口確認(rèn)過的情況后），在根據(jù)清單中劃分的設(shè)備所以功能開始出圖，建議最好是PC端先出，因為很多app端的展示是要根據(jù)pc給的限制來做。比如：有些要做字符展示的，PC做了最大字符控制，app也可以根據(jù)這個控制來設(shè)計展示方式。
我們在繪制原型的時候也會容易有一個誤區(qū)，那就是我們做線框圖很多時候可能都是說先把頁面上要有的功能全部鋪出來，具體的擺放，就想著還有UI，靠UI調(diào)整，但是這里會有一個不太好的地方，就是技術(shù)在研發(fā)的時候，原型圖和效果圖差距太大，導(dǎo)致對整個功能出現(xiàn)理解偏差的問題，真的是時有發(fā)生。大一點的公司可能會專門設(shè)有U交互師，會在這其中在做一次調(diào)整，但是當(dāng)前部分的情況是，要么是產(chǎn)品兼職了交互，要么是UI兼職了交互，更多的時候還是產(chǎn)品在做交互這個角色，所以我們在做原型的時候，也要更多的考慮產(chǎn)品的易用性。
下面以我做的一個原型以及我們UI出的原型為示例：
這里找了兩個比較布局簡單的頁面做示例，可以看出來在樣式分布上，我們都是基本一致的，這里有個好處就是，技術(shù)小哥哥們在開發(fā)的時候，對比查看的難度會降低很多，我們在設(shè)計上游如果把產(chǎn)品交互布局布置的有一定的合理性對下游的設(shè)計以及開發(fā)都會減少很多難度。
當(dāng)然這里也看公司的要求了，我們是因為公司在產(chǎn)品上就要求的比較規(guī)范化了。這也有利于后期如果大家負(fù)責(zé)的應(yīng)用模塊需要整改起來的時候，風(fēng)格不會過分差異化。
4.基本交互
原型頁面搭建完成之后，我們現(xiàn)在有一種主流思維就是不要做太多的交互化，但是從我個人的經(jīng)驗來看，加了交互的原型在給客戶跟技術(shù)宣講時會比完全平鋪的原型要更加容易被接受。這里說的交互不是說要完全高保真，是指一些基本的頁面調(diào)整，彈框樣式這些。做一個流程能達(dá)閉環(huán)是最好的。
簡單的交互可以加快快發(fā)以及設(shè)計人員對業(yè)務(wù)的理解。但是有一點確實，不要花太多的精力去研究交互，我們產(chǎn)品做得非常復(fù)雜非常炫酷的交互技術(shù)從性能考慮大部分都會被斃掉，所以基本的交互最好要有，但是過于復(fù)雜的就不要了。
下面是一個原型交互示例
5.文檔編寫
每個公司對于PRD文檔的編寫可能都是有自己的要求的，這里就針對那些剛?cè)腴T或者公司沒有要求的新手們推薦一種我個人用的比較多的方式，（我們公司不要求文檔用word編寫，，所以我這里都是直接寫在文檔原型上的，以前我也是原型word分開寫，后來我發(fā)現(xiàn)技術(shù)大佬們根本不看文檔，吐血。）
可以參考下圖：
大致就是把拆分為幾個說明區(qū)域：
功能說明：簡要概括這個頁面要做的事情，方便技術(shù)人員快速理解這里的業(yè)務(wù)。
表單說明：對這個頁面的字段進(jìn)行說明。
交互說明：對這個頁面要有的交互進(jìn)行說明。
等等其他自己需要擴(kuò)展的說明，比如上文中有些頁面有新建操作，這個新建是個比較重要的組件，所以可以單獨拿出來做一個新建編輯說明。
這種方式就是會比較清楚明了的方便技術(shù)快速定位需要了解的說明，但是有一點就是頁面最好是保持在一屏下，不然頁面跟說明過于分散也不利于瀏覽。
