在上兩篇文章中，筆者就用戶調(diào)研和競品分析這兩個方面提出了自己的一些見解。接下來，就要到產(chǎn)品分析部分了，而需求分析將會是第一步，接下來讓我們看看筆者怎么說的吧：

在各大PM論壇里，C端產(chǎn)品的需求分析指導(dǎo)文章已經(jīng)很常見了，而B端產(chǎn)品的需求分析也有很多大牛提出了自己有針對性的見解。那么在本文中，筆者結(jié)合自己實際的工作經(jīng)歷，分享一下在B端產(chǎn)品設(shè)計前期的需求分析方面所收獲的經(jīng)驗，以供大家共同學(xué)習(xí)交流。由于專業(yè)及領(lǐng)域限制，難免存在偏差或謬誤的地方，還請各位前輩指點一二，筆者感激不盡。

筆者將從三個步驟展開需求分析的相關(guān)論述，其分別為需求收集、需求整理、需求轉(zhuǎn)化。

一、需求收集

要想設(shè)計一款優(yōu)秀的B端產(chǎn)品，首先就要廣泛的收集需求。B端產(chǎn)品的需求來源要比C端產(chǎn)品的需求來源廣泛，簡要來說大概有以下幾個方面：

針對上述幾個方面，簡要介紹一下每個需求來源方的情況：

• 客戶：這里主要是通過調(diào)研客戶時收集需求，包括To B角色鏈中的決策者、運維人員、最終用戶。至于如何有效地調(diào)研客戶，可以參考筆者的上一篇文章《B端產(chǎn)品經(jīng)理進行客戶調(diào)研的三個階段》。
• 公司內(nèi)部：公司內(nèi)部的來源主要有三個方面：一是與其他產(chǎn)品線合作的需求；二是產(chǎn)品線內(nèi)其他同事，例如運營、技術(shù)服務(wù)、定制組等同事提出的需求；三是公司內(nèi)部對于產(chǎn)品本身合規(guī)性的需求，例如軟件銷售許可證、軟件著作權(quán)所需要的一些需求點。
• PM本身：這里主要是PM自己通過競品分析或者YY出來的一些需求。
• 技術(shù)突破：這是一個值得關(guā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，大家心里都懂。

好了，我們在通過多方渠道將需求收集完畢后，面對一大堆需求，你肯定會感到頭疼，別急，下一步要做的事就是將它們進行整理。

二、需求整理

對于需求整理來說，核心就是要從一大堆需求里挑出該做的需求，然后把這些需求按照優(yōu)先級進行排列。

關(guān)于優(yōu)先級，筆者有一點想法，曾經(jīng)在一位前輩的文章中看到一個排優(yōu)先級的做法，即將需求按照百分制進行打分，分數(shù)高的優(yōu)先級就高，后來試行了這一做法，發(fā)現(xiàn)被開發(fā)同事拿刀追著砍。后來跪地求饒才知道，對于開發(fā)同事而言，無論一個需求的優(yōu)先級高還是低，最終都是要做的。既然都要做，又何來分數(shù)高低一言。因此，筆者之后在排需求優(yōu)先級的時候，都只是排出了每個需求的最晚完成的迭代版本，而不分一個迭代版本里需求的優(yōu)先級高低。

當然，不同企業(yè)有不同企業(yè)的做法，各位PM還是按照自己與開發(fā)同事最舒服的相處模式進行即可。

回到文章，我們在收集了一堆需求后，如何從一大堆需求里挑出該做的需求呢？

筆者有如下幾點建議：

1. 基于業(yè)務(wù)場景進行整理

B端產(chǎn)品就關(guān)鍵就在于解決業(yè)務(wù)場景中遇到的問題。那么，我們可以基于真實的業(yè)務(wù)場景流程，梳理我們所收集的需求。

舉個例子：筆者設(shè)計的產(chǎn)品為企業(yè)數(shù)據(jù)安全，那么其針對的最典型的場景就是數(shù)據(jù)泄密?；跀?shù)據(jù)泄密的場景，我們可以梳理出在【泄密監(jiān)控】-【關(guān)鍵數(shù)據(jù)外發(fā)】-【泄密檢測】-【泄密告警】-【泄密舉證】-【線下處置反饋】-【持續(xù)泄密監(jiān)控】這一泄密流程中所需要的一切功能和需求點，進而整理出該做的需求。

2. 基于決策鏈進行整理

前面幾篇文章也有提到，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運維主管，產(chǎn)品的部署和實施要盡可能簡單，最好能旁路部署等等。

3. 基于緊急程度進行整理

這里可以采用大名鼎鼎的四象限法則進行整理，舉例如下：

（皮一下不要當真）

4. 基于整體性進行整理

基于整體性進行整理的意思是，我們在整理需求的時候，既要能夠看到產(chǎn)品的細節(jié)，也要能夠看到產(chǎn)品的宏觀。你可以想象成隨時放大/縮小一款產(chǎn)品，這樣就不會被局限在某個小細節(jié)或者小需求中，能夠跟全面地去考慮多個需求之間的關(guān)聯(lián)性。

基于上述四點建議，我們挑選出了一堆需求并確認了其優(yōu)先級。那么，接下來我們可以將它放到一個需求矩陣中去。需求矩陣的內(nèi)容包括如下：

其中，有幾點需要說明：

1. 需求受益人指的是此需求實現(xiàn)后，最終落實在產(chǎn)品交付層面上的受益人。例如：采用了機器學(xué)習(xí)技術(shù)，那么這里的受益人就是CTO（技術(shù)把關(guān)者）；采用了旁路部署模式，那么這里的受益人就是運維人員（降低工作量）。
2. 需求實現(xiàn)復(fù)雜度和人力估算，最好找個時間和開發(fā)經(jīng)理坐下來，互相溝通一起評估，避免由于對技術(shù)不了解而隨意評估導(dǎo)致被砍。
3. 變更說明一般在需求變更后，要詳細的填寫變更原因和直接變更人，避免背鍋。

最后還有一點，相信每一位B端產(chǎn)品經(jīng)理在職業(yè)生涯中都會遇到一個永遠繞不開的問題——定制化。如何找到產(chǎn)品標準化與定制化之間的平衡——有哪些需求在整理時可以放棄，轉(zhuǎn)而采用定制的方式解決；而又有哪些定制的需求，可以合入通用版本，以降低定制工作量。

這里面有很多坑，而這些坑筆者都踩過，真的是一個都沒有落下。后續(xù)筆者會單獨寫一篇文章與各位分享其中的辛酸苦辣，各位可以提前準備好瓜子小板凳。

三、需求轉(zhuǎn)化

在整理好需求矩陣后，我們就可以開始著手需求的轉(zhuǎn)化工作了，說白了就是寫文檔、畫原型。其中需要注意的是，與C端PM所需要編寫的PRD不同，在筆者曾就職的企業(yè)中，B端PM需要編寫兩份文檔，一份是用戶場景需求文檔，一份是系統(tǒng)需求文檔。

用戶場景需求文檔，顧名思義，就是基于用戶真實的使用場景去編寫一份文檔。文檔的基本編寫邏輯如下：

【什么業(yè)務(wù)場景】-【什么問題】-【客戶有什么需求】-【期望操作步驟】

需要注意的是，在編寫用戶場景需求文檔是，要將所有的需求點都納入進來，而不是只寫某一個迭代版本中的需求。對于B端產(chǎn)品來說，這一份文檔是最重要的，能不能發(fā)掘客戶真實的業(yè)務(wù)需求就看這一份文檔寫得全不全，有沒有寫透徹。

因此，在用戶場景需求文檔編寫完成后，需要召集市場、運營、開發(fā)同事進行一次需求文檔評審會議。怎么開會估計各位PM比我還懂，此處略去會議過程，但是有一點要注意，在用戶場景需求文檔的評審會議中，要盡可能地避免討論技術(shù)實現(xiàn)的問題。

評審?fù)ㄟ^后，就可以拿著需求矩陣和用戶場景需求文檔去找交互設(shè)計師了。一般來說，在B端產(chǎn)品企業(yè)里，PM都不需要自己動手畫原型。所以筆者也只是負責(zé)跟交互設(shè)計師對接需求即可，專業(yè)的事還是交給專業(yè)的人靠譜。

在交互設(shè)計師給出基礎(chǔ)的交互設(shè)計圖之后，需要組織產(chǎn)品組內(nèi)同事對交互設(shè)計圖進行一次評審，評審主要是為了檢查產(chǎn)品在交互設(shè)計中用戶的業(yè)務(wù)場景流程完不完整，是否存在邏輯不合理的問題。通過后，便可以不斷完善交互圖中的功能細節(jié)。

待交互設(shè)計圖完善后，還需要寫一份系統(tǒng)需求文檔。這里就和各位C端PM們的PRD工作差不多了，基于交互圖，指出某個功能在某個場景下的操作步驟及結(jié)果。但是需要注意的是，系統(tǒng)需求文檔中也需要給出一些基本的技術(shù)參數(shù)，例如查詢功能的響應(yīng)時間要求、底層架構(gòu)穩(wěn)定性要求等等，這些參數(shù)要盡可能量化，如果不好確定，可以與開發(fā)經(jīng)理一同確認。

最終，需求轉(zhuǎn)化后的結(jié)果就是兩份文檔+一份交互設(shè)計圖。此時，需要在正式開發(fā)前，組織一次外部評審，邀請其他產(chǎn)品線的同事，最后檢驗一次產(chǎn)品的所有設(shè)計細節(jié)，當然，這里面也會有很多坑，例如會涉及到需求變更、技術(shù)實現(xiàn)難度等等。后續(xù)，筆者會單獨出一篇文章，講一講在B端PM在各類評審會議中遇到的坑。

至此，一次需求分析的過程結(jié)束。由于篇幅原因，其中很多細節(jié)并未詳細描述，例如：交互設(shè)計、需求變更、評審等。

正常來說，一次B端產(chǎn)品的需求分析少則數(shù)周，多則數(shù)月。在其中，你可能會無數(shù)次推翻你曾確信的需求，你也可能會改無數(shù)次文檔，甚至連交互設(shè)計小姐姐都改圖改到不想再改了。你可能會很痛苦，團隊也會很痛苦，但要相信，當你經(jīng)歷過痛苦后，看到自己心心念念的產(chǎn)品一點一點被打磨出來，又被成千上萬家企業(yè)所使用后，這種成就感是無與倫比的。那一刻，你會覺得這一切都值得。所以，保持強大的內(nèi)心，才能堅定的走在To B的道路上。

B端產(chǎn)品不易，且行且珍惜。

本文由 @魔力貓 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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