這篇文章想和大家探討 B 端產(chǎn)品應(yīng)該如何規(guī)劃。

很多人都說(shuō)，做 B 端產(chǎn)品最重要的是搞清楚業(yè)務(wù)邏輯。只要搞清楚業(yè)務(wù)是怎么運(yùn)作的，就能做出滿足業(yè)務(wù)需求的產(chǎn)品。

但是 B 端產(chǎn)品所處復(fù)雜的業(yè)務(wù)需求環(huán)境，如同茂密的森林一樣，產(chǎn)品經(jīng)理一不小心就會(huì)迷失在業(yè)務(wù)細(xì)節(jié)中，做出一款停留在業(yè)務(wù)表面的產(chǎn)品。導(dǎo)致這種情況的根本原因在于：一個(gè)行業(yè)花費(fèi)了幾年甚至幾十年時(shí)間建立起來(lái)的業(yè)務(wù)流程與規(guī)范，我們很難用一兩個(gè)星期完全消化。

面對(duì)這樣一個(gè)錯(cuò)綜復(fù)雜的場(chǎng)景，產(chǎn)品經(jīng)理最好的做法是循序漸進(jìn)，從最粗略的業(yè)務(wù)目標(biāo)開始，然后分析業(yè)務(wù)流程，到各職位的工作內(nèi)容，最后才是數(shù)據(jù)、報(bào)表的細(xì)節(jié)。

正如蓋爾定律所言，一個(gè)切實(shí)可行的復(fù)雜系統(tǒng)勢(shì)必是從一個(gè)切實(shí)可行的簡(jiǎn)單系統(tǒng)發(fā)展而來(lái)的。從頭開始設(shè)計(jì)的復(fù)雜系統(tǒng)根本不切實(shí)可行，無(wú)法修修補(bǔ)補(bǔ)讓它切實(shí)可行。你必須由一個(gè)切實(shí)可行的簡(jiǎn)單系統(tǒng)重新開始。

這個(gè)由粗到細(xì)的過(guò)程，就像我們?cè)诳疾煲蛔胚z址時(shí)，首先在外圍繞一圈，通過(guò)無(wú)人機(jī)鳥瞰整個(gè)建筑的全貌，對(duì)整體輪廓有一個(gè)大致的了解。再進(jìn)入到建筑物內(nèi)部，將主通道走一遍，將內(nèi)部結(jié)構(gòu)搞清楚，最后再細(xì)致研究每一個(gè)區(qū)域。

產(chǎn)品背景分析

知己知彼，方能百戰(zhàn)不殆。

無(wú)論是設(shè)計(jì) C 端產(chǎn)品還是 B 端產(chǎn)品，首先我們都要對(duì)「使用者」進(jìn)行深入的分析。C 端產(chǎn)品直接看用戶特征，為用戶做畫像做分群。B 端產(chǎn)品則需要剖析企業(yè)的經(jīng)營(yíng)過(guò)程，再去看不同使用者的需要。

第一階段的任務(wù)是對(duì)產(chǎn)品所服務(wù)的業(yè)務(wù)領(lǐng)域有一個(gè)概括性的了解。我們可以從行業(yè)背景、業(yè)務(wù)目標(biāo)與訴求、組織架構(gòu)、崗位劃分等方面開展研究。雖然第一層次并不足以讓人了解業(yè)務(wù)具體運(yùn)轉(zhuǎn)的邏輯，但是通過(guò)業(yè)務(wù)架構(gòu)描繪出的一幅業(yè)務(wù)全景，對(duì)于進(jìn)一步了解需求幫助巨大，這樣就不會(huì)迷失在茂密的需求森林中。

1. 目標(biāo)客群分析

每個(gè)產(chǎn)品都有特定的用戶群體，B 端產(chǎn)品也不例外。背景分析的第一步，首先我們要搞清楚，產(chǎn)品到底是賣給誰(shuí)？

做C端產(chǎn)品時(shí)，我們習(xí)慣用「用戶故事」幫助我們定義用戶類型。做 B 端產(chǎn)品，同樣可以用一個(gè)「企業(yè)故事」幫助我們理清目標(biāo)群體的需要。

「目標(biāo)客群是一家____公司，沒(méi)有我們產(chǎn)品之前，他們是這樣工作的：____，當(dāng)前的工作方式出現(xiàn)了____的問(wèn)題，因此想要借助我們的產(chǎn)品解決____需要，期望達(dá)到____的效果?！?/p>

假設(shè)我們現(xiàn)在要做一款針對(duì)二三線城市房產(chǎn)中介的 CRM 產(chǎn)品，企業(yè)故事可以這樣寫：

產(chǎn)品的目標(biāo)客戶是二三線城市、中小型的房產(chǎn)中介公司，沒(méi)有我們的產(chǎn)品之前，他們主要是采用市面上常見的 CRM 工具實(shí)現(xiàn)客戶管理。但是目前使用的工具沒(méi)有針對(duì)房產(chǎn)中介的流程做適應(yīng)，導(dǎo)致流程不規(guī)范，有些環(huán)節(jié)在線上、有些環(huán)節(jié)在線下進(jìn)行，數(shù)據(jù)監(jiān)管不到位，業(yè)務(wù)員管理混亂等問(wèn)題，因此想要借助我們的產(chǎn)品規(guī)范流程，以達(dá)到提升業(yè)務(wù)質(zhì)量、提高標(biāo)準(zhǔn)化效率的目的。

通過(guò)這個(gè)企業(yè)故事，我們可以定位到產(chǎn)品針對(duì)什么行業(yè)、什么規(guī)模的企業(yè)，然后明確這類公司的核心訴求，將來(lái)在做功能與設(shè)計(jì)的時(shí)候可以圍繞著這個(gè)核心訴求展開，也是產(chǎn)品不斷更新迭代的方向。

2. 業(yè)務(wù)目標(biāo)分析

短短一個(gè)企業(yè)故事，對(duì)我們后續(xù)的需求分析有很大的幫助。接下來(lái)我們還要做一道選擇題幫助我們理解產(chǎn)品的定位。

我們的產(chǎn)品對(duì)企業(yè)的重要性如何？

• 生存需要：這個(gè)產(chǎn)品關(guān)系到公司的生存問(wèn)題；
• 核心發(fā)展需要：這個(gè)產(chǎn)品有利于公司提高核心生產(chǎn)力與競(jìng)爭(zhēng)力；
• 次要發(fā)展需要：這個(gè)產(chǎn)品對(duì)公司的生產(chǎn)或發(fā)展不產(chǎn)生重大影響，但有利于公司解決一些具體的問(wèn)題，幫助公司改善非核心領(lǐng)域的工作，或改善核心領(lǐng)域的工作；
• 錦上添花需要：有這個(gè)產(chǎn)品更好，沒(méi)有也沒(méi)太大關(guān)系，可以有其他替代解決方案。

任何一個(gè) B 端產(chǎn)品，一定是在某個(gè)特定的階段滿足企業(yè)的某種價(jià)值。如果我們的產(chǎn)品直接影響企業(yè)的核心業(yè)務(wù)流程，對(duì)企業(yè)的生產(chǎn)與銷售有很大的幫助，那么這類產(chǎn)品比較受企業(yè)的歡迎，在企業(yè)經(jīng)營(yíng)的全階段都比較受歡迎，例如各類業(yè)務(wù)流程系統(tǒng)、部分垂直行業(yè)的 ERP、CRM 等。如果我們的產(chǎn)品是改善企業(yè)經(jīng)營(yíng)管理類型的，只有當(dāng)企業(yè)成長(zhǎng)到一定規(guī)模，出現(xiàn)管理需求時(shí)才比較受歡迎，例如常見的 CMS、OA、HRM 等。

這個(gè)問(wèn)題相信不難回答，但是能夠幫助我們準(zhǔn)確理解產(chǎn)品自身的定位，很多時(shí)候?qū)Ξa(chǎn)品的定位越清晰，越容易站在客戶的角度考慮，理解客戶的想法。

戰(zhàn)略分析讓我們對(duì)產(chǎn)品做到「心中有數(shù)」，接下來(lái)的需求分析是我們產(chǎn)品設(shè)計(jì)的重點(diǎn)。

業(yè)務(wù)分類，需求梳理

在做 C 端產(chǎn)品時(shí)，最重要的步驟是需求分析，也就是思考什么類型的用戶在什么場(chǎng)景下遇到了什么問(wèn)題。那么在做 B 端產(chǎn)品時(shí)，什么是 B 端產(chǎn)品的需求分析呢？

這個(gè)看似簡(jiǎn)單的問(wèn)題并不那么好回答，很多人認(rèn)為的 B 端需求就是幫助用戶完成業(yè)務(wù)流程所需要做的事情。但這樣的理解并不完整，筆者認(rèn)為 B 端的需求包含三種：

• 業(yè)務(wù)需求：即解決企業(yè)運(yùn)作過(guò)程中遇到的問(wèn)題，業(yè)務(wù)需求同樣是產(chǎn)品建設(shè)的目標(biāo)。
• 用戶需求：描述的是使用者需要完成什么任務(wù)，完成這個(gè)任務(wù)的過(guò)程中遇到的問(wèn)題；值得注意的是，用戶需求通常是零散且存在矛盾的，用戶會(huì)從不同角度、不同層面提出需求，通常都是一句話需求，而且由于用戶處于企業(yè)的不同層級(jí)，不同部門，難免會(huì)出現(xiàn)「盲人摸象」的現(xiàn)象，從而導(dǎo)致需求的片面性。
• 軟件需求：是產(chǎn)品經(jīng)理對(duì)業(yè)務(wù)需求、用戶需求，經(jīng)過(guò)分析、提煉與整理后生成指導(dǎo)開發(fā)的需求，是需求分析最終的產(chǎn)物。

需求分析的主要目的是獲得為系統(tǒng)開發(fā)提供指導(dǎo)的軟件需求。在此之前，首先我們要做的事情是挖掘業(yè)務(wù)需求與用戶需求。主要任務(wù)是梳理清楚目標(biāo)客戶群體所有的業(yè)務(wù)類型，為不同的業(yè)務(wù)類型劃分清晰的界限，并且梳理出每個(gè)業(yè)務(wù)類型中所有的業(yè)務(wù)需求與用戶需求。這個(gè)過(guò)程同時(shí)也是需求澄清的過(guò)程。

1. 業(yè)務(wù)流程分析

業(yè)務(wù)流程分析就是針對(duì)每一項(xiàng)業(yè)務(wù)事件，分析業(yè)務(wù)活動(dòng)的特點(diǎn)，并確定業(yè)務(wù)活動(dòng)之間的關(guān)系。具體要做的事情是：

• 記錄這些業(yè)務(wù)活動(dòng)需要接收哪些信息；
• 記錄這些業(yè)務(wù)活動(dòng)將產(chǎn)生哪些數(shù)據(jù)（報(bào)表），并確定數(shù)據(jù)傳輸?shù)穆肪€；
• 標(biāo)識(shí)出這些業(yè)務(wù)活動(dòng)是由哪些部門、崗位在負(fù)責(zé)。

一個(gè)企業(yè)的核心價(jià)值就是對(duì)外部客戶的訴求進(jìn)行處理，在為客戶創(chuàng)造價(jià)值的同時(shí)，為企業(yè)創(chuàng)造價(jià)值。因此由業(yè)務(wù)事件觸發(fā)的流程是分析需求時(shí)的核心線索。

在進(jìn)行流程分析的時(shí)候有幾個(gè)關(guān)鍵要點(diǎn)，一是理解流程的層次性，二是了解流程的類型，三是掌握以業(yè)務(wù)事件尋找流程的技巧。

流程的層次性

流程有組織級(jí)、部門級(jí)與崗位級(jí)三個(gè)層次關(guān)系。

• 組織級(jí)：是指經(jīng)過(guò)抽象、提煉后的業(yè)務(wù)事件，是指大方向的業(yè)務(wù)流向，例如一個(gè)產(chǎn)品可能包含生產(chǎn)、銷售、售后服務(wù)等組織級(jí)的流程；
• 部門級(jí)：是指具體每個(gè)崗位負(fù)責(zé)什么活動(dòng)，以及這些活動(dòng)之間的關(guān)系。例如一個(gè)產(chǎn)品在生產(chǎn)階段可能需要原材料部門和加工部門的配合。它是需求分析的主線索，也是流程分析的主要輸出；
• 崗位級(jí)：是指每個(gè)業(yè)務(wù)活動(dòng)具體的操作步驟，可能由某個(gè)崗位的一個(gè)人或多個(gè)人操作，屬于需求細(xì)節(jié)。

如果我們現(xiàn)在設(shè)計(jì)一款專門給房產(chǎn)中介的 CRM 產(chǎn)品，那么在調(diào)研業(yè)務(wù)流程的時(shí)候，買賣二手房就是兩個(gè)不同的組織級(jí)流程。買二手房會(huì)涉及到看房、查檔、簽合同、公證、贖樓過(guò)戶等等一系列的流程，屬于部門級(jí)流程。而在看房時(shí)，又涉及到買賣雙方初步洽談價(jià)格、付款方式、交房日期等事項(xiàng)確認(rèn)等步驟，這種屬于崗位級(jí)流程。

流程的類型

在一個(gè)企業(yè)中，根據(jù)業(yè)務(wù)流程的目標(biāo)可以將其分成不同的類型，一般我們可以分為生產(chǎn)流程、管理流程以及支撐流程三類。

• 生產(chǎn)流程是流程中最重要的部分，也是體現(xiàn)企業(yè)價(jià)值的業(yè)務(wù)環(huán)節(jié)，通常最容易識(shí)別；
• 管理流程是對(duì)生產(chǎn)流程的管控，通常是對(duì)流程效率與質(zhì)量的監(jiān)督控制；
• 支持流程是對(duì)生產(chǎn)流程的補(bǔ)充，通常是對(duì)主流程起支撐作用的環(huán)節(jié)，非必須但容易忽略。

在這款房產(chǎn)中介的 CRM 產(chǎn)品中，看房、查檔、簽合同、贖樓過(guò)戶這類環(huán)節(jié)都屬于生產(chǎn)流程。在這個(gè)主流程以外，每一個(gè)環(huán)節(jié)都有相應(yīng)的審核操作，這種流程屬于管理流程。

流程分析的輸出：跨職責(zé)流程圖

其實(shí)從不同角度來(lái)看一個(gè)業(yè)務(wù)流的時(shí)候，可能會(huì)有很多不同的流程。流程會(huì)有大小之分，主流程中可能會(huì)有子流程等，因此流程分析是一項(xiàng)龐大的工程，僅僅通過(guò)文字將流程描述清楚是很困難的，我們需要系統(tǒng)化地分析，因此可以借助「跨職責(zé)流程圖」幫助我們梳理脈絡(luò)。

跨職責(zé)流程圖是商業(yè)分析的標(biāo)準(zhǔn)工具，它定義了一套標(biāo)準(zhǔn)的建模元素與分析方法，下圖展示了房產(chǎn)中介賣房時(shí)的流程。

看到這張圖，也許很多讀者會(huì)很疑惑：這張圖也太簡(jiǎn)單了吧。談判議價(jià)以及辦理過(guò)戶手續(xù)都涉及許多業(yè)務(wù)性的判斷，為什么在圖中都不體現(xiàn)呢？

這是因?yàn)樗鼈儗儆诩?xì)節(jié)層次，在本階段判斷的原則是：不會(huì)影響其他泳道的流程，在這個(gè)階段都不需要表現(xiàn)出來(lái)。在這個(gè)場(chǎng)景中，談判議價(jià)雖然復(fù)雜，但是它的判斷流程并不會(huì)對(duì)其他泳道產(chǎn)生影響，因此我們可以暫時(shí)不看。

2. 角色與使用場(chǎng)景分析

不少讀者會(huì)有這樣的疑惑，我做 B 端的產(chǎn)品，把流程梳理完了就能知道需要設(shè)計(jì)什么功能點(diǎn)來(lái)描述需求了，為什么還要去分析角色與使用場(chǎng)景呢？對(duì)于一個(gè) B 端產(chǎn)品來(lái)說(shuō)，用戶在使用的過(guò)程中應(yīng)該是無(wú)差別的，我們硬是把這些用戶分成不同的角色那不是多此一舉嗎？

確實(shí)，我剛開始接觸 B 端產(chǎn)品時(shí)也是相同的想法。直到有一次，一位朋友給我描述他們的產(chǎn)品。

「我們這款產(chǎn)品是一個(gè)征收系統(tǒng)，給政府人員管理征收流程用的。這個(gè)產(chǎn)品包含填寫測(cè)算表、選擇安置房、選擇賠償標(biāo)準(zhǔn)、查看簽訂合約人數(shù)等等功能，填寫測(cè)算表里又分為了某某模塊…...」

當(dāng)時(shí)確實(shí)是把我聽懵了。隨后我問(wèn)了他兩個(gè)問(wèn)題：

• 這個(gè)系統(tǒng)到底有誰(shuí)在用？
• 這個(gè)系統(tǒng)幫助這些人解決什么問(wèn)題，怎么解決？

問(wèn)完之后我馬上意識(shí)到，這兩個(gè)問(wèn)題不就是典型的用例分析方法嗎？

用戶故事是指某種類型的用戶為了完成某特定目標(biāo)所執(zhí)行的一系列操作。在描述層面我們可以暫時(shí)忽略業(yè)務(wù)目標(biāo)，因此一條用戶故事包含兩個(gè)元素。

參與者

參與者是指在系統(tǒng)之外，這個(gè)流程中與系統(tǒng)進(jìn)行有意義交互的任何事物。參與者不僅可以由人來(lái)承擔(dān)，也可以是其他系統(tǒng)或者是硬件設(shè)備。

例如在看房的過(guò)程中，業(yè)務(wù)員從后臺(tái)系統(tǒng)調(diào)取房屋的平面圖以及詳細(xì)信息，這時(shí)候后臺(tái)系統(tǒng)就是其中一個(gè)參與者。如果我們的新房還沒(méi)有裝修好，用 VR 眼鏡讓客戶看到裝修后的效果時(shí)，VR 眼鏡也是流程中的參與者。參與者是一種角色，而不是一個(gè)特定的人，在某些場(chǎng)景中甚至一個(gè)人能夠充當(dāng)多個(gè)角色。

做什么事情（用例）

用例是指用戶在系統(tǒng)中執(zhí)行的一系列動(dòng)作，通常用「動(dòng)詞+名詞」的方式表達(dá)。值得注意的是，用例是有目標(biāo)的，它能夠?yàn)閰⑴c者帶來(lái)有意義的結(jié)果，例如「填寫搜索房屋條件」顯然對(duì)于參與者來(lái)說(shuō)沒(méi)有任何意義，就不是一個(gè)合適的用例。

另外用例是對(duì)一組使用場(chǎng)景的抽象。用例與場(chǎng)景之間的關(guān)系像是計(jì)算機(jī)概念中，類與對(duì)象之間的關(guān)系。一個(gè)場(chǎng)景是一個(gè)具體的行為，一個(gè)用例是對(duì)一類相關(guān)行為的抽象。

例如我們?cè)谙到y(tǒng)上找房源的時(shí)候，可能會(huì)遇到很多場(chǎng)景：使用搜索框直接搜索心儀房源、根據(jù)篩選條件挑選房源、根據(jù)推薦的新盤挑選房源、拉取兩三個(gè)房源對(duì)比后挑選等等，不管有多少種情況，只要是在做挑選房源這件事，那么這些場(chǎng)景在系統(tǒng)中，都可以概括為一個(gè)「挑選房源」的用例。

在傳統(tǒng)的結(jié)構(gòu)化分析與設(shè)計(jì)方法中，對(duì)事物的分析視角都是站在解決方案層面思考的，即這個(gè)系統(tǒng)需要有什么，從系統(tǒng)的角度出發(fā)做功能規(guī)劃。這樣做出來(lái)的產(chǎn)品，常常有用戶抱怨太難用，很難理解系統(tǒng)的意思，也不知道從哪里去找需要的功能。

而以「用戶故事」驅(qū)動(dòng)的需求分析方法，是一種更側(cè)重于「從用戶的角度出發(fā)，將系統(tǒng)當(dāng)做一個(gè)黑盒子」的視角，這種方法能夠有效解決上述問(wèn)題。

從另外一個(gè)角度來(lái)說(shuō)，用戶故事的關(guān)鍵點(diǎn)在于發(fā)現(xiàn)使用系統(tǒng)的用戶，了解并梳理這些用戶如何使用系統(tǒng)，從而達(dá)到「以人為本」的需求分析。

B 端產(chǎn)品怎么找用例？又如何把用例找「全」呢？這是一個(gè)經(jīng)常困擾產(chǎn)品經(jīng)理的問(wèn)題。

實(shí)際上，我們可以從針對(duì)各個(gè)業(yè)務(wù)事件處理過(guò)程的流程圖中得到用例。正如前文所述，流程圖是我們與企業(yè)中層管理人員溝通后得到的產(chǎn)物。只要有針對(duì)各個(gè)業(yè)務(wù)事件處理過(guò)程的流程圖，我們就可以從中導(dǎo)出相應(yīng)的用例。

跨職能流程圖對(duì)應(yīng)的不同崗位是可能產(chǎn)生用例的參與者，再加上他們所負(fù)責(zé)的事情，就是完整的業(yè)務(wù)用例。也就是我們的客戶完成一項(xiàng)業(yè)務(wù)需要做的所有事情。但是我們做一款產(chǎn)品，很多時(shí)候不能滿足客戶的所有業(yè)務(wù)環(huán)節(jié)，只能挑選與我們產(chǎn)品相匹配的核心場(chǎng)景的業(yè)務(wù)鏈條深入分析。

因此，對(duì)于我們來(lái)說(shuō)，本階段挑選的業(yè)務(wù)用例實(shí)際上就是系統(tǒng)用例。而系統(tǒng)用例的判斷要點(diǎn)在于該用例「是否屬于系統(tǒng)范圍」，以及他們所做的這個(gè)事情能否產(chǎn)生業(yè)務(wù)價(jià)值，只要滿足這兩個(gè)條件的所有用例都必須記錄下來(lái)。這樣一來(lái)，我們就能夠得到完整的系統(tǒng)用例。

有的讀者可能會(huì)問(wèn)：用例分析要分析到什么地步才能結(jié)束？

筆者的建議是不要追求完美，只要感覺已經(jīng)把客戶的業(yè)務(wù)都弄清楚就可以考慮結(jié)束，而不必等到事無(wú)巨細(xì)的每件事都梳理完整。

面對(duì)一個(gè)陌生的領(lǐng)域，一個(gè)經(jīng)歷了多年發(fā)展變化的業(yè)務(wù)流程，要在短時(shí)間內(nèi)弄清楚的確是一個(gè)不小的挑戰(zhàn)。用例分析的意義在于幫助產(chǎn)品經(jīng)理在短時(shí)間內(nèi)從結(jié)構(gòu)、整體上了解業(yè)務(wù)構(gòu)成。用例是比較高層次的業(yè)務(wù)抽象，更容易被人們理解和接受。所以進(jìn)行這一項(xiàng)工作，只需要感覺到業(yè)務(wù)的整體信息已經(jīng)可以掌握，就可以考慮停止更廣泛的用例獲取。以現(xiàn)有的用例作為基線，進(jìn)行接下來(lái)的工作。產(chǎn)品不斷迭代的前提就是建立在用例不斷優(yōu)化、不斷調(diào)整的過(guò)程中。

獲取用戶需求

在客戶調(diào)研的時(shí)候，經(jīng)?？吹疆a(chǎn)品經(jīng)理傻里傻氣地問(wèn)客戶：你對(duì)這個(gè)產(chǎn)品有什么需求或者有想法嗎？但不管用戶怎么回答，似乎都很難讓我們滿意。客戶提不出需求，你會(huì)覺得我們的客戶對(duì)這事好像也沒(méi)那么上心。更多的時(shí)候是客戶提的需求都是不痛不癢，或者你感覺極具個(gè)性化，讓你感覺做也不是，不做也不是。

和 C 端場(chǎng)景一樣，B 端場(chǎng)景中的用戶需求也像是一個(gè)冰山，有很大一部分信息是埋藏在海平面之下，這就對(duì)需求調(diào)研工作帶來(lái)很大的困擾。主要的需求分為三種：

• 意識(shí)到的需求：這是在海平面以上的需求，通常是一些困擾用戶的問(wèn)題，或者是用戶自己能想到的功能。大部分產(chǎn)品經(jīng)理在調(diào)研過(guò)程中獲取到的都是這一類需求；
• 無(wú)意識(shí)的需求：它是用戶在實(shí)際工作場(chǎng)景中「沒(méi)有意識(shí)到是問(wèn)題」的問(wèn)題，這種問(wèn)題需要產(chǎn)品經(jīng)理對(duì)業(yè)務(wù)有一定的理解才能夠發(fā)現(xiàn)。如果對(duì)這些場(chǎng)景能做到「感同身受」的話，相信在產(chǎn)品規(guī)劃的過(guò)程中能夠設(shè)計(jì)出更合理、高效的方案；
• 進(jìn)一步的需求：調(diào)研的用戶畢竟不是技術(shù)專家，只是普通的業(yè)務(wù)人員，因此他們沒(méi)有辦法對(duì)其工作提出產(chǎn)生變革的解決方案。因此需要產(chǎn)品經(jīng)理對(duì)問(wèn)題充分理解的前提下，選擇合適的實(shí)現(xiàn)方式以創(chuàng)造出用戶未想到的功能。

在設(shè)計(jì)這款針對(duì)房產(chǎn)中介的 CRM 產(chǎn)品時(shí)，業(yè)務(wù)員反饋他們?cè)诳蛻暨x房的時(shí)候，需要將不同房源的信息發(fā)送給客戶。于是產(chǎn)品經(jīng)理聽完后，在房源列表中，每一條房源的操作按鈕區(qū)域增加了一個(gè)分享按鈕。

滿心歡喜地給到業(yè)務(wù)員時(shí)，業(yè)務(wù)員說(shuō)這功能不實(shí)用，因?yàn)闆](méi)辦法把多個(gè)房源的信息合并在一起發(fā)給客戶。但是產(chǎn)品經(jīng)理認(rèn)為，你可以一條一條發(fā)給客戶呀，所以產(chǎn)品的設(shè)計(jì)還是能滿足業(yè)務(wù)需要的，但業(yè)務(wù)員希望得到的是多個(gè)房源信息合并后，摘出關(guān)鍵信息發(fā)給客戶比對(duì)，而不僅僅是展示每個(gè)房源的信息。

這個(gè)場(chǎng)景就是只發(fā)現(xiàn)意識(shí)到的需求，而沒(méi)有深究以及進(jìn)一步分析的結(jié)果。

實(shí)際上 B 端產(chǎn)品的需求獲取并不難，難的是與用戶交流溝通的過(guò)程。因?yàn)槲覀兊挠脩魞H僅作為一個(gè)使用者，他只是站在自身使用的視角，想讓自己的工作方便一些或是在利益分配上對(duì)自己更有利，很難站在系統(tǒng)規(guī)劃的角度考慮全面整體的東西。

遇到這種情況，最有效的應(yīng)對(duì)策略是需求分析從流程入手，搞清楚業(yè)務(wù)活動(dòng)在平時(shí)是如何開展的，再逐步過(guò)渡到存在什么樣的障礙，有什么困難等等。在這個(gè)過(guò)程中，多問(wèn)幾個(gè)為什么，多思考客戶訴求背后代表的心理狀態(tài)與利益沖突。

所以這一階段，我們主要做的工作是收集針對(duì)業(yè)務(wù)活動(dòng)的問(wèn)題點(diǎn)、需求點(diǎn)。這時(shí)候我們獲取到的是原始的用戶需求。

實(shí)際上，在整個(gè)業(yè)務(wù)分類、需求梳理的大環(huán)節(jié)中，業(yè)務(wù)流程分析、角色與使用場(chǎng)景分析，以及獲取用戶需求都是伴隨著用戶調(diào)研進(jìn)行的。用戶調(diào)研是一個(gè)有計(jì)劃、循序漸進(jìn)的過(guò)程。具體來(lái)說(shuō)，在針對(duì)不同的訪談對(duì)象時(shí)，訪談的要點(diǎn)也不盡相同，具體的要點(diǎn)參考以下表格：

除了用戶訪談和問(wèn)卷調(diào)查以外，有機(jī)會(huì)到業(yè)務(wù)工作中實(shí)際現(xiàn)場(chǎng)觀摩也是一種很好的需求獲取手段，有助于產(chǎn)品經(jīng)理對(duì)業(yè)務(wù)場(chǎng)景建立更加感性的認(rèn)識(shí)。在對(duì)關(guān)鍵任務(wù)理解不清晰、很多東西用文字沒(méi)辦法表述時(shí)，現(xiàn)場(chǎng)觀摩都是一種很好的方式。

到了這一步，我們已經(jīng)收集到足夠多的業(yè)務(wù)信息，供我們進(jìn)行后續(xù)的需求分析工作了。

1. 確定需求細(xì)節(jié)

完善用例

本階段的任務(wù)是對(duì)用例的細(xì)節(jié)進(jìn)行填充。上一階段的用戶故事已經(jīng)說(shuō)明業(yè)務(wù)怎么執(zhí)行，但缺少表達(dá)如何「實(shí)現(xiàn)」的機(jī)制。例如房產(chǎn)交易后對(duì)合同歸檔，有一部分合同可以由業(yè)務(wù)員直接歸檔，有一部分則需要經(jīng)過(guò)部門經(jīng)理審核后才能歸檔。另外歸檔需要什么前置條件，歸檔后會(huì)引發(fā)這項(xiàng)業(yè)務(wù)發(fā)生什么樣的變化，這些都是本階段需要考慮的問(wèn)題。

因此在完善用例階段，我們需要做的事情主要有：

• 將用例與需求相對(duì)應(yīng)；
• 表述用例的事件流；
• 補(bǔ)充用例的前置條件與后置條件；
• 確定用例的規(guī)則與約束條件。

用例與需求相對(duì)應(yīng)

以用例作為需求的最小單位，是按照業(yè)務(wù)流的角度將需求分類管理的方法。在這個(gè)階段，首先我們要做的事情是將用戶調(diào)研階段獲取到的用戶原始需求，整理到相應(yīng)的用例中，以此建立用戶原始需求與軟件需求（用例）之間的映射。

在具體操作時(shí)，我們可以用以下表格管理需求追蹤。前三列描述了用戶原始需求的編號(hào)、描述與提出者，接下來(lái)兩列則是相應(yīng)的用例編號(hào)及用例名稱。這些用戶的原始需求來(lái)源于用戶調(diào)研、用戶提供的需求說(shuō)明以及在使用系統(tǒng)過(guò)程中獲得的反饋。

有這樣一張表，我們對(duì)用戶的需求管理更顯得張弛有度，同時(shí)也更容易發(fā)現(xiàn)需求沖突的地方。

表述事件流

對(duì)于用例而言，最常見的事件流包括 3 種：

• 基本事件流：是對(duì)用例的預(yù)期路徑的描述。是大部分時(shí)間遇到的場(chǎng)景，也是符合用戶預(yù)期與業(yè)務(wù)初衷的核心路徑；
• 拓展事件流：也稱為分支事件流，主要用來(lái)描述用戶的不同選擇以及對(duì)異常情況的表示；
• 子事件流：用于對(duì)事件流中多次重復(fù)的部分進(jìn)行概括，類似代碼中的「循環(huán)結(jié)構(gòu)」。

在買房這個(gè)例子中，按預(yù)定路線雙方完成交易就是基本事件流，雙方對(duì)價(jià)錢的商議過(guò)程就是子事件流，而買賣雙方的交易過(guò)程穿插著比較多的交易情況，屬于拓展事件流。

補(bǔ)充前置條件與后置條件

所謂前置條件是指在用例啟動(dòng)時(shí)，參與者與系統(tǒng)應(yīng)處于什么狀態(tài)。這個(gè)狀態(tài)是系統(tǒng)能夠檢測(cè)并且是有意義的。而后置條件是指在用例結(jié)束時(shí)，系統(tǒng)應(yīng)處于什么狀態(tài)。同樣這個(gè)狀態(tài)也是系統(tǒng)能檢測(cè)到并且有意義的。通過(guò)以下例子加深理解：

客戶有購(gòu)房意向：這不是一個(gè)前置條件，因?yàn)檫@是系統(tǒng)無(wú)法檢測(cè)的；

客戶登錄系統(tǒng)查看房源圖片：這也不是一個(gè)好的前置條件，雖然系統(tǒng)可以檢測(cè)，但是這個(gè)事情所表現(xiàn)出來(lái)的意義不大，對(duì)我們來(lái)說(shuō)沒(méi)有幫助；

審核通過(guò)，完成合同：這是一個(gè)好的后置條件，系統(tǒng)可以檢測(cè)并且事件對(duì)流程有影響。

一般來(lái)說(shuō)，前置條件通常是一種狀態(tài)，后置條件可能是一種狀態(tài)，也可能是一種后續(xù)行為。并非所有的用例都存在前置條件與后置條件。

規(guī)則與設(shè)計(jì)約束

規(guī)則是在實(shí)現(xiàn)階段應(yīng)該考慮的東西，而約束是對(duì)技術(shù)手段起限制作用的各種條件。在這個(gè)階段補(bǔ)充規(guī)則與設(shè)計(jì)約束是我們對(duì)用例整理的最后一件事情。

從需求的角度來(lái)看，用例涉及的規(guī)則大致可以分為：業(yè)務(wù)規(guī)則與數(shù)據(jù)規(guī)則兩類。

• 業(yè)務(wù)規(guī)則：它是指和業(yè)務(wù)邏輯、業(yè)務(wù)流程相關(guān)的規(guī)則。例如業(yè)務(wù)系統(tǒng)中，一個(gè)業(yè)務(wù)員接觸了買方之后，系統(tǒng)不會(huì)把這個(gè)客戶再分給別的業(yè)務(wù)員；業(yè)務(wù)員釋放了某個(gè)客戶之后，其他業(yè)務(wù)員可以聯(lián)系這個(gè)客戶等等；
• 數(shù)據(jù)規(guī)則：它是和業(yè)務(wù)屬性相關(guān)的規(guī)則。例如業(yè)務(wù)員給客戶發(fā)送的營(yíng)銷短信最大長(zhǎng)度是 200 個(gè)漢字；業(yè)務(wù)員的當(dāng)月有效業(yè)績(jī)是當(dāng)月已付款的所有訂單的總金額合計(jì)等等。

而用例的約束則比較簡(jiǎn)單，通常指的是性能指標(biāo)等非功能要求，或是軟硬件、用戶使用環(huán)境以及技術(shù)選擇的限制。這些限制也并非每個(gè)用例都會(huì)有，但關(guān)鍵業(yè)務(wù)活動(dòng)的設(shè)計(jì)約束要充分考慮，才不會(huì)發(fā)生因規(guī)劃產(chǎn)生的設(shè)計(jì)缺陷。

2. 需求整理與分析

需求分析是需求工程中最重要的活動(dòng)之一。需求分析并不是在分析系統(tǒng)如何實(shí)現(xiàn)用戶的需求，而是選擇一種業(yè)務(wù)導(dǎo)向的指引將零散的需求串聯(lián)起來(lái)，形成一個(gè)體系完整、內(nèi)容清晰的框架，為下一階段的產(chǎn)品設(shè)計(jì)工作做準(zhǔn)備。

在這個(gè)階段，我們要做兩件事情：整理需求并消除需求間的矛盾。

整理需求

將用戶需求轉(zhuǎn)化成系統(tǒng)需求后，我們要根據(jù)業(yè)務(wù)流向，整理每一個(gè)環(huán)節(jié)，每一種類型的需求。如下圖所示：

這種結(jié)構(gòu)是以業(yè)務(wù)流程為整理的主線索，也就是按「事」的角度進(jìn)行分解。這種方法對(duì)于工作流系統(tǒng)以及信息管理系統(tǒng)來(lái)說(shuō)都是非常適用的方法。

首先將我們的產(chǎn)品劃分成不同的業(yè)務(wù)板塊，在這個(gè)層面看哪些系統(tǒng)需求是針對(duì)業(yè)務(wù)事件，確保業(yè)務(wù)流程正常進(jìn)行的；哪些系統(tǒng)需求是針對(duì)報(bào)表的要求，確保流轉(zhuǎn)過(guò)程中的數(shù)據(jù)傳遞。

接下來(lái)再往更細(xì)顆粒的維度整理，梳理哪些系統(tǒng)需求是支持業(yè)務(wù)步驟的，基于這些業(yè)務(wù)步驟需要設(shè)計(jì)什么樣的功能點(diǎn)。這樣一來(lái)所有的系統(tǒng)需求都按照清晰的脈絡(luò)，層層遞進(jìn)展現(xiàn)在我們面前。

消除需求間的矛盾

以上整理需求的方式，是按照業(yè)務(wù)流程進(jìn)行整理的。在這個(gè)分析過(guò)程中，因?yàn)槲覀兊男枨髞?lái)自不同的部門不同的崗位，難免會(huì)發(fā)現(xiàn)有些需求是互相矛盾、互相沖突的。因此我們?cè)谡砗蟮牧斜碇行枰獙⑦@些矛盾的需求全部圈出來(lái)，然后快速地找到相關(guān)人員，通過(guò)進(jìn)一步的溝通協(xié)調(diào)來(lái)消除矛盾的需求。

很多時(shí)候，需求沖突的真正原因是使用者與管理者之間的沖突。作為使用者，他的核心訴求是方便高效、省事，最好還能在某些方面獲得一定的利益；作為管理者，他的訴求是流程規(guī)范、過(guò)程可追蹤，杜絕損害公司利益的事情發(fā)生。

例如中介公司的業(yè)務(wù)員，經(jīng)常需要帶客戶去樓盤看房，他們自然希望在考勤方面能夠更彈性，有一些自由度。但是作為管理人員，他們也沒(méi)有辦法盯著業(yè)務(wù)員時(shí)刻在做什么，只能通過(guò)一些定位打卡等手段管理業(yè)務(wù)員，不讓他偷懶。

從這個(gè)例子可以看出來(lái)，不同角色由于崗位不同，核心訴求也不一樣。在發(fā)生沖突的時(shí)候，筆者的建議是以企業(yè)的生產(chǎn)經(jīng)營(yíng)為核心，首先確保經(jīng)營(yíng)活動(dòng)的規(guī)范化、流程化進(jìn)行，在這個(gè)基礎(chǔ)上增加為普通使用者考慮的易用性設(shè)計(jì)與情感化設(shè)計(jì)，讓他們感受到產(chǎn)品不單單是一個(gè)反感排斥的工作系統(tǒng)，而是真正幫助他們提高工作效率的產(chǎn)品。

完成這一步后，才算是將整個(gè)產(chǎn)品的系統(tǒng)需求全部整理出來(lái)。以后每次迭代就是在業(yè)務(wù)需求與用戶需求的基礎(chǔ)上，創(chuàng)建新的系統(tǒng)需求，不斷完善、豐富產(chǎn)品。

系統(tǒng)建設(shè)

終于，我們進(jìn)入到系統(tǒng)建設(shè)環(huán)節(jié)，真正開始設(shè)計(jì)一款產(chǎn)品的形狀了。在這之前，我們先探討一個(gè)問(wèn)題：B 端產(chǎn)品和 C 端產(chǎn)品在產(chǎn)品設(shè)計(jì)上有什么差異性？

筆者認(rèn)為，絕大多數(shù) C 端產(chǎn)品的設(shè)計(jì)邏輯會(huì)把用戶體驗(yàn)與效率放在首位。追求極致的簡(jiǎn)單好用與高效。在整個(gè)產(chǎn)品設(shè)計(jì)上比較側(cè)重用戶的感受，精心打磨頁(yè)面與交互，盡量少讓用戶做選擇，保持產(chǎn)品的易用性與流暢性，都是做 C 端產(chǎn)品設(shè)計(jì)的不二法門。

但是做 B 端產(chǎn)品時(shí)，所有的產(chǎn)品設(shè)計(jì)都是為「流程」服務(wù)的。體驗(yàn)和效率未必是設(shè)計(jì)的重心。很簡(jiǎn)單的一個(gè)例子就能明白，企業(yè)買一款中介 CRM 產(chǎn)品，不是為了讓業(yè)務(wù)員更輕松，做業(yè)務(wù)的時(shí)候更「省事」，而是為了將整個(gè)賣房的流程管理起來(lái)，做標(biāo)準(zhǔn)化的經(jīng)營(yíng)，為經(jīng)營(yíng)決策提供更準(zhǔn)確科學(xué)的決策。B 端產(chǎn)品更多是通過(guò)計(jì)算機(jī)技術(shù)實(shí)現(xiàn)企業(yè)的信息化管理，對(duì)企業(yè)流程進(jìn)行優(yōu)化升級(jí)，從而達(dá)到降本增效的目的。

由此可以看出來(lái)，做 C 端產(chǎn)品更注重對(duì)「人」的理解，要求產(chǎn)品經(jīng)理具備同理心，感知用戶的能力。而做 B 端產(chǎn)品更注重對(duì)「業(yè)務(wù)」的理解，要求產(chǎn)品經(jīng)理具有系統(tǒng)性的邏輯思維，富有理性地對(duì)企業(yè)業(yè)務(wù)進(jìn)行全面梳理與診斷，給出合理有效的解決方案。

在規(guī)劃產(chǎn)品原型的過(guò)程中，產(chǎn)品的信息架構(gòu)設(shè)計(jì)是重要一環(huán)，其中菜單結(jié)構(gòu)設(shè)計(jì)、CRUD 原則與 RBAC 模型的應(yīng)用，可以幫助我們?cè)O(shè)計(jì)出更合理、高效的產(chǎn)品形態(tài)。

1. 菜單結(jié)構(gòu)設(shè)計(jì)

常見的菜單結(jié)構(gòu)設(shè)計(jì)有兩種，以「人/物」為主線，或以「事」為主線。

大部分的通用型 B 端產(chǎn)品由于各行各業(yè)的垂直差異性，無(wú)法做到統(tǒng)一的流程管理，而產(chǎn)品需要滿足盡可能多的行業(yè)，因此只能以「物」為主線劃分菜單結(jié)構(gòu)。例如將 CRM 系統(tǒng)劃分為線索、客戶、聯(lián)系人、公海、商機(jī)、合同等等，都是以「人/物」作為劃分的標(biāo)準(zhǔn)。

這種劃分方式在一定程度上來(lái)說(shuō)是有缺陷的，因?yàn)樵趯?shí)際的業(yè)務(wù)流程中，物與物之間的傳遞有可能交錯(cuò)，例如在房產(chǎn)交易、確權(quán)、歸檔的幾個(gè)環(huán)節(jié)中都涉及到合同的流轉(zhuǎn)，而這種菜單結(jié)構(gòu)沒(méi)有充分體現(xiàn)這種流轉(zhuǎn)的特點(diǎn)，同時(shí)不同崗位的職責(zé)權(quán)限也有可能交錯(cuò)在一起。

而專注于垂直行業(yè)的 B 端產(chǎn)品則往往以業(yè)務(wù)流程的職責(zé)劃分為菜單劃分的標(biāo)準(zhǔn)，也就是以「事」為主線的設(shè)計(jì)方式。這種設(shè)計(jì)方式的好處是可以有效的避免重復(fù)和混亂的現(xiàn)象，對(duì)整個(gè)系統(tǒng)的架構(gòu)都是非常清晰明了的。

CRUD原則

在互聯(lián)網(wǎng)，各類互聯(lián)網(wǎng)書籍都提到過(guò) CRUD 原則，也就是將新增、刪除、查詢與修改等操作合并成一個(gè)管理頁(yè)面。例如一個(gè)訂單管理頁(yè)，包含了新增訂單、刪除訂單、查詢以及修改訂單信息等不同的操作。

但是在很多情況下，一個(gè) ERP 系統(tǒng)中，錄入訂單是由業(yè)務(wù)員錄入的，后續(xù)由銷售人員更新訂單的信息。當(dāng)發(fā)現(xiàn)退款時(shí)，由財(cái)務(wù)或售后人員撤銷訂單。由此可見這些所謂的「管理」操作往往不是由同一個(gè)角色完成的，如果合并在同一個(gè)管理頁(yè)面會(huì)產(chǎn)生很多職責(zé)權(quán)限混亂的問(wèn)題。好在現(xiàn)在越來(lái)越多的產(chǎn)品也意識(shí)到這個(gè)問(wèn)題，在菜單設(shè)計(jì)上盡量避免使用「某某管理」這樣的字眼，而是根據(jù)業(yè)務(wù)場(chǎng)景，更靈活地劃分菜單的范圍。

上面這段話的意思，難道是說(shuō) CRUD 原則是錯(cuò)的？其實(shí)并非如此，只是 CRUD 原則對(duì)于系統(tǒng)創(chuàng)造的東西才適用，例如管理系統(tǒng)用戶、管理數(shù)據(jù)字典、管理權(quán)限這類的東西就適用該原則。對(duì)系統(tǒng)用戶的增刪改查，通常都是由管理員操作的，這個(gè)時(shí)候我們把這些操作都放在同一個(gè)界面就是合理的場(chǎng)景。

RBAC權(quán)限模型

B 端產(chǎn)品的權(quán)限設(shè)計(jì)通常都是適用 RBAC 模型，也就是每個(gè)用戶都要被賦予一個(gè)或多個(gè)系統(tǒng)角色，每個(gè)系統(tǒng)角色都對(duì)應(yīng)一個(gè)明確的權(quán)限集合，包括對(duì)菜單、頁(yè)面元素等資源的訪問(wèn)與操作權(quán)限。建立一個(gè)「用戶 - 角色?- 權(quán)限」之間的對(duì)應(yīng)關(guān)系。

此時(shí)，用戶與角色，角色與權(quán)限都是多對(duì)多關(guān)系，即一個(gè)用戶可以對(duì)應(yīng)多個(gè)角色，一個(gè)角色可以分配給多個(gè)用戶，一個(gè)角色具有多個(gè)權(quán)限。當(dāng)用戶比較多時(shí)，可引入用戶組，既對(duì)用戶分組，將角色與用戶組進(jìn)行關(guān)聯(lián)。

比如某個(gè)銷售部門的員工在系統(tǒng)中是一個(gè)用戶組，當(dāng)新的銷售員加入時(shí)，只需要設(shè)置他所在的用戶組，就會(huì)將這個(gè)部門關(guān)聯(lián)的權(quán)限賦予這位銷售員。設(shè)置用戶組還有一個(gè)好處，當(dāng)這個(gè)部門的權(quán)限發(fā)生變動(dòng)時(shí)，只需要調(diào)整這個(gè)用戶組對(duì)應(yīng)的角色權(quán)限即可，不需要調(diào)整每個(gè)用戶和角色對(duì)應(yīng)的關(guān)系。

以上三點(diǎn)是我們?cè)谧鱿到y(tǒng)建設(shè)時(shí)最關(guān)鍵的核心設(shè)計(jì)點(diǎn)，相信經(jīng)過(guò)以上的思考之后，結(jié)合上一階段整理的系統(tǒng)需求列表，在我們的腦海里已經(jīng)有大致的產(chǎn)品解決方案了。接下來(lái)的我們可以開始畫原型、畫界面，將文字性的想法通過(guò)形象化的方式展現(xiàn)出來(lái)。因原型的設(shè)計(jì)不是本文重點(diǎn)，在此不再贅述。

到這里，相信你已經(jīng)對(duì) B 端產(chǎn)品設(shè)計(jì)的全流程有一個(gè)清晰的思路了。韌哥在《產(chǎn)品經(jīng)理必懂的技術(shù)那點(diǎn)事兒》一書中曾寫道：

產(chǎn)品經(jīng)理必須習(xí)慣與孤獨(dú)為伴，這種孤獨(dú)不是沒(méi)有朋友的孤單感，而是指思考和決策的過(guò)程并不會(huì)有人給你明晰的指引，只能靠自己的獨(dú)立思考和理解給產(chǎn)品賦予生命力，做出關(guān)鍵決策。

本文當(dāng)然也不是一個(gè)教你如何做一款成功的 B 端產(chǎn)品指南，而是希望在你做 B 端產(chǎn)品時(shí)，能夠提供一些設(shè)計(jì)的思路幫助你少犯錯(cuò)，沿著正確的方向思考問(wèn)題。產(chǎn)品路上并不孤獨(dú)，愿你我共勉。

PPT 下載鏈接：https://pan.baidu.com/s/125ZDKdlMctrlYeY87JYowQ? 提取碼: u8na

備用下載鏈接：https://share.weiyun.com/5GD5b4u

歡迎關(guān)注作者的微信公眾號(hào)：「pmakiu」