筆者在上篇文章《B端項目調研提綱的設計與思考》中，重點闡述了以調研目的為核心所需要進行的準備和工作，之所以強調目的呢，其實是為我們接下來的需求采集服務的，即如何提升需求采集的效率，如何保證采集回來需求的質量，帶著這些問題，讓我們進入到本篇文章的中心：如何進行B端產品的需求采集？

一、需求采集方法綜述

在調研的過程中，我們一般會采用定量和定性的方式來采集需求，其中定性方式包括用戶訪談和可用性測試，定量方式包括調查問卷和數據分析，數據分析和調查問卷一般用于用戶數量龐大的C端產品，B端產品因用戶量相對C端來說用戶量數量級要少的多，因此從統計學的角度來看利用數據分析來獲取用戶的需求在B端產品中用到較少，在本人實際參與到B端產品需求采集的過程中，主要是用到調研訪談和可用性測試，下文我將重點闡述在調研實踐過程的這兩種方法和注意事項。

二、B端產品需求采集實踐

1、調研訪談與實踐

調研訪談是需求采集方式中最為普遍和有效的方式，接下來我將帶大家一起模擬進入到調研訪談的場景中，在實景中去感受，相信會有更深的體會。

場景1：根據與客戶定好的調研訪談日期，調研人員李工今天提前半小時來到了會議室，他先打開了窗戶，讓室內的空氣變得清新許多，整理和布置了下現場桌椅，看上去整齊干凈許多，幾分鐘后，需要參加被調研業務流程客戶王經理準時來到了會議室，李工主動和王經理微笑并握手致意，順便愉快的聊了下柜子上的籃球獎狀的來由，然后開始正式的會議，在正式訪談前，說明了下本次訪談的目的、范圍和所需要的時間，王經理點頭表示認可以進入到下一步。

相信大家可能會有疑問了，為什么正式訪談前需要做這些鋪墊，其實主要是為了：

（1）營造一個輕松、舒適的訪談環境，一個好的開始，對于后面工作的開展是很有必要的

（2）正式訪談前介紹本次調研的目的、范圍和所需要的時間，讓被調研人員獲悉本次訪談的重點，內容和時間，讓調研對象心里有底。

場景2：王經理，為了便于我們后期調研內容的整理，準備了錄音設備對本次談話內容進行錄音，您是否同意啊，王經理示意可以，并且希望后期可將資料發送一份給他的意見。隨后李工開啟第一個提問：王經理，目前供應商的管理主要存在哪些問題？王工回答完畢后，李工追問了線下的供應商資質為何管理困難？接著李工問了其他問題：您希望系統解決哪些問題？介紹下現在線下的業務流程是如何進行的？

這個場景需要注意的方面有：

（3）巧用設備備份調研過程，便于后期整理與回顧

（4）提問應先易后難，循環漸進

（5）針對有疑問的地方，恰當的追問，找到背后真實的需求

場景3：隨著調研的深入，王經理強調要采用目前某同行的解決方案來做這個產品，李工詢問為什么要采用該解決方案，并強調目前產品方案的功能和特性，王經理因有過軟件開發的經歷，提問本次產品的技術是否采用MVC架構，李工答道，我們本次的調研訪談的目的是收集供應商證件管理的需求，技術方案將在需求確定后由我們的技術人員與您溝通這個事情。

該場景需要注意的方面有：

（6）用戶過于強勢，強調解決方案，沒有提出本質需求

（7）避免成為用戶的記錄員和設計師，應該挖掘提出背后的原因

（8）調研人員過于強勢，強調產品功能及特性來引導用戶，忽略了用戶真正的需求

（9）調研環節應避免討論技術和太過專業的術語

（10）將話題拉回調研主題，避免話題分散

場景4：王經理，您可以舉個例子來說明下供應商資質審核的步驟嗎？希望您多回憶一下，步驟越清晰越好，您剛剛提到目前審核的瓶頸問題是審核的效率，是說目前的供應商資質的審核是一次只能審核一個導致的效率低嗎？如果可以的話，你能否給我演示下操作的過程以及為何需要這樣的操作？

該場景需要注意的方面有：

（11）鼓勵用戶講故事，這樣用戶和使用場景會更加形象和具體

（12）重述理解用戶的意思，保持對問題理解的一致性

（13）相比用戶如何說，更應該關注如何做；相比用戶如何做，更應該關注這樣做背后的原因

2、可用性測試方法與實踐

可用性測試是B端產品驗證用戶需求、收集需求必要而有效的方式，而驗證的方式是多樣的，可以是產品、競品、demo、高保真、低保真、草圖原型甚至是一張手繪的草圖都可作為測試方法，根據演示環境和用戶的角色的不同觀察用戶使用產品，其本質目的就是驗證需求、收集需求。

在這里先說說可用性測試前的準備工作，其大綱如下：

（1）首先應該理清思路，確定測試的目的，用戶的角色、特征和使用的業務場景，目標不清晰，思路不對會導致事倍功半。

（2）理清思路后，需要準備演示的相關資料，常用的軟件硬件設備有：紙、比、文檔、錄像設備、演示電腦、相關軟件，重點提及一下錄像設備，之所以需要錄像，其目的是在錄音的同時捕捉用戶操作過程中的肢體、表情等動作，不同的微表情和動作可以很好的體現出用戶當時使用產品的感受，便于調研人員后期的總結和分析。另外需要強調下原型設計，在未確定好業務流程圖和頁面流程圖直接設計原型是存在很多問題的，業務流程的不清晰、用戶和使用場景的不清晰、信息架構的不清晰都會影響到原型呈現出產品的定位和用戶體驗，原型設計的過程本文不做詳細的描述，后文會有專文針對產品設計的文章來進行探討，最后再介紹下測試腳本，其目的是記錄用戶測試產品過程中的信息，可參考如下表：

表中問題等級可依據實際情況進行設置，至此，準備就緒，可安排相應的用戶進行可用性測試了，其注意事項將沿用場景化的描述方式。

場景1：李工在進行完深入的業務流程調研后，以用戶+使用場景的方式進行了需求分析，繪制了業務流程圖，設計了頁面流程圖，利用原型軟件制作了可實現交互效果的原型demo，暖場之后，介紹了本次測試的目的是產品非用戶，李工助理架起了錄像設備，李工提出希望采購部張經理在測試的過程中，盡量表達自己的感受和想法，接著張經理開始了測試，當張經理遇到困難時；李工并沒有主動引導怎么做，而是在一旁鼓勵他，同時很細致地觀察著張經理的行為和表情的變化，測試完成后，李工拿著初步整理后的測試用例與張經理進行了確認，并告知會盡快將測試結果及會議紀要已郵件的形式發送。

該場景需要注意的有：

（1）告知用戶測試的目的是產品而非人，便于減輕用戶的顧慮

（2）鼓勵用戶說出自己的想法、感受和思考過程，便于需求挖掘

（3）用戶測試過程中盡量不要提供幫助，適當給予鼓勵，便于發現更多問題

（4）在聽用戶說的同時觀察用戶如何使用產品，包括操作過程和臉部情緒，便于需求分析

三、調研報告整理與反饋

在進行完調研訪談和可用性測試之后可不要忘了反饋結果，及時的反饋結果不僅能體現出調研人員的專業性給客戶留下好的影響，也能及時發現調研中的遺漏、理解有誤和不足的問題，最主要的是能夠讓雙方對解需求采集進度是一致的，如何保證反饋的質量，會議紀要作為雙方理解的依據有著很重要的作用，下圖是本人會議紀要的大綱，提供給大家參考

可將用戶訪談和可用性測試的過程和結果記錄于會議內容中，如果有待確認事項，可放在下次會議進行確認。

四、總結

上文就是筆者在進行B端項目需求采集實踐過程中所總結的方法和注意事項，主要介紹了調研訪談和可用性測試，當然因行業和經驗的差異，可能存在不當或錯誤之處，希望和大家一起探討，另外做個小小預告下片文章將討論如何做需求分析，感謝大家的閱讀！

相關閱讀

B端項目調研提綱的設計與思考

作者：張磊（個人公眾號：lightinglei）互聯網醫療B端產品策劃者，音樂愛好者，籃球愛好者，攝影愛好者。

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

題圖由作者提供