本文以車銷業(yè)務(wù)為例，向我們分享了B端項(xiàng)目需求調(diào)研的前中后期的工作內(nèi)容以及注意要點(diǎn)。

前言

有段時(shí)間整個(gè)產(chǎn)品團(tuán)隊(duì)頻繁支撐SFA項(xiàng)目，但需求調(diào)研普遍存在一些問題，導(dǎo)致PRD質(zhì)量不高。團(tuán)隊(duì)成員基本是內(nèi)部轉(zhuǎn)崗過來的，對(duì)B端需求調(diào)研的方法論多有不足。故結(jié)合過往經(jīng)驗(yàn)，參考《軟件需求開發(fā)最佳實(shí)踐-基于模型驅(qū)動(dòng)的需求開發(fā)過程》一書，以車銷業(yè)務(wù)為例做此分享。

調(diào)研前

基礎(chǔ)捕獲

既然是去項(xiàng)目進(jìn)行調(diào)研，再不濟(jì)也知道甲方客戶名稱。有了客戶名稱，基本能獲取到以下方面的資料：

• 主營(yíng)業(yè)務(wù)，以及所屬行業(yè)
• 在行業(yè)中的地位
• 經(jīng)營(yíng)的產(chǎn)品，以及對(duì)應(yīng)特性
• 資本構(gòu)成
• 組織架構(gòu)（尤其是營(yíng)銷組織）
• 營(yíng)銷渠道

下面以益力多為例，講一下獲取信息的途徑。

通過啟信寶、天眼察、企查查等網(wǎng)站，可以找到益力多的信息。經(jīng)營(yíng)業(yè)務(wù)包括進(jìn)口、乳制品、保健品等。保健品，就可能有溯源的訴求（主要怕偽劣產(chǎn)品吃出人命）。

公司的相關(guān)信息，還可通過官網(wǎng)得到。從官網(wǎng)首頁導(dǎo)航欄中，很容易找到“乳酸局巨頭”這個(gè)信息。

另外，官網(wǎng)顯示的產(chǎn)品信息中只有低糖（藍(lán)色裝）和正常（紅色裝）兩種。典型的大單品模式，一如紅牛定義了?；撬峁δ苄燥嬃?。益力多從港臺(tái)進(jìn)駐，定義了大陸的乳酸菌飲料。

股權(quán)穿透圖顯示株式會(huì)社Yakult本社控股50%，香港益力多控股35%，養(yǎng)樂多10%?？雌饋硭坪跏侨召Y+港資+中資，但深追一下發(fā)現(xiàn)不那么簡(jiǎn)單。

追溯歷史，Yakult是日本企業(yè)，先后進(jìn)入港臺(tái)。香港是粵語音譯為益力多，臺(tái)灣則普通話音譯為養(yǎng)樂多。2001年左右從香港進(jìn)入華南地區(qū)，成立廣州益力多，覆蓋華南及海南。2年后在上海設(shè)立養(yǎng)樂多公司，覆蓋大陸其他地區(qū)。所以，日資無誤，控股占比相當(dāng)高。

日資企業(yè)的特點(diǎn)不用說了，什么部長(zhǎng)、課（科）長(zhǎng)之類的崗位是必備了。然后日資注重上下級(jí)關(guān)系，嚴(yán)格的業(yè)務(wù)流程&一堆審批流是必須的。

組織架構(gòu)是比較難從網(wǎng)絡(luò)上獲取到，基本上是用“公司名稱+組織架構(gòu)”在百度文庫中查找。益力多沒有，康師傅這類倒是有。

營(yíng)銷渠道也是非常難獲取到的，用“公司名稱+渠道”可以嘗試在百度中查找。益力多找不到，同為乳制品的蒙牛有。

進(jìn)階捕獲

這一塊因企業(yè)、項(xiàng)目而異，因?yàn)楦鱾€(gè)企業(yè)的營(yíng)銷玩法不一樣，各個(gè)項(xiàng)目的立項(xiàng)方式也有區(qū)別。

整體來說，就是從營(yíng)銷線和實(shí)施線獲取資料。

營(yíng)銷線的資料包括：

• 售前報(bào)告
• 合同（細(xì)化拆解為部署方式、三方對(duì)接系統(tǒng)和SOW，但部分合同SOW幾乎等于沒有）

實(shí)施線的資料包括：

• 計(jì)劃交付版本（Base的標(biāo)準(zhǔn)產(chǎn)品版本）
• 項(xiàng)目計(jì)劃（細(xì)化拆解整體計(jì)劃排期和調(diào)研計(jì)劃）
• 負(fù)責(zé)模塊（極少單兵作戰(zhàn)，需要分工合作）
• 需求規(guī)范（交付物以及對(duì)應(yīng)規(guī)范，根據(jù)項(xiàng)目等級(jí)有個(gè)內(nèi)部規(guī)范。調(diào)研過程中，再和甲方確認(rèn)）

這些資料的捕獲，就靠自己發(fā)揮才能了。部分信息很敏感（如合同金額），企業(yè)內(nèi)部不讓隨意傳閱，可以要求僅截取部分信息。實(shí)在沒有辦法，可以嘗試讓上級(jí)協(xié)助。

以售前報(bào)告為例，可能從該項(xiàng)目的銷售、售前或者PMO（部分項(xiàng)目可能尚未走完立項(xiàng)流程）那邊獲取。一般售前報(bào)告會(huì)有Base產(chǎn)品模塊的客戶訴求描述，并且會(huì)突出某部分和現(xiàn)有產(chǎn)品有差距，這就是我們要的關(guān)鍵信息。

再以調(diào)研計(jì)劃為例，可能從銷售、售前和項(xiàng)目經(jīng)理處獲取。但是初步的調(diào)研計(jì)劃很粗，通常都是項(xiàng)目經(jīng)理。一方面調(diào)研完成時(shí)間根本不可能（Deadline倒排法萬歲），另一方面調(diào)研的順序等都不符合你的做事方式。建議立刻和項(xiàng)目經(jīng)理溝通，看看能否調(diào)整（只能調(diào)調(diào)研先后順序，deadline是紅線）。

另外，根據(jù)調(diào)研計(jì)劃和SOW，提前整理出調(diào)研準(zhǔn)備物，讓甲方項(xiàng)目團(tuán)隊(duì)提前啟動(dòng)，參與部分調(diào)研工作。舉個(gè)例子，需要甲方先提供好營(yíng)銷組織架構(gòu)、角色清單、主數(shù)據(jù)相關(guān)字段&審批、接口文檔、關(guān)鍵表單信息和報(bào)表樣式。

高階捕獲

準(zhǔn)備一份調(diào)研問卷（Base交付版本產(chǎn)品能力），讓甲方先進(jìn)行填寫，如“考勤是否包含內(nèi)勤人員的管理”、“內(nèi)勤人員打卡，是否要基于定位進(jìn)行檢查，如距離辦公樓100米內(nèi)”。

準(zhǔn)備一份計(jì)劃交付版本的產(chǎn)品功能清單，項(xiàng)目的功能清單將基于這份，進(jìn)行裁剪和新增。

充分了解產(chǎn)品的內(nèi)部邏輯，特別是牽一發(fā)而動(dòng)全身的主數(shù)據(jù)關(guān)聯(lián)。舉個(gè)例子，終端的某個(gè)字段，標(biāo)準(zhǔn)產(chǎn)品里面是必填非空的。但這個(gè)項(xiàng)目不需要，那么這個(gè)字段不能被刪除的，要給個(gè)默認(rèn)值才能正常往下跑，并且后續(xù)功能都會(huì)受到影響（頁面都要隱藏掉這個(gè)字段）。

充分了解PaaS能力（無PaaS的就多儲(chǔ)備點(diǎn)技術(shù)吧），能衡量改動(dòng)的代價(jià)。客戶提出訴求（一般已經(jīng)是具體的UI、UE層面），先判斷需求是什么。為達(dá)到目標(biāo)，是否有更低成本的方式。又或者，是否有更通用的方式，為后續(xù)該功能點(diǎn)產(chǎn)品化做準(zhǔn)備。

最后，是對(duì)競(jìng)品進(jìn)行捕獲?，F(xiàn)有項(xiàng)目基本是兩種：

1. 替換已有系統(tǒng)；
2. 新上系統(tǒng)。

一般1的話，能提前拿到UAT環(huán)境，進(jìn)去看看能知己知彼。2的話，大部分項(xiàng)目公開招標(biāo)。招標(biāo)過程中基本試用或POC過，客戶一定是想要最優(yōu)秀的體驗(yàn)。所以會(huì)存在某個(gè)功能對(duì)方有，我們也要。又或者某個(gè)功能別人的好用，你改一改這種。如果能借機(jī)能拿到競(jìng)品的環(huán)境，就是很好的競(jìng)品分析機(jī)會(huì)，也能提前準(zhǔn)備。

舉個(gè)例子，以下是隨便找的車銷解決方案，可以看出大體流程和業(yè)務(wù)支撐能力。

調(diào)研中

整體方法

三字訣——問聽記。

剛接觸調(diào)研，可能覺得記是最困難的。一般帶新人，也是讓他從記開始。客戶講了很多，到底記什么?？蛻糁v的很快，記不過來等等。建議開始調(diào)研的時(shí)候帶上紙筆，這種時(shí)候?qū)懽直确炊赡鼙却蜃挚?。然后可以開啟錄音，記不清的（先記錄個(gè)時(shí)間）可以回去再聽。

經(jīng)歷個(gè)一兩次，會(huì)知道問是最困難的。調(diào)研的過程，基本就是一問一答，基于已有的知識(shí)和聽到甲方的回答進(jìn)行提問。整體的節(jié)奏被提問人員控制，只有自己感覺獲取足夠多的信息，能將業(yè)務(wù)流程串聯(lián)起來，足夠輸出需求規(guī)格，才會(huì)停止發(fā)問。建議在問完一個(gè)大的問題后，提出歸納類問題“那我說下我目前關(guān)于X的理解，看看對(duì)不對(duì)”。這樣才能確保你的信息是足夠的，且甲乙雙方的認(rèn)知是統(tǒng)一的。

這里要特別強(qiáng)調(diào)下——少一點(diǎn)套路。B端調(diào)研往往，過于期望“引導(dǎo)”客戶。無論你在這行混了多少年，奮斗在企業(yè)營(yíng)銷一線的才是專家。即便同行業(yè)規(guī)模類似的企業(yè)，渠道的模式和具體的玩法上都會(huì)有差異。所以不要嘗試從業(yè)務(wù)合理性上去否決訴求，最多只能是技術(shù)代價(jià)比較高（也有先有技術(shù)無法實(shí)現(xiàn)的，請(qǐng)直接否決掉）。能做的引導(dǎo)，是保證實(shí)現(xiàn)目標(biāo)的前提下，往現(xiàn)有產(chǎn)品靠攏，選擇簡(jiǎn)單的實(shí)現(xiàn)方式。

總體捕獲的方法，是5W1H分析法。這個(gè)是很成熟的方法不做展開，簡(jiǎn)介如下：

需求調(diào)研過程中，往往會(huì)出現(xiàn)甲方問諸如“客戶列表頁面，投放冰柜的要有標(biāo)簽或Icon區(qū)分出來”這種問題。這其實(shí)是跨階段了，需求調(diào)研階段要解決的是業(yè)務(wù)是什么，為什么這么做，怎么協(xié)作完成。怎么設(shè)計(jì)UI頁面，那是后面原型驗(yàn)證&解決方案階段的事情。遇到這種情況，調(diào)研人員不能簡(jiǎn)單考慮可行性，要先問自己“為什么要區(qū)分，不區(qū)分有什么影響嗎？為什么在這里區(qū)分，是不是可以在其他地方區(qū)分？”。如果自己無法回答，要問清楚為止，再給出自己的方案進(jìn)行協(xié)商。如果可以回答，倒是可以簡(jiǎn)單的說“OK，這個(gè)我們到時(shí)候會(huì)有的”。

業(yè)務(wù)捕獲

業(yè)務(wù)捕獲分為三塊，分別是組織架構(gòu)、業(yè)務(wù)架構(gòu)和業(yè)務(wù)實(shí)務(wù)。這里面有非常繁雜的邏輯，就列一些要點(diǎn)大綱，不做展開。

先講組織架構(gòu)，這個(gè)基本上最核心的。而絕大部分人員腦海中，組織結(jié)構(gòu)圖就是一棵樹。導(dǎo)致甲方給的資料是這樣，乙方提供的系統(tǒng)也是如此。

實(shí)際在營(yíng)銷CRM系統(tǒng)中，至少要被拆分為兩棵樹。一顆是企業(yè)的機(jī)構(gòu)樹，企業(yè)下面分了多少個(gè)部門。

另一顆是各部門的樹，繼續(xù)分拆。這樣能實(shí)現(xiàn)，財(cái)務(wù)部老總看到所有營(yíng)銷部門的銷售數(shù)據(jù)，財(cái)務(wù)部某個(gè)財(cái)務(wù)主管看到營(yíng)銷部南方戰(zhàn)區(qū)的銷售數(shù)據(jù)。組織架構(gòu)基本和權(quán)限設(shè)計(jì)綁定，是CRM系統(tǒng)的基石，要仔細(xì)考慮。

然后是業(yè)務(wù)架構(gòu)，細(xì)分為部門業(yè)務(wù)和崗位設(shè)置。關(guān)于部門業(yè)務(wù)，需要注意以下幾點(diǎn)：

1. 哪些部門和項(xiàng)目相關(guān)
2. 這些部門各自分管哪一塊，怎么考核
3. 對(duì)照的職責(zé)是否都在系統(tǒng)上落實(shí)，工作流全部跑通
4. 了解推力和阻力，盡量讓每個(gè)部門都有所獲益
5. 各組織節(jié)點(diǎn)，部門設(shè)置是否一致?；蛘哒w職責(zé)是否一致，只是有所合并拆分（最怕遺漏了某個(gè)部門，而且這個(gè)部分流程全部特殊）

關(guān)于崗位設(shè)置，從下述的幾個(gè)方面提問：

1. 崗位的大概目標(biāo)，考核的大概方法（KPI）
2. 崗位間的協(xié)作和上下級(jí)關(guān)系
3. 哪些崗位需要對(duì)外（區(qū)分內(nèi)外勤人員）
4. 哪些崗位會(huì)啟動(dòng)新流程
5. 各層次崗位是否能統(tǒng)一
6. 是否出現(xiàn)一人多崗的情況（業(yè)務(wù)人員兼主管是很常見的）
7. 是否已有內(nèi)部系統(tǒng)編碼，領(lǐng)導(dǎo)是否要顯示最前面

這里面，強(qiáng)調(diào)下崗位的問題。如果一人多崗，會(huì)影響整體系統(tǒng)的設(shè)計(jì)，包括權(quán)限那塊。

技術(shù)捕獲

技術(shù)捕獲，主要是技術(shù)層面的訴求，也存在很大的風(fēng)險(xiǎn)。

遺留系統(tǒng)方面，注意以下三點(diǎn)：

1. 是否并存，并存到何時(shí)，職責(zé)切分
2. 能否替代，替代節(jié)奏和方案
3. 數(shù)據(jù)能否遷移，遷移方案

外部系統(tǒng)方面，注意以下4點(diǎn)：

1. 是否并存
2. 能否替代
3. 接口
4. 數(shù)據(jù)

剩下的是一些非功能性需求，一般有：

1. 可靠性
2. 可用性（注意體驗(yàn)）
3. 有效性
4. 可移植性

調(diào)研匯報(bào)

調(diào)研節(jié)奏普遍較快，密集的1-2周。調(diào)研人員每天晚上就是寫會(huì)議紀(jì)要以及跟進(jìn)問題，很少時(shí)間進(jìn)行需求設(shè)計(jì)。再加上項(xiàng)目人員一般設(shè)計(jì)能力有限（大部分項(xiàng)目經(jīng)理是axure略懂而已），需要請(qǐng)求總部資源，調(diào)研結(jié)束后一般就回總部。然后1-2周進(jìn)行需求設(shè)計(jì)輸出原型，項(xiàng)目經(jīng)理配合產(chǎn)品出解決方案。

但是這個(gè)階段有個(gè)空窗期，且搜集信息未得到確認(rèn)。最好聯(lián)系甲方項(xiàng)目經(jīng)理，組織部分干系人，進(jìn)行需求調(diào)研匯報(bào)。匯報(bào)的內(nèi)容主要包含：

• 組織架構(gòu)圖
• 分部門的崗責(zé)清單（Excel）
• 重點(diǎn)業(yè)務(wù)流程&審批流程梳理（Visio）
• 核心業(yè)務(wù)原型圖（axure）

需求開發(fā)

需求分析

需求分析的過程，大部分是客戶無感知的，只能體現(xiàn)在最終的輸出物中。

我個(gè)人認(rèn)為主要分為產(chǎn)品（含PaaS）、業(yè)務(wù)和報(bào)表三塊。

產(chǎn)品需要考慮：

• 現(xiàn)有的PaaS配置能力
• 標(biāo)準(zhǔn)產(chǎn)品邏輯（標(biāo)準(zhǔn)產(chǎn)品已有能力要補(bǔ)充到需求規(guī)格中）
• 公共需求的抽象（分頁、導(dǎo)入導(dǎo)出等）

業(yè)務(wù)需要考慮：

• 流程和分支節(jié)點(diǎn)
• 事件觸發(fā)（時(shí)間or操作）
• 特殊字段維護(hù)（如訂單類型，是通用字典維護(hù)，還是專用頁面維護(hù)，或者寫入數(shù)據(jù)庫不提供UI界面維護(hù)，甚至直接代碼寫死）

報(bào)表需要考慮：

• 周期（日?qǐng)?bào)、周報(bào)、月報(bào)）
• 樣式（動(dòng)態(tài)列頭？）
• 明細(xì)流水
• 統(tǒng)計(jì)抽取
• 歷史數(shù)據(jù)處理
• 性能

在需求分析過程中，有很重要的一個(gè)點(diǎn)，就是給需求排優(yōu)先級(jí)，嘗試切分部分需求。這個(gè)在立項(xiàng)時(shí)候甲乙雙方就有約定，但調(diào)研過程往往有變數(shù)。所以需要基于調(diào)研情況，重新排優(yōu)先級(jí)，切分階段。

一般都會(huì)分成兩期上，一期先上某個(gè)渠道，搭建好基礎(chǔ)。需求的優(yōu)先級(jí)，基本上對(duì)內(nèi)不對(duì)外。即便一期的內(nèi)容，乙方內(nèi)部也是要排優(yōu)先級(jí)的。每一期的功能清單，都不包含優(yōu)先級(jí)。最終計(jì)劃怎么排，哪些功能可以如期上，乙方內(nèi)部要心里有數(shù)。

而功能清單是全量的，一般附帶在需求規(guī)格中。但是會(huì)加上標(biāo)注，區(qū)分每一期的內(nèi)容。這個(gè)功能清單基本是頁面級(jí)別的，顆粒度比較粗。

業(yè)務(wù)解決方案

售前階段已有解決方案，是比較靠近標(biāo)準(zhǔn)產(chǎn)品和行業(yè)的。而業(yè)務(wù)解決方案則是落地，貼近企業(yè)實(shí)務(wù)?；旧?，是調(diào)研匯報(bào)內(nèi)容的總結(jié)和升華。

部分項(xiàng)目中，這個(gè)由項(xiàng)目經(jīng)理編寫，產(chǎn)品做輔助支撐。產(chǎn)品需要提供各個(gè)業(yè)務(wù)的流程圖和設(shè)計(jì)原型，匹配業(yè)務(wù)訴求。

另外部分重點(diǎn)項(xiàng)目，這個(gè)由產(chǎn)品獨(dú)立解決。這種方案有點(diǎn)偏咨詢，除了本次調(diào)研的業(yè)務(wù)還涉及其他的相關(guān)系統(tǒng)。要基于行業(yè)營(yíng)銷信息化的認(rèn)知，去構(gòu)建大營(yíng)銷系統(tǒng)的藍(lán)圖。所以什么AI、數(shù)據(jù)中臺(tái)，統(tǒng)統(tǒng)都上。

原型驗(yàn)證基本上是和業(yè)務(wù)解決方案同時(shí)開始的，業(yè)務(wù)解決方案中包含重點(diǎn)業(yè)務(wù)的原型圖。一旦業(yè)務(wù)解決方案得到認(rèn)可，就開始細(xì)致的原型驗(yàn)證階段。這個(gè)階段客戶會(huì)開始看UE，原型的改動(dòng)非常多。

舉個(gè)例子，B端是非常喜歡單據(jù)式布局的。一方面是使用習(xí)慣，另一方面是單據(jù)布局直觀緊湊。尤其是APP端，經(jīng)常出現(xiàn)客戶選擇表格布局替代卡片布局的情況。

需求規(guī)格說明書

CMMI的定義中，交付物包含用戶需求規(guī)格說明書和產(chǎn)品需求規(guī)格說明書。實(shí)際項(xiàng)目中的需求規(guī)格說明書，基本上是用戶需求規(guī)格說明書。這是常態(tài)，只有基于業(yè)務(wù)的描述才能和甲方進(jìn)行確認(rèn)。但很多研發(fā)是沒有業(yè)務(wù)背景的，看這份用戶需求很難直接進(jìn)行概要設(shè)計(jì)?；诔杀究紤]，部分細(xì)節(jié)會(huì)一并在這份用戶需求規(guī)格上。

所以，我們看到的項(xiàng)目的需求規(guī)格，大部分時(shí)候是四不像的大雜燴。一般包含：用戶需求規(guī)格說明書+字段細(xì)分說明（部分會(huì)省略）+接口說明+狀態(tài)流程說明（審批流、訂單業(yè)務(wù)流等）。卻又缺少了關(guān)鍵的需求建模信息（主要是領(lǐng)域建模），研發(fā)要頻繁的找產(chǎn)品問業(yè)務(wù)，才能進(jìn)行概要設(shè)計(jì)。

項(xiàng)目的需求規(guī)格，基本上是和原型同步啟動(dòng)的。但我個(gè)人建議是原型驗(yàn)證后，再貼原型圖。最好文檔基本確認(rèn)完成，再貼原型圖。期間原型圖可以生成html打包，郵件給甲方查閱。不這么做，就是以下的情況：

1. 以會(huì)議紀(jì)要的形式記錄改動(dòng)點(diǎn)，晚上回去后要先原型。原型改好要截圖，貼到PRD。但經(jīng)常出現(xiàn)，原型圖和PRD字段不匹配。
2. 以屏幕擴(kuò)展的方式投屏，客戶要修改的，現(xiàn)場(chǎng)標(biāo)記或者改好。回去匆忙改原型，準(zhǔn)備后面的原型驗(yàn)證。后面再補(bǔ)PRD，很容易造成遺漏（因?yàn)槭敲芗脑万?yàn)證，這期間客戶不看PRD，導(dǎo)致PRD和原型脫節(jié)）。
3. 原型驗(yàn)證完成，開始評(píng)審PRD。開啟審閱+批注后，打開和保存文檔不是一般的卡（4G內(nèi)存還能怎樣）

補(bǔ)充說明：

產(chǎn)品需求規(guī)格中，需求建模主要包含用例圖（內(nèi)部WBS拆解夠細(xì)，可不出）、類圖（可簡(jiǎn)化為ER圖）、序列圖（可簡(jiǎn)化為活動(dòng)圖）、狀態(tài)圖。以訂單領(lǐng)域?yàn)槔?/p>

• 用例圖，訂單的所有用例，如查看查詢、新增、編輯、導(dǎo)入、導(dǎo)出、審核、發(fā)貨、收貨
• 類圖，訂單類的成員名和字段類型乃至長(zhǎng)度，以及審批單、發(fā)貨單、送貨單、收貨單等附屬單據(jù)信息。
• 序列圖，訂單的全流轉(zhuǎn)過程。
• 狀態(tài)圖，訂單的先后狀態(tài)和觸發(fā)狀態(tài)變更的操作

PS：將近一年前的PPT，拿出來分享。從輸出倒逼輸入，真的是很痛苦，各位將就下。

作者：道·術(shù) ，郵箱：olivercan.wunban@foxmail.com

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

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