起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識實例講解：如何一步步做好需求分析
做為產品經理，口中說得最高頻率的詞就是“需求”，這也是產品人所必須掌握的能力。在這個人人都說需求，談痛點的互聯網時代，作為產品經理的你，是否真的掌握了需求分析的方法和能力？
我曾寫過一篇文章，題為《經驗總結：產品需求文檔的編寫四步法》，此文是我多年產品工作經歷所總結出的一套快速有效的需求文檔編寫方法。相比我寫的其它話題文章，這篇文章發布后瀏覽量，收藏量都非常高，可此可見產品人對需求，對技巧，對實例分享都非常有興趣。為此，本文就再次圍繞需求這個話題作出進一步分享。
在寫需求文檔之前，我們必須先進行需求分析，從用戶需求到產品需求，再到產品功能，最后形成產品需求文檔轉入產品開發。
對于如何進行需求分析，知乎上各路大神們都寫出了高深莫測指導理論，令人膜拜。但這種高度理論化的內容，讓人看完之后，仍然有一種無從下手的感覺。因此，我準備用更直白的實例方式來分享一下我的需求分析經驗。
一、盡可能地讓自己成為用戶
不管你在做任何產品，如果想要做好它，都需要將自己代入相應的用戶角色，從真實的使用者角度去思考問題。
我曾在一家車聯網公司負責智能車機產品，當時我還沒有拿到駕照，所以并沒有駕駛經驗。雖然我對車聯網非常感興趣，但作為非車主，我對此并沒有產品感，在做需求分析時，很難做出合理的判斷和設計。
為了讓自己成為車主，有產品感，我提前去買了輛車（半年后才拿到駕照），雖然沒法上路，但至少有輛車讓自己體驗，甚至在小區的車庫里轉兩圈也是沒問題的。
在后來的一次產品需求評審會上，有位同樣沒有開過車的項目經理提出了一個問題，車機系統界面上為什么沒有關機功能，一直開著多耗電？這個問題在熟悉汽車的人眼里會覺得可笑——因為車機是直接連通汽車電源的，而汽車只要點火后，發動機工作就可以為蓄電池充電，并不存耗完電的問題；而且汽車的部分控制操作是通過車機界面進行的，如果真關機了，就沒辦法操作了。所以車機并不需要關機功能，最多也只是關閉屏幕。
這個問題，在我沒碰到車之前，我也一樣沒法回答這個問題。
還有一些基本常識問題，如開車過程中去操作車機是很危險的，所以車機界面上的觸控區域都做得很大很顯眼，就是為了能實現半盲操作，盡量提高行車安全性。又如，我們車機的各個界面都會顯示時間，而且特意設計得比較顯眼。
那么就有人會問，為什么搞那么多時間，汽車本身沒有時鐘顯示嗎？
還真沒有。
在當時，中低端汽車上大部分都沒有時間顯示功能，而高端車已經標配了較強大的車機，并不是我們車機產品的目標載體。因此，顯示時間這個功能是非?；竞捅匾?。
如果我自己并不是車主，并不開車，那這些最基本的認知就不會有，也很難體會到作為駕駛者的需求。
當然，車聯網產品有一定的特殊性，因為車主和非車主群體有一道鴻溝，非車主很難通過腦補的方式代入車主角色。但的，對于其它產品，如果你能成為真實的用戶，相信你對產品需求的把控會更加到位。
這是做好需求分析工作，做好產品的基礎。
二、傾聽用戶需要，理解用戶需求
很多需求都是直接從用戶中來的，用戶有時會告訴你他需要什么，這個時候，我們會認真聽取用戶的意見。
但是我們并不能只是簡單的接收用戶反饋的信息，而是要去理解用戶內心的真實需求。
在某個項目中，我們在后臺管理中設計了一個訂單管理的功能模塊，用戶（其實是B端客戶，但為了統一，仍稱為用戶）正式使用后跟我們提出說，希望能增強查詢功能，比如訂單多狀態下的組合查詢（目前只有單狀態條件查詢），這樣就可以方便地查詢到他所需要的數據。
咋一聽，會感覺這需求很明確，也很簡單，無非就是把查詢功能增強一下，so easy!
但真的是這樣嗎？
這個時候，我們需要進一步了解用戶的動機。就是：為什么要這么做，目的是什么？
經過進一步溝通，才弄明白了他的目的是：想通過這種操作方法導出所需要的各項數據，然后拿到這些數據進行計算，最終用于對賬，核對賬目是否齊平。
由此可見，通過增強的查詢功能查詢出各項數據，只是一個中間環節，最終的目的是為了拿到這些數據進行對賬。因此，對賬才是用戶的最終需求。所以，如果我們的平臺能自動地計算出各項數據，直接告之用戶對賬結果，是不是更好？
顯然是的。
但考慮到目前業務模式變化快，還不穩定，用于對賬的數據也可能經常會有變化，所以對賬規則還無法固定，并不適合進行系統化。
因此，最終我給出的方案是：新增一個功能模塊，系統按相應的規則自動查詢出當前所需要的各項對賬數據，并以列表的形式展現出來。這樣，用戶只需要把這幾項數據拿出來，復制到對賬所用的Excel表中，再將其它需要的數據填充進來，就可以便捷地進行對賬工作。
此用戶聽到我提出的方案后，表示出非常驚喜的樣子，說道“真的可以這樣？那真是太方便了！”。
通過這樣的深入分析，給出更接近用戶內心需要的方案，結果就能大大超出用戶的預期，這不就是所謂的用戶體驗嗎？
大部分用戶在面對問題時，都會通過自己預想的方案去尋求滿足，這是人的本能——但這只是用戶的需要，通常不會是“用戶需求”。這就是所謂的偽需求，傳說中的“一匹更快的馬”。
這個分析過程，可以總結為what-why-how的求解過程，也就是：是什么？為什么？怎么做？
經過這樣的分析后，真正的用戶需求就能浮出水面。
三、聽聽用戶的解決方案
當我們一邊在做需求分析，一邊在考慮產品方案時，有些時候會陷入困境。
按著自己的思路去思考時，很可能會把事情變得復雜難解。
而在這個時候，我們需要做的，并不是繼續努力思考去攻克難題，而是應該停下來，找我們的用戶聊聊。
某項目，我需要在產品中增加一個汽配商補貼運費的功能。
簡單描述一下背景：我們是做汽配物流業務的，也就是幫汽配商配送貨品到汽修門店，我們會收取配送費；配送費通常由汽修門店支付，但有時汽配商為了讓利，會選擇補貼部分配送費。但我們配送時是按趟收取配送費，也就是說：同一趟車，配送到某汽修門店時可能會有多家汽配商的貨物，也就可能存在多家汽配商同時補貼運費的情況。
這個時候問題就出來了：假如3家汽配商都補貼配送費10元，共30元，而配送費是25元，這時，就會出現汽修門店即使支付0元配送費也還多出5元的問題。
這種情況下，為了賬目清晰，可能需要將這筆多出的錢變為一項收入記錄到系統中。
但這筆錢在業務流轉中又沒有相應的款項與之對應，怎么處理這筆錢卻成了麻煩事。多方思考終究覺得這個處理起來比較麻煩，沒能想到更簡單的方案。
這個時候，我決定找用戶聊聊。
我問道，在沒有系統來解決的情況下，你們現在是如何來處理這種情況的？
經過詳細溝通后知道，原來他們的解決辦法如此簡單——直接將配送費調整為與補貼配送費之和一致，這樣就不存在會多出一筆收入的問題，就只是一筆普通的配送費；這樣賬目也是齊平的，只不過配送費是由汽配商來支付的而矣。
于是，最后的解決方案就是：當汽配商補貼的配送費高于原定的配送費時，則系統自動調整配送費，汽修門店免付配送費。
所以，當我們面對一些不知怎么處理的需求時，不用急于思考如何解決，可以問問用戶目前是如何處理此類問題的。
很多時候，我們自以為能用產品技術的方式更專業，更便捷地解決用戶的問題；但其實更多時候我們會把問題復雜化。面對全新的需求，我應該多和用戶溝通，要相信勞動人民的智慧，很可能會給你帶來意外驚喜。
四、了解需求發生的頻度
面對需求，在思考如何解決之前，我們還需要問多一個問題：這個需求發生的頻度到底有多高？
特別是當要滿足這個需求而要對系統進行改造花費高昂的成本時，我們在考慮產品方案時要所有選擇。
還是上面那個案例：如果用戶所采用的處理方法無法借鑒到系統時，也就是沒有更簡單的處理方法時，我們就會再次陷入思路困境。
而這時，我們更應該問問：這樣的情況發生的次數多嗎？
得到的答案是：很少。
對于這種不好處理，而發生頻度又低的需求，我們應該堅決考慮低成本應對方案。如果實在沒有更好的系統解決方案，那么， 你們最終還可以考慮人肉方案——當這種情況發生時，就自動轉接到人工進行處理，即人工干預。因為人腦更靈活，可以應對復雜多變的情況。
就像我們的客戶電話一樣，一般高頻而標準的需求，可以直接通過語音菜單引導進行選擇操作，這種系統語音與電話按鍵的交互就相當于系統程序來處理需求。而如果系統語音給出的選項都不匹配時，最終你還可以通過選擇人工客服來尋求解決。
但在很多時候，我們無法直接從用戶口中了解到需求頻度的情況，這個時候我們還可以從我們系統數據中分析。也就是利用我們系統中的業務數據、用戶埋點數據、訪問日志等等各種數據，從中提取并進行綜合分析，最終找到這個答案。
有了這個事實數據，如果數據表明頻度確實低，那我們則應該毫不猶豫考慮低成本方案。
五、模擬用戶操作，補全缺失流程
到這一步，我們基本已經完成了需求的分析工作，正式進入了產品設計和需求編寫的階段。
在這個階段，只要我們在前期的需求分析工作做得比較完善，這個過程基本上不需要花費太多時間。
但唯一是需要注意的問題是：避免出現業務流程缺失。
還是實例說明：
我們項目中有一個需求點叫汽配商貨款確認，意思是我們代收的貨款，需要汽配商在系統中核對確認后，我們才會進行貨款的轉賬工作。這個需求我安排了另一名產品經理A同事來負責，跟他描述完大體的需求要點和流程后，他便開始工作了。
沒過多久，A同事便完成了此功能的需求文檔，他發了過來讓我確認。我大概看了一下，用戶（汽配商）端的設計沒有什么大問題，但是在系統后臺管理中卻存在一個不小的問題：后臺管理中，他只做了貨款確認記錄的查詢；當然，還有導出數據功能。因為我當時跟他說過，確認的貨款記錄，我們前期需要在導出數據后用人工的方式進行轉賬操作（因為銀行轉賬接口還未接入）。
我們來分析一下，按著這個功能的操作流程來模擬一下過程：
汽配商在系統中對著未確認的貨款進行逐一核對，然后將無誤的數據進行確認操作；我們的出納人員每天定時通過后臺查詢出已確認但未轉賬的貨款記錄，然后導出，然后根據導出的數據一個個進行轉賬……
細心的同學可能已經發現問題了：如果這樣操作，那么，同一個汽配商下的貨款有多筆；如果按著這份數據進行操作，則需要對同一汽配商進行多次轉賬——如果是這樣，那么我想不光我們的出納會瘋，汽配商也會瘋。
當然，出納可以將導出的數據再合并一下，但畢竟每天這樣操作太過于麻煩，我們需要進一步完善我們的設計。我們可以增加一個功能模塊，直接呈現每天需要轉帳的匯總數據，自動合并同一汽配商的貨款總額，這樣出納人員可以直接拿這份數據進行轉賬操作。轉賬完畢后再回來將這些記錄設定為“已轉賬”，然后系統自動將匯總記錄對應的貨款記錄進行一次性狀態變更。
通過這樣一個過程，就可以將我們的需求進一步完善，最終完成系統流程閉環。
當然，如果我們在前期分析時能夠提早考慮到，則不需要在產品設計階段進行復盤補漏。
六、不忘初心，方得始終
有些時候，我們把產品做到最后，才發現前面始終有一道鴻溝無法跨越。而這個時候，我們可能才會靜下心來思考。也許復盤之后才會發現，我們一開始就錯了。
我在做車聯網項目時，曾負責過一個音樂產品，也就是車機上的音樂APP。我們在做產品需求的時候，商務同事也同步在外部尋找音樂資源，因為我們產品的定位是在線音樂，所以需要海量版權音樂庫的支持。
但是音樂資源的問題卻一直沒有能搞定，主要問題是合作方開出的價格都太高，讓我們無法接受。洽談過好幾家都差不多，因為音樂資源集中度較高，并沒有太多的選擇。等到我們的音樂產品都快要開發完成了，也沒能最后確定音樂資源——這樣就會導致這個音樂產品根本無法上線?？粗虅胀聼o能為力的樣子，我們也很無奈。
在這種情況下，我們不得不思考，能否在產品層面突破這個問題？
音樂產品是為了解決車主開車時聽音樂的需求，我們希望能給車主提供便捷的音樂服務，享受駕駛的樂趣。就像以前就專門有MP3這樣的隨身聽產品，滿足人們隨時隨地的音樂需求；但后面因為有了智能手機，于是被取代了。現在，只要喜歡聽音樂的人，自己的手機里都會有音樂APP，也會存儲一定的音樂，想聽就聽。
想到這里，忽然發現一個問題：我們通過智能手機來獲取音樂已經足夠便捷，對于車主，真的需要一個新的“在線音樂”嗎？我們做車載音樂，是為了解決車主的便捷音樂需求，但并非一定要“在線”音樂。
音樂資源的來源可以有別的選擇，比如可以利用SD卡將電腦上的音樂進行拷貝，還可以利用手機藍牙發送過去——對了，是否可以將手機上的音樂傳送到車機中進行播放呢？比如我們同時開發一個手機APP，用于與車機進行連接，實現音樂文件的傳輸，或者說是同步。
這樣就解決音樂源的問題，而且也比SD卡方式更為便捷。
這種低成本的方案同樣可以解決音樂資源問題，只是稍微麻煩一點點。
從需求角度講，用戶需要的只是聽音樂，而并不是什么在線音樂。在線與否并不是問題的關鍵，只要能聽、方便地聽，這就夠了。
對于用戶需求，我想更重要的是想明白車載環境與普通環境下對于聽音樂這個需求的差異上。比如，我們在長途駕駛時會容易犯困，這時就特別需要一些激情的音樂來提神。而在普通環境下，這種需求卻很弱。對于這點，我們可以從車主在不同精神狀態下對不同類別音樂的需求角度去深入探索，相信通過這樣的挖掘一定可以做出符合用戶需求的產品。
不忘初心，方得始終。只有始終記著用戶的根本需求，才能做出恰當的產品來滿足用戶內心的渴望。
以上便是我自己對需求分析的經驗和理解。這里沒有多少高度化的理論，但如果大家在做需求分析工作時，能用這樣的方式去思考，相信定能做出滿足用戶需求的好產品。
本文由 @星思維 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
很多產品個人無法成為用戶的，比如有些產品是金融機構使用的
你好，文章寫的很贊，請問可以分享轉載這篇文章嗎？
不錯，個人體會讓后來者少走彎路
為了讓自己成為車主，有產品感，我提前去買了輛車。好有錢 ??
實用的技巧，干貨
最后一個案例需求，一個藍牙功能板塊與手機相連會不會更簡單直接。
有思考，不錯！如果光從聽音樂角度來看，使用藍牙連接播放沒有問題。但是，如果想做深度體驗的音樂APP，那這種方式存在很大的技術局限性，無法支撐產品體驗的深度化。
“可此可見產品人對需求，”、“但的，對于其它產品，”請問這是錯別字嗎
抱歉，沒檢查出來。。。是打錯了。由此可見，但是
最后的一個案例，可以藍牙，手機和車載端同步，代替耳機的功能就是了，然后在音源輸出上做些優化，加入一些混響等功能
我一直覺得要有很深的積累才可以做總結，要做很牛逼的產品并且成功后才可以分享，但其實，我們都需要在不斷地反思和復盤中成長，而其中犯下的錯，才是我們最寶貴的財富，對于別人來說也更有借鑒意義~贊一個
是的，有思考，有總結，就值得分享。