編輯導語：不管是新業務，還是已經成熟的業務，一般都需要進行需求調研。那麼，需求調研該怎麼做呢？本文作者從需求調研的準備工作、目的分析以及調研方式這三個方面，探討分析怎麼才能快速開展需求調研，希望能給你帶來幫助。
文章將從需求調研的準備工作、需求調研的目的分析、需求調研的方式選擇三個部分出發，探討我們應該如何準備才能快速開展需求調研。
一、需求調研的準備工作1. 基礎功，提升溝通能力需求調研的準備工作，第一項我認為是“溝通能力”，這也是平日需要磨鍊的基本功。
我曾經自詡溝通能力很強，直到有一次和同事共同進行業務調研，同事給我的反饋是：溝通的目的性太強了，容易引導用户。他説產品經理是一羣邏輯思維突出，目的性很明確的人，但是在和用户溝通的時候，應該多傾聽用户的聲音，挖掘背後的問題。而不是利用邏輯，引導他們去回答指定的問題，否則都沒辦法去發散思維，發現更多的可能性。
剛開始，我還不太理解，覺得調研不就是了解問題之後，驗證這些問題是否真實嘛，內心有過一絲委屈和不解。直到後來仔細觀察他和業務人員的溝通氛圍、提問的技巧才發現，自己有些時候確實不是在做溝通，而是在表達（如果要正名，我應該説自己“表達能力”很強，而不是“溝通能力”很強）。
“表達”和“溝通”的區別在哪裏呢？
表達是單向輸出的狀態，將自己的想法“灌輸”給對方。而溝通則是雙向的交流的過程，雙方能換位思考，使用相同的“語言體系”，在洞察對方的語言表達習慣、思維方式上進行你來我往的交流。
而實際的調研中對產品經理提出了更高的要求，通常需要產品經理調整自己的表達方式，讓被調研的用户覺得這個人和我在一個層次上，我能輕鬆理解他説的內容，我們能順利地溝通，並且聊得很開心。説難聽一些，產品經理們在調研的過程中，應該少一些自我，多一些謙卑與傾聽，就能有意想不到的收穫。
一個簡單的例子，我司業務人員在稱呼銷售人員的時候，經常使用“小助理”一詞，那麼在調研的時候，就不要將“小助理”改為“銷售助理”“銷售人員”“銷售”等詞彙。而是應該和業務統一步調，避免無意製造溝通的障礙和增加思維切換的成本。
除了要注意雙向信息的交流，還應該有敏鋭的觀察力，能識別用户是否在撒謊或者隱瞞什麼事情。因為人都是趨利性的，會潛意識美化自己的行為，如果發現用户在溝通的過程中有以上行為，需要有適度的引導或者話題鋪墊，卸下用户的戒備心，發現事情的真相。
在需求結果的實地調研中，有一件印象很深刻的事情。
當時團隊上線了客户的餘額管理體系，能幫助小助理從手工登記客户餘額的繁瑣工作中脱離出來。UI 小姐姐站在一位小助理的身後（想觀察交互體驗來着），看着她用Excel表格一個一個地登記客户的名稱、充值的金額、訂單消費的金額、剩餘的餘額……UI 小姐姐問：“你為什麼為什麼自己做表格，不用導出功能啊？”結果小助理沒好氣地瞪了她一眼，説了句大區經理需要，就繼續製作Excel表格了。
我瞭解情況後，先和小助理解釋了一下我們是產品團隊的（消除戒備，她以為我們來是盯工作進度的），最近上線了一個客户餘額明細導出的功能，她製作的表格，可以通過系統10秒鐘就導出指定客户的餘額信息（提供幫助，獲得信任）。
然後小助理情緒明顯轉變，畢竟要 1-2 個小時才能做完的工作，10 秒鐘就能搞定了。接下來深入溝通後才發現，這是完全不必要的工作——原因在於產品上線後的系統培訓和功能同步做的不到位，也由於人員對的互聯網認知層次問題，大區經理並不知道自己可以通過查詢+導出拉取客户的餘額數據。
為了分解自己的工作，大區經理轉而讓每個小助理上交客户的餘額表，而小助理們的信息系統的操作經驗更不足，就懂得一個一個的查詢客户名稱後登記到表格，再提交給大區經理。
這對人力是多麼可怕的消耗啊！
2. 開始準備，善用工具聊完虛的但重要的事情，現在正式開始實際的準備工作吧，工欲善其事必先利其器。
李誕在他的《李誕脱口秀工作手冊》中提出過：我們怎麼提高讀稿會（所有涉及創作的會都適用）的效率？帶東西來。不要空手踏入任何一個會議室，把稿子寫好了再來，哪怕是你們創作小組開會，也該寫好了初稿再聊，哪怕只寫幾個想法，也得有東西再開會。還是那句話，寫不好你還寫不壞嗎？
挺有意思的觀點，產品的需求調研也是一樣的，不要貿貿然就跑去找業務聊，時間也是成本。提前準備一份調研大綱，工具可以是思維導圖或者Word文檔，甚至Excel表格。形式不重要，重要的是能夠達成調研的目標。
在調研開始之前，我們最好可以編寫一份調研清單，設定好數據分析的計劃，然後再根據目標去拆解，設定調研的內容大綱。沒有提前規劃好要什麼數據、數據怎麼用，就設計了調研內容的坑，我是踩過的，看看這篇幫你避坑：《案例實戰|我在產品MVP中，踩到的調研問卷坑》。
如果你是通過調研問卷來獲取用户需求，公開的免費軟件有問卷網（更專業）、騰訊問卷（輕量化），鏈接的文章中略微講解了兩者之間的差異，酌情選擇吧~
另外我自己還常用UML 工具梳理核心的業務流程，然後單獨列出要重點了解的問題點，比較不容易遺漏。
PS：Mac用户可以使用 Process on 的在線流程、思維工具，Windows 用户可以下載 Visio，功能基本差異不大，體驗感也差不多。
這裏有一個小技能點，需求調研並不都是以慎重約定、正兒八經的會議形式發生，甚至只是在偶然的談話間完成的。和幾個核心的業務人員保持好聯繫，及時提供幫助，在平日裏就可以無壓力和他們請教一些問題啦。
如下圖，就是在正式的業務調研開始前整理出來的流程，對接下來的具體問題調研有很大的幫助（當然，你也可以用稱這種方式為一對一的業務訪談）。
△某MCN機構的核心業務流程
二、明確需求調研的目的明確需求調研的目的，也是調研的準備工作的一部分。這裏基於筆者自己的項目經驗，將調研的目的分為兩種。
1. 新業務調研，主要在於《案例實戰|我在產品 MVP 中，踩到的調研問卷坑》，這一篇文章就是針對新業務的調研發起的，附帶着了市場洞察、創意驗證、瞭解用户痛點的目的，不再贅述。
渠道信息蒐集不屬於嚴格意義上的新業務調研的形式，成熟業務中也會用到，只是一般發生在獲客的環節，所以我放在了新業務調研的維度。
大家在註冊、首次登錄一些產品的時候（特別是 SaaS 產品）應該有遇到過，網站會彈出頁面，問“你是在哪個渠道瞭解到我們的產品的 ?”這種調研的形式，我理解的是：要麼是產品獲客的鏈路不暢通，無法通過線上數據標記自動化識別用户的來源；要麼是為了做客户線索的分層、清洗，設想如果是哪個渠道來的都不願意填，體驗產品的意願度就非常低了。
2. B端成熟業務的調研以前寫過一篇總結《B端需求調研，善用“人、場、文”三字訣》，內容雖然比較單薄，但是框架性的思維依然有效。接下來做一些補充。
1）瞭解企業未來發展方向，制定部門級的 OKR
這一項比較特殊，主要是面向企業的管理層級別的。OKR 是互聯網大廠們比較常用的“績效、激勵”工具，一般是由上至下制定戰略，由下自上承諾結果。
作為產品線的管理者，我經歷過研發部OKR制定和落實的全過程。當時還在公告上書寫：我們基於公司的戰略方向，一起自發設定了技術部門的目標。這些目標有挑戰難度，往往需要你付出很多額外的時間和精力，如果 KR 證明無效，會被快速調整、重設。
2）瞭解業務流程、難點，獲取需求優先級判斷依據
最常見的就是針對業務做的需求調研，主要是為了確定業務流程、難點以及排需求的優先級。
在第一篇文章《4000 字總結 | B端產品規劃和 roadmap 怎麼做？》提過 RICE 原則，B 端需求的擇取也是一個不小的話題，大家可以酌情選擇 1-2 套好用的、證實有效的方法論（如 KANO 模型、四象限原則等）去使用。
方法不在多，重點在實踐，都説產品是 10% 的學習 + 20% 方法論 + 70%的實踐。
3）瞭解需求上線後的使用效果
上文講述的一個案例，就是對需求上線後的使用效果做的實地觀察和訪談，不再贅述，也有些產品會在網頁中彈出功能的調研（如墨刀的功能 tips 調研）或者彈出 NPS 評分。
△墨刀的功能tips
三、選取合適的調研方式絮絮叨叨説了不少，明確了需求調研的目標，就要選擇具體的調研方式啦，我們以優勢、不足和適用場景來拋磚引玉。
1. 調研問卷1）優勢
能快速的蒐集大量的用户反饋。
2）不足
- 問卷發放的渠道成本高
- 蒐集來的問卷有效性低於其他調研方式，需要進行多輪數據清洗、分析
3）適用場景
創意初步驗證或者需要大量的結果反饋、大樣本的數據分析時使用。
2. 焦點小組1）定義
是收集信息和資料的一種重要方法，是通過召集一組與研究主題有關的同類人員對某一研究議題進行討論，得出深入結論的定性研究方法（MBA智庫）。
2）優勢
與頭腦風暴有異曲同工之妙，容易激發大量想法，能夠短時間內快速蒐集到大量信息。
3）不足
- 對主持人有很高的主導會議的要求，需要有結構性的提問，在有效的時間內討論到所有的問題
- 選取的樣本量小，討論的結果有侷限性
4）適用場景
有主題性的問題的自由討論、測試新概念或者產品的可用性時可以使用，人員可來自於各個專業、業務方向。
3. 頭腦風暴1）定義
可分為直接頭腦風暴法（通常簡稱為頭腦風暴法）和質疑頭腦風暴法（也稱反頭腦風暴法），前者是在專家羣體決策儘可能激發創造性，產生儘可能多的設想的方法，後者則是對前者提出的設想、方案逐一質疑，分析其現實可行性的方法（MBA智庫）。
2）優勢
類似焦點小組，常有天馬行空的想法和驚喜產生。
3）不足
對發言者的專業素質有一定的要求。
4）適用場景
- 個人理解頭腦風暴和焦點小組的區別，主要在於聚焦於問題去發散還是天馬行空的發散
- 我們在實踐中會通過參與的人員來決定使用焦點小組或者頭腦風暴。通常對於職級或者資質比較接近的專家，如產品小組，需要大量的想法和創意的時候，我們會採取頭腦風暴。
焦點小組與頭腦風暴都是比較成熟的定性研究方式，市面上有很多案例可以查詢，筆者不敢自稱專家，僅在此拋磚引玉。
4. 用户一對一訪談1）優勢
深度訪談效果明顯，避免用户在羣體討論中被帶偏，隱藏自己的真實想法。
2）不足
- 對產品經理的知識儲備、業務認知深度要求較高
- 調研結果受被調研人員的表達能力、業務素質的影響
3）適用場景
適合對資深業務專家、中層管理者，在安靜、隱私性相對較好的環境中使用。
5. 輪崗實習1）優勢
- 產品經理能深入到業務一線，發現實戰中的業務痛點
- 和一線業務人員建立起良好的同事關係，有利於需求上線後的推廣、運營
2）不足
調研成本高，人員緊張的小企業並不太支持這種方式。
3）適用場景
“激勵相容”，支持產品經理深入一線的企業管理理念和願意進入一線實習的產品經理，兩者配合才能取到效果。
以上介紹的調研方式並非互相沖突的，有些場景下，比如從 0-1 的項目規劃時，可能需要選擇各個部門的業務代表做焦點小組訪談，然後就具體的業務問題做一對一的用户訪談，在有條件的情況下還需要產品輪崗、實地體驗，需要根據場景靈活選擇調研方式。
對於複雜度比較高的業務，還需要進行多輪調研、訪談才能梳理出完整的產品規劃來。
最後總結一下，快速開啓需求調研的方式：
- 有效溝通，對信息去偽存真
- 明確調研的目的，以及提前準備調研大綱
- 選擇正確的調研方式
本文由@RaRa 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於 CC0 協議。