本文以車銷業務為例，向我們分享了B端項目需求調研的前中後期的工作內容以及注意要點。
有段時間整個產品團隊頻繁支撐SFA項目，但需求調研普遍存在一些問題，導致PRD質量不高。團隊成員基本是內部轉崗過來的，對B端需求調研的方法論多有不足。故結合過往經驗，參考《軟體需求開發最佳實踐-基於模型驅動的需求開發過程》一書，以車銷業務為例做此分享。
既然是去項目進行調研，再不濟也知道甲方客戶名稱。有了客戶名稱，基本能獲取到以下方面的資料：
下面以益力多為例，講一下獲取信息的途徑。
通過啟信寶、天眼察、企查查等網站，可以找到益力多的信息。經營業務包括進口、乳製品、保健品等。保健品，就可能有溯源的訴求（主要怕偽劣產品吃出人命）。
公司的相關信息，還可通過官網得到。從官網首頁導航欄中，很容易找到「乳酸局巨頭」這個信息。
另外，官網顯示的產品信息中只有低糖（藍色裝）和正常（紅色裝）兩種。典型的大單品模式，一如紅牛定義了牛磺酸功能性飲料。益力多從港臺進駐，定義了大陸的乳酸菌飲料。
股權穿透圖顯示株式會社Yakult本社控股50%，香港益力多控股35%，養樂多10%。看起來似乎是日資+港資+中資，但深追一下發現不那麼簡單。
追溯歷史，Yakult是日本企業，先後進入港臺。香港是粵語音譯為益力多，臺灣則普通話音譯為養樂多。2001年左右從香港進入華南地區，成立廣州益力多，覆蓋華南及海南。2年後在上海設立養樂多公司，覆蓋大陸其他地區。所以，日資無誤，控股佔比相當高。
日資企業的特點不用說了，什麼部長、課（科）長之類的崗位是必備了。然後日資注重上下級關係，嚴格的業務流程&一堆審批流是必須的。
組織架構是比較難從網絡上獲取到，基本上是用「公司名稱+組織架構」在百度文庫中查找。益力多沒有，康師傅這類倒是有。
營銷渠道也是非常難獲取到的，用「公司名稱+渠道」可以嘗試在百度中查找。益力多找不到，同為乳製品的蒙牛有。
這一塊因企業、項目而異，因為各個企業的營銷玩法不一樣，各個項目的立項方式也有區別。
整體來說，就是從營銷線和實施線獲取資料。
營銷線的資料包括：
實施線的資料包括：
這些資料的捕獲，就靠自己發揮才能了。部分信息很敏感（如合同金額），企業內部不讓隨意傳閱，可以要求僅截取部分信息。實在沒有辦法，可以嘗試讓上級協助。
以售前報告為例，可能從該項目的銷售、售前或者PMO（部分項目可能尚未走完立項流程）那邊獲取。一般售前報告會有Base產品模塊的客戶訴求描述，並且會突出某部分和現有產品有差距，這就是我們要的關鍵信息。
再以調研計劃為例，可能從銷售、售前和項目經理處獲取。但是初步的調研計劃很粗，通常都是項目經理。一方面調研完成時間根本不可能（Deadline倒排法萬歲），另一方面調研的順序等都不符合你的做事方式。建議立刻和項目經理溝通，看看能否調整（只能調調研先後順序，deadline是紅線）。
另外，根據調研計劃和SOW，提前整理出調研準備物，讓甲方項目團隊提前啟動，參與部分調研工作。舉個例子，需要甲方先提供好營銷組織架構、角色清單、主數據相關欄位&審批、接口文檔、關鍵表單信息和報表樣式。
準備一份調研問卷（Base交付版本產品能力），讓甲方先進行填寫，如「考勤是否包含內勤人員的管理」、「內勤人員打卡，是否要基於定位進行檢查，如距離辦公樓100米內」。
準備一份計劃交付版本的產品功能清單，項目的功能清單將基於這份，進行裁剪和新增。
充分了解產品的內部邏輯，特別是牽一髮而動全身的主數據關聯。舉個例子，終端的某個欄位，標準產品裡面是必填非空的。但這個項目不需要，那麼這個欄位不能被刪除的，要給個默認值才能正常往下跑，並且後續功能都會受到影響（頁面都要隱藏掉這個欄位）。
充分了解PaaS能力（無PaaS的就多儲備點技術吧），能衡量改動的代價。客戶提出訴求（一般已經是具體的UI、UE層面），先判斷需求是什麼。為達到目標，是否有更低成本的方式。又或者，是否有更通用的方式，為後續該功能點產品化做準備。
最後，是對競品進行捕獲。現有項目基本是兩種：
一般1的話，能提前拿到UAT環境，進去看看能知己知彼。2的話，大部分項目公開招標。招標過程中基本試用或POC過，客戶一定是想要最優秀的體驗。所以會存在某個功能對方有，我們也要。又或者某個功能別人的好用，你改一改這種。如果能藉機能拿到競品的環境，就是很好的競品分析機會，也能提前準備。
舉個例子，以下是隨便找的車銷解決方案，可以看出大體流程和業務支撐能力。
三字訣——問聽記。
剛接觸調研，可能覺得記是最困難的。一般帶新人，也是讓他從記開始。客戶講了很多，到底記什麼。客戶講的很快，記不過來等等。建議開始調研的時候帶上紙筆，這種時候寫字比反而可能比打字快。然後可以開啟錄音，記不清的（先記錄個時間）可以回去再聽。
經歷個一兩次，會知道問是最困難的。調研的過程，基本就是一問一答，基於已有的知識和聽到甲方的回答進行提問。整體的節奏被提問人員控制，只有自己感覺獲取足夠多的信息，能將業務流程串聯起來，足夠輸出需求規格，才會停止發問。建議在問完一個大的問題後，提出歸納類問題「那我說下我目前關於X的理解，看看對不對」。這樣才能確保你的信息是足夠的，且甲乙雙方的認知是統一的。
這裡要特別強調下——少一點套路。B端調研往往，過於期望「引導」客戶。無論你在這行混了多少年，奮鬥在企業營銷一線的才是專家。即便同行業規模類似的企業，渠道的模式和具體的玩法上都會有差異。所以不要嘗試從業務合理性上去否決訴求，最多只能是技術代價比較高（也有先有技術無法實現的，請直接否決掉）。能做的引導，是保證實現目標的前提下，往現有產品靠攏，選擇簡單的實現方式。
總體捕獲的方法，是5W1H分析法。這個是很成熟的方法不做展開，簡介如下：
需求調研過程中，往往會出現甲方問諸如「客戶列表頁面，投放冰櫃的要有標籤或Icon區分出來」這種問題。這其實是跨階段了，需求調研階段要解決的是業務是什麼，為什麼這麼做，怎麼協作完成。怎麼設計UI頁面，那是後面原型驗證&解決方案階段的事情。遇到這種情況，調研人員不能簡單考慮可行性，要先問自己「為什麼要區分，不區分有什麼影響嗎？為什麼在這裡區分，是不是可以在其他地方區分？」。如果自己無法回答，要問清楚為止，再給出自己的方案進行協商。如果可以回答，倒是可以簡單的說「OK，這個我們到時候會有的」。
業務捕獲分為三塊，分別是組織架構、業務架構和業務實務。這裡面有非常繁雜的邏輯，就列一些要點大綱，不做展開。
先講組織架構，這個基本上最核心的。而絕大部分人員腦海中，組織結構圖就是一棵樹。導致甲方給的資料是這樣，乙方提供的系統也是如此。
實際在營銷CRM系統中，至少要被拆分為兩棵樹。一顆是企業的機構樹，企業下面分了多少個部門。
另一顆是各部門的樹，繼續分拆。這樣能實現，財務部老總看到所有營銷部門的銷售數據，財務部某個財務主管看到營銷部南方戰區的銷售數據。組織架構基本和權限設計綁定，是CRM系統的基石，要仔細考慮。
然後是業務架構，細分為部門業務和崗位設置。關於部門業務，需要注意以下幾點：
關於崗位設置，從下述的幾個方面提問：
這裡面，強調下崗位的問題。如果一人多崗，會影響整體系統的設計，包括權限那塊。
技術捕獲，主要是技術層面的訴求，也存在很大的風險。
遺留系統方面，注意以下三點：
外部系統方面，注意以下4點：
剩下的是一些非功能性需求，一般有：
調研節奏普遍較快，密集的1-2周。調研人員每天晚上就是寫會議紀要以及跟進問題，很少時間進行需求設計。再加上項目人員一般設計能力有限（大部分項目經理是axure略懂而已），需要請求總部資源，調研結束後一般就回總部。然後1-2周進行需求設計輸出原型，項目經理配合產品出解決方案。
但是這個階段有個空窗期，且搜集信息未得到確認。最好聯繫甲方項目經理，組織部分干係人，進行需求調研匯報。匯報的內容主要包含：
需求分析的過程，大部分是客戶無感知的，只能體現在最終的輸出物中。
我個人認為主要分為產品（含PaaS）、業務和報表三塊。
產品需要考慮：
業務需要考慮：
報表需要考慮：
在需求分析過程中，有很重要的一個點，就是給需求排優先級，嘗試切分部分需求。這個在立項時候甲乙雙方就有約定，但調研過程往往有變數。所以需要基於調研情況，重新排優先級，切分階段。
一般都會分成兩期上，一期先上某個渠道，搭建好基礎。需求的優先級，基本上對內不對外。即便一期的內容，乙方內部也是要排優先級的。每一期的功能清單，都不包含優先級。最終計劃怎麼排，哪些功能可以如期上，乙方內部要心裡有數。
而功能清單是全量的，一般附帶在需求規格中。但是會加上標註，區分每一期的內容。這個功能清單基本是頁面級別的，顆粒度比較粗。
售前階段已有解決方案，是比較靠近標準產品和行業的。而業務解決方案則是落地，貼近企業實務。基本上，是調研匯報內容的總結和升華。
部分項目中，這個由項目經理編寫，產品做輔助支撐。產品需要提供各個業務的流程圖和設計原型，匹配業務訴求。
另外部分重點項目，這個由產品獨立解決。這種方案有點偏諮詢，除了本次調研的業務還涉及其他的相關系統。要基於行業營銷信息化的認知，去構建大營銷系統的藍圖。所以什麼AI、數據中臺，統統都上。
原型驗證基本上是和業務解決方案同時開始的，業務解決方案中包含重點業務的原型圖。一旦業務解決方案得到認可，就開始細緻的原型驗證階段。這個階段客戶會開始看UE，原型的改動非常多。
舉個例子，B端是非常喜歡單據式布局的。一方面是使用習慣，另一方面是單據布局直觀緊湊。尤其是APP端，經常出現客戶選擇表格布局替代卡片布局的情況。
CMMI的定義中，交付物包含用戶需求規格說明書和產品需求規格說明書。實際項目中的需求規格說明書，基本上是用戶需求規格說明書。這是常態，只有基於業務的描述才能和甲方進行確認。但很多研發是沒有業務背景的，看這份用戶需求很難直接進行概要設計。基於成本考慮，部分細節會一併在這份用戶需求規格上。
所以，我們看到的項目的需求規格，大部分時候是四不像的大雜燴。一般包含：用戶需求規格說明書+欄位細分說明（部分會省略）+接口說明+狀態流程說明（審批流、訂單業務流等）。卻又缺少了關鍵的需求建模信息（主要是領域建模），研發要頻繁的找產品問業務，才能進行概要設計。
項目的需求規格，基本上是和原型同步啟動的。但我個人建議是原型驗證後，再貼原型圖。最好文檔基本確認完成，再貼原型圖。期間原型圖可以生成html打包，郵件給甲方查閱。不這麼做，就是以下的情況：
補充說明：
產品需求規格中，需求建模主要包含用例圖（內部WBS拆解夠細，可不出）、類圖（可簡化為ER圖）、序列圖（可簡化為活動圖）、狀態圖。以訂單領域為例：
PS：將近一年前的PPT，拿出來分享。從輸出倒逼輸入，真的是很痛苦，各位將就下。
作者：道·術 ，郵箱：olivercan.wunban@foxmail.com
本文由 @道·術 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash ，基於 CC0 協議