起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以車銷業務為例，聊聊B端項目需求調研
本文以車銷業務為例，向我們分享了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層面），先判斷需求是什么。為達到目標，是否有更低成本的方式。又或者，是否有更通用的方式，為后續該功能點產品化做準備。
最后，是對競品進行捕獲。現有項目基本是兩種：
- 替換已有系統；
- 新上系統。
一般1的話，能提前拿到UAT環境，進去看看能知己知彼。2的話，大部分項目公開招標。招標過程中基本試用或POC過，客戶一定是想要最優秀的體驗。所以會存在某個功能對方有，我們也要。又或者某個功能別人的好用，你改一改這種。如果能借機能拿到競品的環境，就是很好的競品分析機會，也能提前準備。
舉個例子，以下是隨便找的車銷解決方案，可以看出大體流程和業務支撐能力。
調研中
整體方法
三字訣——問聽記。
剛接觸調研，可能覺得記是最困難的。一般帶新人，也是讓他從記開始?？蛻糁v了很多，到底記什么。客戶講的很快，記不過來等等。建議開始調研的時候帶上紙筆，這種時候寫字比反而可能比打字快。然后可以開啟錄音，記不清的（先記錄個時間）可以回去再聽。
經歷個一兩次，會知道問是最困難的。調研的過程，基本就是一問一答，基于已有的知識和聽到甲方的回答進行提問。整體的節奏被提問人員控制，只有自己感覺獲取足夠多的信息，能將業務流程串聯起來，足夠輸出需求規格，才會停止發問。建議在問完一個大的問題后，提出歸納類問題“那我說下我目前關于X的理解，看看對不對”。這樣才能確保你的信息是足夠的，且甲乙雙方的認知是統一的。
這里要特別強調下——少一點套路。B端調研往往，過于期望“引導”客戶。無論你在這行混了多少年，奮斗在企業營銷一線的才是專家。即便同行業規模類似的企業，渠道的模式和具體的玩法上都會有差異。所以不要嘗試從業務合理性上去否決訴求，最多只能是技術代價比較高（也有先有技術無法實現的，請直接否決掉）。能做的引導，是保證實現目標的前提下，往現有產品靠攏，選擇簡單的實現方式。
總體捕獲的方法，是5W1H分析法。這個是很成熟的方法不做展開，簡介如下：
需求調研過程中，往往會出現甲方問諸如“客戶列表頁面，投放冰柜的要有標簽或Icon區分出來”這種問題。這其實是跨階段了，需求調研階段要解決的是業務是什么，為什么這么做，怎么協作完成。怎么設計UI頁面，那是后面原型驗證&解決方案階段的事情。遇到這種情況，調研人員不能簡單考慮可行性，要先問自己“為什么要區分，不區分有什么影響嗎？為什么在這里區分，是不是可以在其他地方區分？”。如果自己無法回答，要問清楚為止，再給出自己的方案進行協商。如果可以回答，倒是可以簡單的說“OK，這個我們到時候會有的”。
業務捕獲
業務捕獲分為三塊，分別是組織架構、業務架構和業務實務。這里面有非常繁雜的邏輯，就列一些要點大綱，不做展開。
先講組織架構，這個基本上最核心的。而絕大部分人員腦海中，組織結構圖就是一棵樹。導致甲方給的資料是這樣，乙方提供的系統也是如此。
實際在營銷CRM系統中，至少要被拆分為兩棵樹。一顆是企業的機構樹，企業下面分了多少個部門。
另一顆是各部門的樹，繼續分拆。這樣能實現，財務部老總看到所有營銷部門的銷售數據，財務部某個財務主管看到營銷部南方戰區的銷售數據。組織架構基本和權限設計綁定，是CRM系統的基石，要仔細考慮。
然后是業務架構，細分為部門業務和崗位設置。關于部門業務，需要注意以下幾點：
- 哪些部門和項目相關
- 這些部門各自分管哪一塊，怎么考核
- 對照的職責是否都在系統上落實，工作流全部跑通
- 了解推力和阻力，盡量讓每個部門都有所獲益
- 各組織節點，部門設置是否一致?；蛘哒w職責是否一致，只是有所合并拆分（最怕遺漏了某個部門，而且這個部分流程全部特殊）
關于崗位設置，從下述的幾個方面提問：
- 崗位的大概目標，考核的大概方法（KPI）
- 崗位間的協作和上下級關系
- 哪些崗位需要對外（區分內外勤人員）
- 哪些崗位會啟動新流程
- 各層次崗位是否能統一
- 是否出現一人多崗的情況（業務人員兼主管是很常見的）
- 是否已有內部系統編碼，領導是否要顯示最前面
這里面，強調下崗位的問題。如果一人多崗，會影響整體系統的設計，包括權限那塊。
技術捕獲
技術捕獲，主要是技術層面的訴求，也存在很大的風險。
遺留系統方面，注意以下三點：
- 是否并存，并存到何時，職責切分
- 能否替代，替代節奏和方案
- 數據能否遷移，遷移方案
外部系統方面，注意以下4點：
- 是否并存
- 能否替代
- 接口
- 數據
剩下的是一些非功能性需求，一般有：
- 可靠性
- 可用性（注意體驗）
- 有效性
- 可移植性
調研匯報
調研節奏普遍較快，密集的1-2周。調研人員每天晚上就是寫會議紀要以及跟進問題，很少時間進行需求設計。再加上項目人員一般設計能力有限（大部分項目經理是axure略懂而已），需要請求總部資源，調研結束后一般就回總部。然后1-2周進行需求設計輸出原型，項目經理配合產品出解決方案。
但是這個階段有個空窗期，且搜集信息未得到確認。最好聯系甲方項目經理，組織部分干系人，進行需求調研匯報。匯報的內容主要包含：
- 組織架構圖
- 分部門的崗責清單（Excel）
- 重點業務流程&審批流程梳理（Visio）
- 核心業務原型圖（axure）
需求開發
需求分析
需求分析的過程，大部分是客戶無感知的，只能體現在最終的輸出物中。
我個人認為主要分為產品（含PaaS）、業務和報表三塊。
產品需要考慮：
- 現有的PaaS配置能力
- 標準產品邏輯（標準產品已有能力要補充到需求規格中）
- 公共需求的抽象（分頁、導入導出等）
業務需要考慮：
- 流程和分支節點
- 事件觸發（時間or操作）
- 特殊字段維護（如訂單類型，是通用字典維護，還是專用頁面維護，或者寫入數據庫不提供UI界面維護，甚至直接代碼寫死）
報表需要考慮：
- 周期（日報、周報、月報）
- 樣式（動態列頭？）
- 明細流水
- 統計抽取
- 歷史數據處理
- 性能
在需求分析過程中，有很重要的一個點，就是給需求排優先級，嘗試切分部分需求。這個在立項時候甲乙雙方就有約定，但調研過程往往有變數。所以需要基于調研情況，重新排優先級，切分階段。
一般都會分成兩期上，一期先上某個渠道，搭建好基礎。需求的優先級，基本上對內不對外。即便一期的內容，乙方內部也是要排優先級的。每一期的功能清單，都不包含優先級。最終計劃怎么排，哪些功能可以如期上，乙方內部要心里有數。
而功能清單是全量的，一般附帶在需求規格中。但是會加上標注，區分每一期的內容。這個功能清單基本是頁面級別的，顆粒度比較粗。
業務解決方案
售前階段已有解決方案，是比較靠近標準產品和行業的。而業務解決方案則是落地，貼近企業實務。基本上，是調研匯報內容的總結和升華。
部分項目中，這個由項目經理編寫，產品做輔助支撐。產品需要提供各個業務的流程圖和設計原型，匹配業務訴求。
另外部分重點項目，這個由產品獨立解決。這種方案有點偏咨詢，除了本次調研的業務還涉及其他的相關系統。要基于行業營銷信息化的認知，去構建大營銷系統的藍圖。所以什么AI、數據中臺，統統都上。
原型驗證基本上是和業務解決方案同時開始的，業務解決方案中包含重點業務的原型圖。一旦業務解決方案得到認可，就開始細致的原型驗證階段。這個階段客戶會開始看UE，原型的改動非常多。
舉個例子，B端是非常喜歡單據式布局的。一方面是使用習慣，另一方面是單據布局直觀緊湊。尤其是APP端，經常出現客戶選擇表格布局替代卡片布局的情況。
需求規格說明書
CMMI的定義中，交付物包含用戶需求規格說明書和產品需求規格說明書。實際項目中的需求規格說明書，基本上是用戶需求規格說明書。這是常態，只有基于業務的描述才能和甲方進行確認。但很多研發是沒有業務背景的，看這份用戶需求很難直接進行概要設計?；诔杀究紤]，部分細節會一并在這份用戶需求規格上。
所以，我們看到的項目的需求規格，大部分時候是四不像的大雜燴。一般包含：用戶需求規格說明書+字段細分說明（部分會省略）+接口說明+狀態流程說明（審批流、訂單業務流等）。卻又缺少了關鍵的需求建模信息（主要是領域建模），研發要頻繁的找產品問業務，才能進行概要設計。
項目的需求規格，基本上是和原型同步啟動的。但我個人建議是原型驗證后，再貼原型圖。最好文檔基本確認完成，再貼原型圖。期間原型圖可以生成html打包，郵件給甲方查閱。不這么做，就是以下的情況：
- 以會議紀要的形式記錄改動點，晚上回去后要先原型。原型改好要截圖，貼到PRD。但經常出現，原型圖和PRD字段不匹配。
- 以屏幕擴展的方式投屏，客戶要修改的，現場標記或者改好?；厝ゴ颐Ω脑停瑴蕚浜竺娴脑万炞C。后面再補PRD，很容易造成遺漏（因為是密集的原型驗證，這期間客戶不看PRD，導致PRD和原型脫節）。
- 原型驗證完成，開始評審PRD。開啟審閱+批注后，打開和保存文檔不是一般的卡（4G內存還能怎樣）
補充說明：
產品需求規格中，需求建模主要包含用例圖（內部WBS拆解夠細，可不出）、類圖（可簡化為ER圖）、序列圖（可簡化為活動圖）、狀態圖。以訂單領域為例：
- 用例圖，訂單的所有用例，如查看查詢、新增、編輯、導入、導出、審核、發貨、收貨
- 類圖，訂單類的成員名和字段類型乃至長度，以及審批單、發貨單、送貨單、收貨單等附屬單據信息。
- 序列圖，訂單的全流轉過程。
- 狀態圖，訂單的先后狀態和觸發狀態變更的操作
PS：將近一年前的PPT，拿出來分享。從輸出倒逼輸入，真的是很痛苦，各位將就下。
作者：道·術 ，郵箱：olivercan.wunban@foxmail.com
本文由 @道·術 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash ，基于 CC0 協議
補一個PPT下載鏈接 ? ，https://share.weiyun.com/5CHcmhX
牛