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

前言

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

調(diào)研前

基礎(chǔ)捕獲

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

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

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

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

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

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

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

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

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

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

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

進(jìn)階捕獲

這一塊因企業(yè)、項目而異，因為各個企業(yè)的營銷玩法不一樣，各個項目的立項方式也有區(qū)別。

整體來說，就是從營銷線和實施線獲取資料。

營銷線的資料包括：

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

實施線的資料包括：

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

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

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

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

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

高階捕獲

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

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

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

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

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

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

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

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

調(diào)研中

整體方法

三字訣——問聽記。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

技術(shù)捕獲

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

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

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

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

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

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

1. 可靠性
2. 可用性（注意體驗）
3. 有效性
4. 可移植性

調(diào)研匯報

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

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

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

需求開發(fā)

需求分析

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

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

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

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

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

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

報表需要考慮：

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

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

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

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

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

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

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

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

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

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

需求規(guī)格說明書

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

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

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

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

補充說明：

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

• 用例圖，訂單的所有用例，如查看查詢、新增、編輯、導(dǎo)入、導(dǎo)出、審核、發(fā)貨、收貨
• 類圖，訂單類的成員名和字段類型乃至長度，以及審批單、發(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é)議