編輯導語：在對用戶認知不統一時，團隊內部則可能出現混亂，導致後續業務推進的延後。那麼，我們應該如何做好用戶調研，獲得一手的用戶反饋數據，明確用戶的真實需求呢？本篇文章里，作者總結了一個人也能採用的QTI敏捷調研法，一起來看一下。
筆者從事產品工作一年多，在工作以及和產品朋友聊天中發現，很多需求都會受到各方的質疑，其背後不能簡單歸類為溝通問題，更多的是沒有真實用戶數據的支撐。雖然他們都知道用戶調研的重要性，但受限於資源和環境原因，他們並沒有進行過有效的用戶調研。
筆者通過學術項目學習過較為系統的用研理論知識，但在經歷過實際的從0到1的項目落地工作中發現，產品經理自己就可以一個人用較低的成本進行快速高效的用戶研究活動。
現基於自己的用研經歷總結出了一套自己的方法論，希望能給到各位幫助和啟發。
本文結構如下：
先從工作場景出發，分析需求質疑背後的核心問題以及主要原因，指出了以此導致的項目問題與影響，並提供了解決思路，再基於個人經驗介紹一套可用的可自定義敏捷用研方法，最後提出了需要注意的問題。
一、需求質疑
1. 產品的高血壓場景
立項評審會上，到了提問的環節，領導倚靠在椅背上，雙手交叉，掃了一眼PPT上的用戶畫像，漫不經心地朝你問：
- 「這個需求我感覺不夠痛，如果我是用戶，是不可能需要這個需求的。」
- 「說了很多次，要站在用戶的角度看問題，這個需求別人也知道，你做的就比別人好嗎？」
- 「你這個需求從哪裡來的，經過驗證了嗎？有多少用戶提到過？」
產品狗心中：^ – ^
還不容易你擦著汗熬過了立項，版本需求評審會上，客戶端同事和服務端同事對視了一眼，乾巴巴對你說：
- 「這個功能沒啥用啊？」
- 「我感覺先弄一個XX功能是不是比這個更好？」
- 「這個功能開發難度有些大，我覺得這個版本就別上了，優先級放低些。」
產品狗：^ – ^
……
作為一個產品人，寫到這裡再回憶一下那時的場景，瞬間低下頭看了下手錶上的心率，果然變高了。
2. 需求質疑的實質
很多人會把這些問題歸咎為溝通層面的問題，例如需求的講解不夠簡單而詳細，沒有讓領導和開發聽懂；又或者說是因為「魅力」的問題（？），讓一個妹子產品經理來說可能就更合適了，當然也會有人說是開發的問題，開發就應該老老實實地接需求做事情就行了……
但一年後，兩年後，三年後這種情況還會出現難道也是溝通問題嗎？
現象反映本質，我們需要看到這類現象背後的實質問題：團隊內部對目標用戶的認知不統一。
無論是領導、開發、設計還是運營同事，他們儘管會有意識避免自己的主觀偏見，但或多或少都會基於自己的經驗來解讀用戶，自然導致對需求理解的不一致。
說的不好聽點，他們不信任你的需求結論，甚至有些產品人都無法說服自己相信。
很多中小公司項目所謂的經過分析而得出的需求本身就是畸形的，因為需求結論背後的依據大部分是二手貨。
什麼是二手貨？就是各類行業市場產品報告中的用戶畫像。
大家的檢索能力都不差，拿到同樣的報告數據，最後大多淪為主觀否定主觀之純憑經驗解讀，那麼作為領導、作為同事憑什麼相信你的解讀呢？
當這些數據只有少部分人拿到的情況下，數據才是可貴有效的，通過解讀可以拿到超額剩餘價值，但數據每個人都能拿到的話，那數據就變成了全行業都得到的相對剩餘價值了。
之後就是看能否拿到更為詳細的一手數據，數據越精確越獨立，價值才會越高，解讀才會讓人信服（又捲起來了哈）。
所以，要保證團隊對用戶需求認知的一致，就需要保證基礎的用戶數據是真實有效的，你需要對當前項目的目標用戶進行有效的調研。
二、用戶研究的無
1. 無用研的原因
明白了很多人生道理，但還是過不好這一生。
作為產品人，自然知道用戶研究的重要性，可實際上由於各種原因，用戶研究最終還是不了了之，或者蜻蜓點水而散去。
主要的原因可分為外部和內部。
1）內部原因：產品人的用戶意識不強
產品經理的專業背景一部分是設計專業或心理專業，是有過用戶體驗相關的課程學習和研究經歷的，所以他們的用戶調研意識會比較強，但大多數的產品崗都是跨專業背景更多，尤其是工程技術導向的專業，雖然他們轉行學習過相關的用戶需求板塊，也有基礎的用戶意識，但很難變為行為上的重視。
2）外部原因：公司部門的支持不足
很多的大廠都直接或間接地組建了自己的用戶研究團隊或用戶體驗團隊，但很多的公司是沒有足夠的資源去建立用戶研究部門或者團隊，甚至連用戶研究員都沒有。
大多數小公司，處於成本的考慮，都可能會讓產品經理既要負責互動設計，又要負責產品測試，對於「沒有看得見摸得著的產出」的用戶研究，公司更不會考慮花錢招人了。
產品團隊面對繁多的任務，必定會導致精力的分散，很多人面對用戶研究眾多的耗時耗力的方法望而卻步，就會草草了事，要麼電話和幾個用戶對著問題聊聊天，要麼就直接花錢買一份報告，好一點的可能會聘請外包的市場團隊進行線下的拉人寫問卷。
當然了，還有其他一些眾多原因，就不再一一列舉了，但無論是什麼原因，都不是不做用戶研究的藉口。
2. 無用研的影響
需求，尤其是面對C端市場的需求，都需要花費一定的成本去接觸真實的用戶，需求一旦剛開始就弄錯，後面很多都是做無用功，無論是時間還是人力，都是極大的損耗。
1）影響其一：導致立項評審反覆修改
俗話說，一鼓作氣，再而衰，三而竭。需求部分作為立項的重要一環，如果各方溝通無法達到統一極易引起對立情緒，業務方會陷入反覆修改的時間浪費中。
2）影響二：開發理解不一致，驗收易衝突
在需求評審和技術評估後，項目就進入了開發階段，雖然開發同事明白功能所要實現的整體效果，但他們如果在前期沒有和產品同事保持對功能背後需求的一致的理解，那麼很多的細節就會存在問題，因為對於開發來說，「跑通了就問題不大」，若需要修改的東西涉及到底層的架構，那開發分分鐘要撕了產品。
3）影響三：運營方案定位存在問題，ROI過高
嚴格意義上說，運營部門需要在立項的時候就要參與到溝通中，需要了解核心的需求，方便產品開發的時候他們準備方案的制定。
術業有專攻，方案的制定也是耗時耗力，若雙方對需求和定位的理解不一致，最後投入的資金和活動必定是竹籃打水一場空，雙方又陷入鍋誰背的扯皮中。
所以，前期做好用研，保持各方認知一致，能夠很大程度上減少後續的溝通成本和資金浪費。
三、敏捷式用研
1. 解決思路
那麼，在沒有用研資源的支持下，作為產品經理如何用較短的時間、較小的成本完成有效的用戶研究活動呢？
首先，強化用戶意識。
當對某事物的意識不堅定的時候，只要是個人，他就不會主動去付諸行動，哪怕是嘗試了，一旦遇到他人的勸說或過程上存在困難，便會輕易放棄。
當你正在準備問卷的時候，同事拿著咖啡走過來看了眼說：「這個我之前做過的，沒有什麼用，看看報告就行了。」
當你完成一半的訪談的時候，你發現收集的答覆非常凌亂，你心中是不是想過：「收集一半差不多了吧，就把這些數據自己優化處理下，作為自己觀點的論據就行了。」
如果沒有較強的用戶意識，很難堅持下去。
其次，避免學術，敏捷處理。
商業產品，不是學術研究項目，不要帶有書生氣去看待問題，也不要去追求所謂的完美主義。
功能實現不了，那就降低維度換一種方式來實現。
同樣的，用戶研究本身就是一個龐大的領域，不可能短時間內掌握（除非轉崗沉浸其中），若沒有專業人員的支持下，產品經理只需要系統了解後根據目前項目情況選取合適的方法進行刪減以及恰當的組合即可。
麻雀雖小，但也五臟俱全。
最後，mvp快速試錯，及時調整。
任何一種方法論不可能在初期就能一次成功，作為產品經理一定要在出第一版方案後，先找同事進行快速排查流程問題，再邀請小體量用戶進行預調研，從中發現關鍵問題進行優化，再調整後才可大範圍投入。
方法論並不是一成不變，一個項目結束後，需要針對性進行復盤，在下一個項目中繼續發現問題、優化問題，方法論是隨著項目經驗的不斷增多而越發完善的，會成為產品人的一大筆經驗財富。
2. 定義敏捷用研
敏捷式開發我們知道，那麼什麼是敏捷用研呢？
我們先看下傳統的用研定義：
用戶研究（User Research）是指基於以用戶為中心的設計理念，為了確定用戶需求痛點、提供設計啟發與優化，通過各種不同方法調查研究產品潛在用戶和現有用戶的而開展的研究活動。
用戶研究根據研究的重點，可分為態度和行為研究，根據研究方法的性質，可分為定性和定量的研究。其常見的方法類別有訪談法、觀察法、問卷法、測試法等。
具體的內容介紹就不多說了，很多文章和書籍有較為完善的說明，大家可以自行檢索歸納。
從上可以看到用戶研究方法眾多，有的涉及到非常專業的知識，包含了社會學、心理學等等，甚至一些嚴謹的活動會用到專業級設備，如眼動儀、生理監測等等。
實際上，我們沒有必要（實際上沒錢沒人）做到如此嚴謹複雜，完全可以根據自己的需要進行方法的改造，主要維持其理念核心（道）不變，方法（術）和工具（器）都可以進行調整，這就是敏捷式用研。
個人將敏捷用戶調研定義為：
基於現有項目限制條件下，選取並組合一定比例的結構性方法來對目標用戶進行分批次的疊代式研究活動。
核心一：現有項目限制條件。
需要根據當前項目的進度，計劃好一定的時間和資源支持，如一人力投入一周、資金預算（獎勵、訪談地點等）3000元。
核心二：選取和組合方法。
時間略短的情況下，可將部分定性和定量方法結合在一起進行某一環節的研究，例如個人訪談和可用性測試。
核心三：分批次疊代式。
如果符合條件可配合研究的用戶有限，可以進行分組，例如原本十人的焦點小組，可以分為兩次五人焦點小組，根據前組情況調整下一組的提問內容。
四、QTI法
QTI法是筆者根據自己之前用研經歷所使用的方法的總結，也可以說是敏捷用研下的一個方法模板。
QTI由Questionnaires（問卷）+Test（測試)+Interview（訪談）三個部分組成。
1. 核心要素
1）要素Q：分為問卷調查和主觀體驗量表
問卷在前期可用於篩選用戶群，一方面可以大範圍收集相關的人口學數據，另一方面通過問題的分析可在一群人中篩出適合調研的用戶。
量表主要用於產品測試後的感受量化工作，通過分數來統計用戶的整體感受。
2）要素T：分為可用性測試和協作測試
可用性測試，不僅可用於本項目產品的評估，還可以使用在競品上，幫助發現一些問題，提前避免。
協作測試，如若存在沉默用戶（不發聲思考）或涉及到多人配合使用的產品，可以組織多位用戶進行測試。
3）要素I：分為個人訪談和多人訪談（焦點小組）
顧名思義，訪談對象是個人和多人（狗頭），但一定要分配好活躍用戶或意見領袖的比例。
說了理念，筆者將自己的項目背景作為例子進行簡單使用說明，後續有空再開幾篇文章詳細說下具體的使用流程和操作。
2. 舉例說明
首先大家要明確一點，沒有什麼方法是一成不變的，QTI法並不是嚴格按照順序進行執行，該方法根據項目的不同情況可進行自由組合和適當增減。
我的一個項目背景：
根據公司戰略，負責一個APP從0到1的落地工作，但因為疫情大環境和支持不足原因沒有做過用戶調研，只是根據報告和競品完成了1.0版本的功能開發，測試包出來的時候，我需要組織用戶調研，一方面就是來挖掘用戶需求以便後續疊代規劃，另一方面就是發現APP的使用問題。
方法實例：
1）向上級申請許可並要到了一些獎品。
2）制定了調研主題、流程和時間安排，完成問卷、訪談綱要、測試任務集和量表設計。
3）向相關用戶群發送有償調查動態，從中選取一批合適的用戶，將參與者分成了個人和小組兩個大類，人數比例基本為1:1。
4）抓3位同事進行預先演練，調整內容描述和流程，再邀請2位用戶進行預調研，確保流程無問題。
5）先進行個人調研，流程為問卷調查、APP可用性測試、量表填寫、問題回顧以及訪談（QTQII）。
6）將個人分成三組，第一組結束後快速統計問題，調整完操作問題後進行第二組，此時重點關注第一組提及的問題，第二組結束後統計兩組的共同問題，涉及到APP操作問題的迅速反饋給開發，接著進行第三組，針對共同問題可適當側重。
7）個人調研結束後，將三組的內容進行整理，提取關鍵的共同問題和差異點，以此調整後續小組調研的內容，儘快安排開發完成問題修復。
8）將小組人數分成兩個焦點小組，流程為問卷調查、訪談討論、APP可用性測試、量表法以及回顧法（QITQI）。
9）調研結束後，儘快處理數據統計，遇到疑惑的地方可查看錄製的視頻或音頻，必要的時候可以聯繫相關的用戶。對了，別忘了給每個用戶的獎品。
以上就是我當時處理用研的流程，基本上是按照實際情況進行調整的，例如個人和小組的APP可用性測試環節順序是不一樣的，主要是考慮到焦點小組耗時更長，訪談放在後期不容易進行問題的廣泛討論，放在前期效果更好。
以此類推，假如立項結束，有目標領域報告但無直接競品，打算調研需求，那麼如何處理呢？
方法例：
- 根據市場報告劃定目標用戶所在的用戶群體；
- 發放篩選問卷，招募10人；
- 將10人分為三組（4，3，3），協商好訪談時間，準備流程和材料，並進行預演；
- 對第一組4人發放問卷，根據訪談大綱進行個人訪談，結束後發放獎品；
- 根據第一組得到的回答情況，適當調整問卷和訪談內容，進行第二組；
- 根據兩組的回答情況，取出共同點針對性調整，進行第三組，第三組注重共同點的回答；
- 三組結束後，結合錄像或音頻進行整理，有問題或遺漏的地方詢問相關用戶。
大家發現了，這裡只會用到QI，按照實際情況減去了T的內容。
那麼再比如：產品上線了，但使用流程存在問題，已經疊代了一個大版本，需要驗證流程可用性，那如何處理？
方法例：Q（產品使用用戶）+I（焦點小組收集反饋）+T（可用性測試）+Q（量表），當然嚴謹還是需要一批未使用過的用戶過一遍流程。
……
3. 三個問題
無論大家最後是採用大而全的方法好，還是採取短快的敏捷式也好，在面對用戶提出的需求時，都需要注意三個問題：
- 你所接觸的這個用戶真的是目標用戶嗎？
- 這個用戶所說的就是用戶真實的想法嗎？
- 用戶反饋的這個需要可以直接拿來用需求嗎？
第一個問題，如果做一個遊戲項目，結果招來的人並不是那麼熱愛遊戲，那麼這個用戶說的話就需要打上一個大大的問號了。
第二個問題，在和用戶接觸的時候，礙於情面或隱私，用戶往往會說出自己認為可能合適的回答，這種回答一旦和產品經理的偏好接近，會直接影響到產品經理的後續判斷。
第三個問題，用戶反饋的內容，即「我需要一個XX」、「有一個XX功能就更好了」，這種功能上的回答往往都是基於他們的認知所得出的解決方法，就好比他們想要更快的馬。
作為產品經理不能將用戶所說的需求當作以用戶為中心的聖旨，因為作為商業產品，必定是在商業、需求和技術中取得平衡，產品經理要站在更高的緯度去看待產品，而不局限於一些零碎的說法。
五、結尾
本文從需求質疑現象出發，分析了原因以及解決思路，提供了可供參考的QTI敏捷法，希望大家無論做什麼產品，都能夠切切實實去主動接觸自己的目標用戶，多一些實事求是與變通，少一些僵化和偏執。
感謝你看到這裡，如果你覺得我的文章對你有用的話，歡迎大家在留言區提問和交流，下次有空的話會寫幾篇文章說說具體的實施步驟和方法細節。
本文由 @蘋果核 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於 CC0 協議