本文以車銷業務為例，向我們分享了B端項目需求調研的前中后期的工作內容以及注意要點。

前言

有段時間整個產品團隊頻繁支撐SFA項目，但需求調研普遍存在一些問題，導致PRD質量不高。團隊成員基本是內部轉崗過來的，對B端需求調研的方法論多有不足。故結合過往經驗，參考《軟件需求開發最佳實踐-基于模型驅動的需求開發過程》一書，以車銷業務為例做此分享。

調研前

基礎捕獲

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

• 主營業務，以及所屬行業
• 在行業中的地位
• 經營的產品，以及對應特性
• 資本構成
• 組織架構（尤其是營銷組織）
• 營銷渠道

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

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

公司的相關信息，還可通過官網得到。從官網首頁導航欄中，很容易找到“乳酸局巨頭”這個信息。

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

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

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

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

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

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

進階捕獲

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

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

營銷線的資料包括：

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

實施線的資料包括：

• 計劃交付版本（Base的標準產品版本）
• 項目計劃（細化拆解整體計劃排期和調研計劃）
• 負責模塊（極少單兵作戰，需要分工合作）
• 需求規范（交付物以及對應規范，根據項目等級有個內部規范。調研過程中，再和甲方確認）

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

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

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

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

高階捕獲

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

準備一份計劃交付版本的產品功能清單，項目的功能清單將基于這份，進行裁剪和新增。

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

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

最后，是對競品進行捕獲?，F有項目基本是兩種：

1. 替換已有系統；
2. 新上系統。

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

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

調研中

整體方法

三字訣——問聽記。

剛接觸調研，可能覺得記是最困難的。一般帶新人，也是讓他從記開始?？蛻糁v了很多，到底記什么?？蛻糁v的很快，記不過來等等。建議開始調研的時候帶上紙筆，這種時候寫字比反而可能比打字快。然后可以開啟錄音，記不清的（先記錄個時間）可以回去再聽。

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

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

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

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

業務捕獲

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

先講組織架構，這個基本上最核心的。而絕大部分人員腦海中，組織結構圖就是一棵樹。導致甲方給的資料是這樣，乙方提供的系統也是如此。

實際在營銷CRM系統中，至少要被拆分為兩棵樹。一顆是企業的機構樹，企業下面分了多少個部門。

另一顆是各部門的樹，繼續分拆。這樣能實現，財務部老總看到所有營銷部門的銷售數據，財務部某個財務主管看到營銷部南方戰區的銷售數據。組織架構基本和權限設計綁定，是CRM系統的基石，要仔細考慮。

然后是業務架構，細分為部門業務和崗位設置。關于部門業務，需要注意以下幾點：

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

關于崗位設置，從下述的幾個方面提問：

1. 崗位的大概目標，考核的大概方法（KPI）
2. 崗位間的協作和上下級關系
3. 哪些崗位需要對外（區分內外勤人員）
4. 哪些崗位會啟動新流程
5. 各層次崗位是否能統一
6. 是否出現一人多崗的情況（業務人員兼主管是很常見的）
7. 是否已有內部系統編碼，領導是否要顯示最前面

這里面，強調下崗位的問題。如果一人多崗，會影響整體系統的設計，包括權限那塊。

技術捕獲

技術捕獲，主要是技術層面的訴求，也存在很大的風險。

遺留系統方面，注意以下三點：

1. 是否并存，并存到何時，職責切分
2. 能否替代，替代節奏和方案
3. 數據能否遷移，遷移方案

外部系統方面，注意以下4點：

1. 是否并存
2. 能否替代
3. 接口
4. 數據

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

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

調研匯報

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

但是這個階段有個空窗期，且搜集信息未得到確認。最好聯系甲方項目經理，組織部分干系人，進行需求調研匯報。匯報的內容主要包含：

• 組織架構圖
• 分部門的崗責清單（Excel）
• 重點業務流程&審批流程梳理（Visio）
• 核心業務原型圖（axure）

需求開發

需求分析

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

我個人認為主要分為產品（含PaaS）、業務和報表三塊。

產品需要考慮：

• 現有的PaaS配置能力
• 標準產品邏輯（標準產品已有能力要補充到需求規格中）
• 公共需求的抽象（分頁、導入導出等）

業務需要考慮：

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

報表需要考慮：

• 周期（日報、周報、月報）
• 樣式（動態列頭？）
• 明細流水
• 統計抽取
• 歷史數據處理
• 性能

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

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

而功能清單是全量的，一般附帶在需求規格中。但是會加上標注，區分每一期的內容。這個功能清單基本是頁面級別的，顆粒度比較粗。

業務解決方案

售前階段已有解決方案，是比較靠近標準產品和行業的。而業務解決方案則是落地，貼近企業實務?；旧?，是調研匯報內容的總結和升華。

部分項目中，這個由項目經理編寫，產品做輔助支撐。產品需要提供各個業務的流程圖和設計原型，匹配業務訴求。

另外部分重點項目，這個由產品獨立解決。這種方案有點偏咨詢，除了本次調研的業務還涉及其他的相關系統。要基于行業營銷信息化的認知，去構建大營銷系統的藍圖。所以什么AI、數據中臺，統統都上。

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

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

需求規格說明書

CMMI的定義中，交付物包含用戶需求規格說明書和產品需求規格說明書。實際項目中的需求規格說明書，基本上是用戶需求規格說明書。這是常態，只有基于業務的描述才能和甲方進行確認。但很多研發是沒有業務背景的，看這份用戶需求很難直接進行概要設計?；诔杀究紤]，部分細節會一并在這份用戶需求規格上。

所以，我們看到的項目的需求規格，大部分時候是四不像的大雜燴。一般包含：用戶需求規格說明書+字段細分說明（部分會省略）+接口說明+狀態流程說明（審批流、訂單業務流等）。卻又缺少了關鍵的需求建模信息（主要是領域建模），研發要頻繁的找產品問業務，才能進行概要設計。

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

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

補充說明：

產品需求規格中，需求建模主要包含用例圖（內部WBS拆解夠細，可不出）、類圖（可簡化為ER圖）、序列圖（可簡化為活動圖）、狀態圖。以訂單領域為例：

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

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

作者：道·術 ，郵箱：olivercan.wunban@foxmail.com

本文由 @道·術 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash ，基于 CC0 協議