在系統外包商進行對外實施項目之前，需求調研指乙方對甲方需求進行摸底了解。需求調研將會直接影響到后續商務談判和研發及驗收流程。

需求調研分為三階段：

• 第一階段：初次摸底。結果物：是否與該客戶合作的主觀結果
• 第二階段：系統邊界框定。結果物：大的系統功能模塊的認定，SOW交付?？蛻粲谐醪揭庀蚧蛲稑诉^初輪。
• 第三階段：mock展示。結果物：系統主用例通過客戶認定，商務合同簽訂或中標。

第一階段：初次摸底

準備資料：客戶當前業務信息收集（包括財務狀況，是否盈利），談判時對方參會人員及職位，欲向對方主推的產品或服務的紙質文檔（重要，很有可能客戶所在場所不能投影），標準化問卷（不需展示給客戶，自己對照檢查看問題問的是否全面，主要涉及到自家產品絕不可能做到的大的業務邊界）。

交談過程：傾聽為主，若需介紹，泛泛而談。

無需談系統，主談案例，但不應透露其他客戶名稱。

觀察對方狀態，若對方為CXO級別，問業務主打方向，無需拘泥細節，主談遠景。

關鍵點：考察對方是否預期過高，是否不懂法規，是否需求過虛。以上三點有一點，慎選，需回公司討論。

回公司復盤：產品，商務和技術主管就客戶愿景給出解決方案，并評估：

• 與本公司當前主營業務是否匹配
• 本次合作是否有利于產品積累
• 對否有利于公司在業內地位的提升（起碼是穩固）。

第三點為最重要。若三點全部占據，放棄。

第二階段：系統邊界框定

準備資料：解決方案PPT和大致的業務框架，競品報價信息，技術主管作為資源必須出席

交談過程：主講解決方案適用的用例場景，顆粒度在10個用例左右。不可過多也不可過少。對方在傾聽中提出的問題稍作解釋，不應生發跑題，注意控場。用例講完后集中回答問題。

若對方拘泥于技術細節，告訴對方，技術上的問題不是問題，解決方案是否滿足客戶需求是本次溝通要解決的問題。（在實際談判中，甲方的技術是乙方的毒藥，且不可被甲方技術主管牽著鼻子走）

關鍵點：是否漏了第一次溝通中沒有講到的關鍵用例場景，甲方的技術主管是否非常難纏，甲方對乙方的產品及實施周期是否期望過高。

回公司復盤： 本階段溝通可能需要往返兩次或更多，直到確定下最關鍵的10個用例場景。

本階段結束的標志是商務合同的簽訂（附SOW）

第三階段：mock展示

準備資料：技術原型（簡單的數據庫及前后臺界面，需要做一些假數據用于呈現）

交談過程：詳細展示mock的每一項功能，仍按用例展示。

本展示需產品經理進行，技術主管作為補充。若對方問起實現方式，需詳細解釋，甚至出示詳細的系統架構圖（不是SOW中的系統架構圖，需要更細致）

展示后，需聽對方業務人員描述具體業務場景，并做好技術重構的準備，因為業務人員的具體操作和高層管理人員的期望并不一致。

關鍵點：可能需要對接多個業務部門及多個外系統，可以分時分批聽取業務部門操作人員的需求，但需要隨時和對方項目經理溝通，對于巨大的需求出入（比如與預估工期嚴重不符的情況），需重啟商務談判，重估工期與報價。

回公司復盤：隨時了解需求變更動態，框定版本計劃與資源投入。嚴格控制版本內需求項目，不可超出，不可偏移。若超出或偏移，都需重啟商務層面的溝通。

本文由 @echo回聲?原創發布于人人都是產品經理?，未經許可，禁止轉載。