業務需求調研經驗分享

1. 針對具體的工作內容，召集專題訪談啟動會、訪談溝通會。

由客戶的專案負責人向涉及的相關部門或者受訪物件進**況介紹和工作任務安排，並注意在會上詳細、正式的介紹需要參與的具體訪談的人員，並收集被訪談物件的基本資訊（包括：姓名、部門、聯絡**、email等）。

2. 在正式訪談之前，給訪談物件提供訪談提綱或需求調研表，並告知客戶需要根據提綱進行準備。即使客戶未填寫調研表，但通過訪談提綱可以讓訪談物件提前思考，整理應答思路、收集相關資料，或者提前準備、預約更合適的訪談物件。

3. 正式訪談前，先向被訪談者介紹訪談議程。

介紹訪談總體過程、各環節主要內容、大致時間。務必先給被訪談者建立乙個全域性整體印象，也便於雙方共同掌握訪談時間和節奏。

4. 開始具體工作內容的訪談前，概要性介紹專案的背景及其他相關情況，快速拉齊與訪談物件的思路基線。但要注意：針對不同型別的物件介紹的側重點應有所不同。管理類重點介紹全域性的、巨集觀、整體性的目標和架構；業務類物件重點介紹業務相關的背景、行業發展情況等；技術類物件重點介紹目前了解的客戶系統的現狀、本專案的期望、業界相關應用及發展趨勢等等。

5. 訪談內容在議程等大框架方面宜統一規範，而在具體交談內容等細節方面則盡量發散。交談過程以發散為主，引導為輔。如果被訪談物件對訪談內容熟悉，且有一定準備，能夠主動、系統、清晰的交流，則盡量以被訪談者發言為主。因為，從訪談物件不經意的一些細節描述資訊中，可能發現很有價值的重要資訊(如果引導式交流則往往容易限制被訪談者思路，造成一問一答的局面)；當客戶談到意料之外的重要資訊時，要抓住時機主動深入挖掘，充分收集這些在前期準備階段未考慮到的需求。如果被訪談物件交流內容匱乏，不知從何談起，則需要系統化的引導，此時一問一答勝過無話可說。

6. 訪談過程中的快速、準確的、原原本本的筆錄非常重要。

好記性不如爛筆頭，將客戶訪談時說的盡可能完整的記錄下來，並且務必使原原本本的記錄，不要增加任何的個人理解。對需求的理解、整理應該是訪談之後的結合全域性的需求進行綜合分析和全面理解工作。需求分析的最後環節一般會對分析結果進行印證，而印證的唯一證據就來自訪談記錄，此時客戶訪談時原始的記錄就非常、非常、非常重要。如果缺乏原始的訪談記錄作為素材，在後續的需求分析結果有可能偏離客戶的實際需求，對專案整體工作的都會造成不利影響。

7. 對於多人參與訪談乙個被訪物件時，訪談提問建議分工明確、各司其職。可以以乙個人為主，其他人補充；或者每個人有其他的分工方式，例如有人負責業務需求部分、有人負責技術部分、有人負責管理部分等等。

8. 記錄筆記時要主次分明，記錄者與提問者保持默契。

若多人同時參與訪談，在記錄筆記時盡量多人同時記錄。並且，提問者在提問時一般不宜做詳細的記錄，此刻輔助者公升級為是主要的記錄者，讓提問者有足夠的思路時間，考慮問題、理解客戶描述的內容、及時發現疑慮當面澄清等等。

9. 對於訪談內容的疑問、顧慮應盡量做到當面澄清，減少事後增補，杜絕二次訪談。

一次成功的訪談，能有效降低思維切換成本，確保交流雙方在特定場景下思維的嚴密性、完整性，從而確保需求訪談質量。如果在訪談的自己擔心沒有準確理解被訪談者的意圖，盡量當面溝通、澄清；事後一般是需求確認、證實性工作，而需求的增補、或者重新調研時，被訪談者的思維往往不如正式訪談那樣完善和嚴密，容易對專案造成誤導和偏見。

10. 在交流完被訪談物件所屬專業的內容之後，嘗試引導客戶進行跨專業的需求交流

。例如：訪談管理層時，可針對本專案需求和目標，**管理層對業務部門、技術部門等有何要求和建議；訪談業務部門時，可引導被訪談者根據專案需求提出對管理部門、技術部門的要求和建議；訪談技術部門時，可與被訪談者溝通從技術實現和專案建設、管理的角度，建議管理部門如何規範管理、業務流程制定，既利於系統建設維護，又利於專案實施。

【但要注意，需求訪談階段，需求資訊收集基本原則是盡可能充分、完整；如果需求收集不充分，開發的軟體產品不能滿足使用者需求的可能性就越大。但需求是否超出本期系統建設範圍、本期商務合同功能需求範圍，是另外乙個層面的問題。需求訪談時，被訪者提出的需求超出範圍的情況在所難免，這方面，將在後續的文章中專門闡述】

業務需求調研經驗分享

業務需求調研經驗分享

業務需求調研經驗分享

業務需求調研文件內容結構參考

相關推薦