在上兩篇文章中，筆者就用戶調(diào)研和競品分析這兩個方面提出了自己的一些見解。接下來，就要到產(chǎn)品分析部分了，而需求分析將會是第一步，接下來讓我們看看筆者怎么說的吧：
在各大PM論壇里，C端產(chǎn)品的需求分析指導(dǎo)文章已經(jīng)很常見了，而B端產(chǎn)品的需求分析也有很多大牛提出了自己有針對性的見解。那么在本文中，筆者結(jié)合自己實(shí)際的工作經(jīng)歷，分享一下在B端產(chǎn)品設(shè)計前期的需求分析方面所收獲的經(jīng)驗，以供大家共同學(xué)習(xí)交流。由于專業(yè)及領(lǐng)域限制，難免存在偏差或謬誤的地方，還請各位前輩指點(diǎn)一二，筆者感激不盡。
筆者將從三個步驟展開需求分析的相關(guān)論述，其分別為需求收集、需求整理、需求轉(zhuǎn)化。
一、需求收集
要想設(shè)計一款優(yōu)秀的B端產(chǎn)品，首先就要廣泛的收集需求。B端產(chǎn)品的需求來源要比C端產(chǎn)品的需求來源廣泛，簡要來說大概有以下幾個方面：
針對上述幾個方面，簡要介紹一下每個需求來源方的情況：
- 客戶：這里主要是通過調(diào)研客戶時收集需求，包括To B角色鏈中的決策者、運(yùn)維人員、最終用戶。至于如何有效地調(diào)研客戶，可以參考筆者的上一篇文章《B端產(chǎn)品經(jīng)理進(jìn)行客戶調(diào)研的三個階段》。
- 公司內(nèi)部：公司內(nèi)部的來源主要有三個方面：一是與其他產(chǎn)品線合作的需求；二是產(chǎn)品線內(nèi)其他同事，例如運(yùn)營、技術(shù)服務(wù)、定制組等同事提出的需求；三是公司內(nèi)部對于產(chǎn)品本身合規(guī)性的需求，例如軟件銷售許可證、軟件著作權(quán)所需要的一些需求點(diǎn)。
- PM本身：這里主要是PM自己通過競品分析或者YY出來的一些需求。
- 技術(shù)突破：這是一個值得關(guān)注的點(diǎn)，相對于C端產(chǎn)品來說，行業(yè)內(nèi)技術(shù)突破往往會在一定程度上影響B(tài)端產(chǎn)品的發(fā)展方向。舉個例子：筆者曾從事企業(yè)數(shù)據(jù)安全行業(yè)，隨著中國大陸HTTPS加密技術(shù)的普及，越來越多的網(wǎng)站及應(yīng)用開始使用HTTPS加密自己的流量；那么筆者在設(shè)計數(shù)據(jù)安全產(chǎn)品時，首要考慮的需求就是如何解密HTTPS流量，如果流量無法解密，那么企業(yè)數(shù)據(jù)安全也就無從談起。
- 外部環(huán)境：這里主要是關(guān)注國家政策、法律法規(guī)的變化，有時候新的法律法規(guī)或政策能催生出一個全新的行業(yè)。
- 老大/老板：這個就不說了，都是PM，大家心里都懂。
好了，我們在通過多方渠道將需求收集完畢后，面對一大堆需求，你肯定會感到頭疼，別急，下一步要做的事就是將它們進(jìn)行整理。
二、需求整理
對于需求整理來說，核心就是要從一大堆需求里挑出該做的需求，然后把這些需求按照優(yōu)先級進(jìn)行排列。
關(guān)于優(yōu)先級，筆者有一點(diǎn)想法，曾經(jīng)在一位前輩的文章中看到一個排優(yōu)先級的做法，即將需求按照百分制進(jìn)行打分，分?jǐn)?shù)高的優(yōu)先級就高，后來試行了這一做法，發(fā)現(xiàn)被開發(fā)同事拿刀追著砍。后來跪地求饒才知道，對于開發(fā)同事而言，無論一個需求的優(yōu)先級高還是低，最終都是要做的。既然都要做，又何來分?jǐn)?shù)高低一言。因此，筆者之后在排需求優(yōu)先級的時候，都只是排出了每個需求的最晚完成的迭代版本，而不分一個迭代版本里需求的優(yōu)先級高低。
當(dāng)然，不同企業(yè)有不同企業(yè)的做法，各位PM還是按照自己與開發(fā)同事最舒服的相處模式進(jìn)行即可。
回到文章，我們在收集了一堆需求后，如何從一大堆需求里挑出該做的需求呢？
筆者有如下幾點(diǎn)建議：
1. 基于業(yè)務(wù)場景進(jìn)行整理
B端產(chǎn)品就關(guān)鍵就在于解決業(yè)務(wù)場景中遇到的問題。那么，我們可以基于真實(shí)的業(yè)務(wù)場景流程，梳理我們所收集的需求。
舉個例子：筆者設(shè)計的產(chǎn)品為企業(yè)數(shù)據(jù)安全，那么其針對的最典型的場景就是數(shù)據(jù)泄密。基于數(shù)據(jù)泄密的場景，我們可以梳理出在【泄密監(jiān)控】-【關(guān)鍵數(shù)據(jù)外發(fā)】-【泄密檢測】-【泄密告警】-【泄密舉證】-【線下處置反饋】-【持續(xù)泄密監(jiān)控】這一泄密流程中所需要的一切功能和需求點(diǎn)，進(jìn)而整理出該做的需求。
2. 基于決策鏈進(jìn)行整理
前面幾篇文章也有提到，B端產(chǎn)品的決策鏈冗長而又復(fù)雜。我們在整理需求時，也可以從Key Person的角度出發(fā)，去整理一些針對決策鏈中關(guān)鍵人物的需求。
舉個例子：還是企業(yè)數(shù)據(jù)安全產(chǎn)品，這款產(chǎn)品在企業(yè)中涉及到的關(guān)鍵人物如下圖：
基于這些關(guān)鍵的決策人物，我們就可以去整理產(chǎn)品的需求，例如：針對CTO，我們的產(chǎn)品所使用的技術(shù)一定要夠前沿，如使用神經(jīng)網(wǎng)絡(luò)分析等等；針對IT運(yùn)維主管，產(chǎn)品的部署和實(shí)施要盡可能簡單，最好能旁路部署等等。
3. 基于緊急程度進(jìn)行整理
這里可以采用大名鼎鼎的四象限法則進(jìn)行整理，舉例如下：
（皮一下不要當(dāng)真）
4. 基于整體性進(jìn)行整理
基于整體性進(jìn)行整理的意思是，我們在整理需求的時候，既要能夠看到產(chǎn)品的細(xì)節(jié)，也要能夠看到產(chǎn)品的宏觀。你可以想象成隨時放大/縮小一款產(chǎn)品，這樣就不會被局限在某個小細(xì)節(jié)或者小需求中，能夠跟全面地去考慮多個需求之間的關(guān)聯(lián)性。
基于上述四點(diǎn)建議，我們挑選出了一堆需求并確認(rèn)了其優(yōu)先級。那么，接下來我們可以將它放到一個需求矩陣中去。需求矩陣的內(nèi)容包括如下：
其中，有幾點(diǎn)需要說明：
- 需求受益人指的是此需求實(shí)現(xiàn)后，最終落實(shí)在產(chǎn)品交付層面上的受益人。例如：采用了機(jī)器學(xué)習(xí)技術(shù)，那么這里的受益人就是CTO（技術(shù)把關(guān)者）；采用了旁路部署模式，那么這里的受益人就是運(yùn)維人員（降低工作量）。
- 需求實(shí)現(xiàn)復(fù)雜度和人力估算，最好找個時間和開發(fā)經(jīng)理坐下來，互相溝通一起評估，避免由于對技術(shù)不了解而隨意評估導(dǎo)致被砍。
- 變更說明一般在需求變更后，要詳細(xì)的填寫變更原因和直接變更人，避免背鍋。
最后還有一點(diǎn)，相信每一位B端產(chǎn)品經(jīng)理在職業(yè)生涯中都會遇到一個永遠(yuǎn)繞不開的問題——定制化。如何找到產(chǎn)品標(biāo)準(zhǔn)化與定制化之間的平衡——有哪些需求在整理時可以放棄，轉(zhuǎn)而采用定制的方式解決；而又有哪些定制的需求，可以合入通用版本，以降低定制工作量。
這里面有很多坑，而這些坑筆者都踩過，真的是一個都沒有落下。后續(xù)筆者會單獨(dú)寫一篇文章與各位分享其中的辛酸苦辣，各位可以提前準(zhǔn)備好瓜子小板凳。
三、需求轉(zhuǎn)化
在整理好需求矩陣后，我們就可以開始著手需求的轉(zhuǎn)化工作了，說白了就是寫文檔、畫原型。其中需要注意的是，與C端PM所需要編寫的PRD不同，在筆者曾就職的企業(yè)中，B端PM需要編寫兩份文檔，一份是用戶場景需求文檔，一份是系統(tǒng)需求文檔。
用戶場景需求文檔，顧名思義，就是基于用戶真實(shí)的使用場景去編寫一份文檔。文檔的基本編寫邏輯如下：
【什么業(yè)務(wù)場景】-【什么問題】-【客戶有什么需求】-【期望操作步驟】
需要注意的是，在編寫用戶場景需求文檔是，要將所有的需求點(diǎn)都納入進(jìn)來，而不是只寫某一個迭代版本中的需求。對于B端產(chǎn)品來說，這一份文檔是最重要的，能不能發(fā)掘客戶真實(shí)的業(yè)務(wù)需求就看這一份文檔寫得全不全，有沒有寫透徹。
因此，在用戶場景需求文檔編寫完成后，需要召集市場、運(yùn)營、開發(fā)同事進(jìn)行一次需求文檔評審會議。怎么開會估計各位PM比我還懂，此處略去會議過程，但是有一點(diǎn)要注意，在用戶場景需求文檔的評審會議中，要盡可能地避免討論技術(shù)實(shí)現(xiàn)的問題。
評審?fù)ㄟ^后，就可以拿著需求矩陣和用戶場景需求文檔去找交互設(shè)計師了。一般來說，在B端產(chǎn)品企業(yè)里，PM都不需要自己動手畫原型。所以筆者也只是負(fù)責(zé)跟交互設(shè)計師對接需求即可，專業(yè)的事還是交給專業(yè)的人靠譜。
在交互設(shè)計師給出基礎(chǔ)的交互設(shè)計圖之后，需要組織產(chǎn)品組內(nèi)同事對交互設(shè)計圖進(jìn)行一次評審，評審主要是為了檢查產(chǎn)品在交互設(shè)計中用戶的業(yè)務(wù)場景流程完不完整，是否存在邏輯不合理的問題。通過后，便可以不斷完善交互圖中的功能細(xì)節(jié)。
待交互設(shè)計圖完善后，還需要寫一份系統(tǒng)需求文檔。這里就和各位C端PM們的PRD工作差不多了，基于交互圖，指出某個功能在某個場景下的操作步驟及結(jié)果。但是需要注意的是，系統(tǒng)需求文檔中也需要給出一些基本的技術(shù)參數(shù)，例如查詢功能的響應(yīng)時間要求、底層架構(gòu)穩(wěn)定性要求等等，這些參數(shù)要盡可能量化，如果不好確定，可以與開發(fā)經(jīng)理一同確認(rèn)。
最終，需求轉(zhuǎn)化后的結(jié)果就是兩份文檔+一份交互設(shè)計圖。此時，需要在正式開發(fā)前，組織一次外部評審，邀請其他產(chǎn)品線的同事，最后檢驗一次產(chǎn)品的所有設(shè)計細(xì)節(jié)，當(dāng)然，這里面也會有很多坑，例如會涉及到需求變更、技術(shù)實(shí)現(xiàn)難度等等。后續(xù)，筆者會單獨(dú)出一篇文章，講一講在B端PM在各類評審會議中遇到的坑。
至此，一次需求分析的過程結(jié)束。由于篇幅原因，其中很多細(xì)節(jié)并未詳細(xì)描述，例如：交互設(shè)計、需求變更、評審等。
正常來說，一次B端產(chǎn)品的需求分析少則數(shù)周，多則數(shù)月。在其中，你可能會無數(shù)次推翻你曾確信的需求，你也可能會改無數(shù)次文檔，甚至連交互設(shè)計小姐姐都改圖改到不想再改了。你可能會很痛苦，團(tuán)隊也會很痛苦，但要相信，當(dāng)你經(jīng)歷過痛苦后，看到自己心心念念的產(chǎn)品一點(diǎn)一點(diǎn)被打磨出來，又被成千上萬家企業(yè)所使用后，這種成就感是無與倫比的。那一刻，你會覺得這一切都值得。所以，保持強(qiáng)大的內(nèi)心，才能堅定的走在To B的道路上。
B端產(chǎn)品不易，且行且珍惜。
愛盈利-運(yùn)營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運(yùn)營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運(yùn)營從業(yè)者的知識啟蒙、成長指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運(yùn)營小咖秀（ID: yunyingshow）
【轉(zhuǎn)載說明】 若上述素材出現(xiàn)侵權(quán)，請及時聯(lián)系我們刪除及進(jìn)行處理：[email protected]
