起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識需求從何而來，又將如何解決？
西游記中的唐僧說得較多的一句話：我從東土大唐而來，前往西天拜佛求經。這句話涵蓋了我從哪里來，要到哪里去以及做什么。同樣需求從哪里來？有該如何解決需求？
我相信做產品的人都知道以下兩個故事：
故事一：
某富翁想要娶老婆,有三個人選,富翁給了三個女孩各一千元，請她們把房間裝滿。
第一個女孩買了很多棉花，裝滿房間。
第二個女孩買了很多氣球，裝滿房間。
第三個女孩買了蠟燭，讓光線充滿房間。
最終，富翁選了胸部最大的那個。
故事二：
福特：你想要什么？
用戶：我想要一匹更快的馬
福特：為什么你要一匹更快的馬？
用戶：因為我想速度更快一些，好節省時間
福特：我造了個東西，叫汽車，比馬快多了
我們經常會用這兩個故事來闡述關于抓住用戶需求的重要性。而關于需求的前世今生，關于用戶是否會用一些冠冕堂皇的理由來達到自己的目的，我想用一篇文章盡量把需求說得透徹以好檢驗自己幾年來對于需求的理解。我將以需求現狀與原因、來源及獲取方法、獲取之后如何分析、如何驗證的邏輯線進行梳理。
前方干貨預警，如果你是銷售人員、產品經理，需求分析師，或者是你想往這幾方面發展的人建議收藏，因為文章較長，可能需要10-15分鐘。
1、關于需求實現的現狀以及原因
現實工作中，有各種的原因導致需求無法實踐，比如銷售人員提出了許多的需求最后都不了了之。有各種原因導致PM與程序猿開啟撕逼大戰，比如前幾天網上看到的PM與程序猿的撕逼上升到辱罵、人身攻擊的地步。
那阻礙需求的實現的絕大部分原因是什么？我歸結為兩方面：
- 一個是需求本身的問題
- 一個是溝通的問題
需求本身的問題
1、需求的不完整
比如PM跟UI說：這個圖標不夠顯眼，重新設計一下。 比如銷售跟PM說：有客戶反映我們的產品不好用，后面的產品你改進一下。很多這樣不完整的需求，我們不知道對方真正要表達的意思是什么，所以經常導致需求不了了之。那么問題來了，什么樣的需求才是完整的需求？其實這個很難去界定，因為只有用戶自己才是驗證需求完整性的最合適的人。確保溝通需求時雙方對于需求的認知無歧義并在實現過程中無其他因素變更的需求是完整的需求。相關人員在提需求的時候盡量從各個層面來考慮，從大的框架、業務流程、實現目的等方面來講需求描述清楚。比如圖標的配色與整個的風格不符或者這個地方的重點是突出圖標，需要將其他地方的設計淡化，將圖標的飽和度提高。比如客戶反映在執行某項任務時發現我們產品的這個功能隱藏太深無法找到等（舉例不一定對）。
2、不切實際的需求
我們經常會聽到，這個產品要是有某某功能那就牛逼了這樣的談資?！拔乙焐系脑铝痢边@樣的大部分需求都是不切實際的需求，至于如何定義不切實際的需求？不切實際的需求不僅僅是指那些不能實現的需求，也指那些小眾或者沒有應用場景的需求。。
3、缺乏站在用戶角度思考的需求
比如做婚紗攝影行業的O2O。當然導致這種行業失敗的原因有多種，低頻、用戶的獲取、轉化等等。但歸根結底還是自己YY出了一大堆的需求，而這種需求脫離了用戶。需求的真偽我們放在后面來說。
4、需求的頻繁變更
需求的頻繁變更導致在處理的過程中忘記初心，最后需求的實現就變成了另一個話題。
溝通的問題
1、溝通的變質
相信大家有聽說過西點軍校的一個故事：
這個故事就反映出了在溝通中需求變質的問題，這里我不再贅述。
2、項目經理或執行人員的控制
由于需求在實現的過程中會涉及到整個項目的時間進度、成本預算、或者優先級等問題。項目經理或者執行人員會在這一過程將需求進行控制，比如擔心拖延整個進度選擇將需求的主要部分實現或者將需求放在下一個版本實現等狀況也是阻礙需求的實現原因之一。
3、程序猿的斷章取義
程序猿在實現的過程中將需求進行技術加工，將原本的需求斷章取義做成另外一種的結果。大家應該有聽過肥皂盒的故事：為了區分空的肥皂盒與裝了肥皂的肥皂盒，一群博士生在討論做一個這樣的機器需要怎么來實現，而實際上只需要一臺風扇即可。
以上說的涵蓋了造成需求不能實現的大部分原因。當然這些都是表象，據其本質原因離不開利益沖突、工作量的增加，而這是另一個層面的問題了。
二、需求的獲取及方法
西游記中的唐僧說得較多的一句話：我從東土大唐而來，前往西天拜佛求經。這句話涵蓋了我從哪里來，要到哪里去以及做什么。同樣需求從哪里來？
內部來源
1、領導以及同事，或者自身挖掘
一般一個公司只從事一個行業（如果多個行業，那就將同事局限在同行業），同事基本上是行業中的精英，他們能夠對產品提出一些獨到的見解和思考，從他們那里去探尋會得到一些意想不到的反饋。
2、自身挖掘
可以關注行業的一些動態、數據等報告，常見的幾個統計報告網站：企鵝智庫、易觀智庫、艾瑞咨詢。也可以通過自己分析競品來挖掘。
外部來源：用戶或者客戶、合作伙伴。我們可以通過接觸到最終的用戶來了解他們的需求。用戶通常會用語言、動作、表情來反饋他們的真實意圖。但基本上用戶能說出來的需求只是基本的需求，更深層次的需求需要我們去挖掘。
了解了來源，如何獲取？
內部來源的獲取方法：
- 對于領導跟同事，需要有針對性的問題提問或者頭腦風暴。這個跟用戶訪談有點類似。
- 對于一些行業上的數據我們可以在大方向上引用數據。對于競品分析出的需求，可以借鑒參考。
外部來源的獲取方法：
- 用戶訪談。用戶訪談是現在的一些公司比較常用的手段，因為這種方法比較有效并且靈活，能夠根據現場情況進行應變。但是占用的時間也相對較長，信息的存在也片面。這種方法的要點是注意人群的選定以及需要注意訪談的技巧，涉及到話術及心理方面的因素不在這里分析。
- 問卷調查。問卷調查的好處是調查面比較廣，可以涵蓋不同的用戶群，但是這種調查不能深入。這種方法的要點是需要注意問卷的設計。
- 現場觀察。有句話說百聞不如一見，但是這種方法太耗時間。要點是需要有洞察用戶行為舉止能力的人執行。
以上都是關于需求得來源及獲取方法，整個需求獲取的過程，執行人員應該都要去主動獲取，針對性的制定計劃。至于每一個方法的實施步驟及要點，比如在訪談的時候需要注意用戶有夸大事實的心理、有抗拒的心理等等這些需要在執行的過程中不斷優化和提升。（如果步驟與要點一一寫上，那可以成書啦!）
三、分析需求
當四面八方的需求匯集到一起時，這些需求的走向我們該如何處理？
篩選
這一步的作用是確定哪些需求是確定要實施的。
1、將不切實際的需求丟棄
不切實際的需求定義前面已經提到：不切實際的需求不僅僅是指那些不能實現的需求，也包含那些小眾或者沒有應用場景的需求。我們也可以稱其中的一部分需求是偽需求，如果你不能通過應用場景來判斷其真偽性，沒關系，我們后面還會講到如何來驗證。
2、將與定位背離的需求丟棄
這里講的定位包含市場和產品的雙重定位。不是針對產品的目標消費市場的需求、不是產品的目標人群定位的需求都稱之為與定位背離的需求，我們應該將這些需求丟棄。之前我在做一個視頻流網關產品的時候犯的一個錯誤：有用戶反饋需要有輪播的功能，而我當時認為可以考慮，而實際上這個功能與產品的定位不符。
分級
這一步的作用是確定需求什么時間點做。
需求篩選出來之后，需要對需求進行分級。
劃分需求的優先級有多種方法：四象限法、商業價值與用戶體驗法、風險-價值法等等。我這里就拿常用的四象限法進行分析，如下圖。
問題來了：如何界定緊急跟重要？
需求的緊急從大方向上應該要根據產品所處的階段來考慮。產品的起步階段的重點是核心功能的實現，驗證產品的可行性。產品的發展階段重點是功能的擴展和完善，需要做的是探索新的價值。產品的迭代階段重點是用戶體驗的提升。在不同的階段，需求的緊急度衡量的側重點是不一樣的。
大方向上考慮了之后，同一階段的需求又如何進一步細分排序？這里應該考慮需求在實現上面的時間緊急程度，通常以其影響程度來衡量。如A需求再不處理，會影響50%的用戶操作，影響程度惡劣，所以較為緊急。
需求的重要性從宏觀角度看應該是根據需求對于用戶的驚喜度來定。KANO模型中的三種需求：基本型需求、期望型需求、興奮型需求。我認為這三種需求的重要性為：基本型需求＞期望型需求＞興奮型需求。因為對于用戶基本的需求如果不滿足，這會引起用戶的不滿，這直接決定了用戶是否繼續探索你產品的其他功能。期望型的需求屬于錦上添花，而用戶興奮型的需求如果滿足了則會給產品增添不少好評與魅力。
再詳細一點，如果篩選除了一堆重要的需求（同一宏觀層級），又如何給重要性排序？這里我們可以根據需求的使用場景來決定：用戶在什么情況下會涉及到該需求。說白了就是這種需求涉及的使用場景的多還是少來決定。
跟蹤與管理
我相信大家都有各自一套管理方法，這里我也不拿出自己的管理與跟蹤表格說事了，因為我的也不一定是好的或者是對的。
這里僅說一下管理與跟蹤的要點:應該要包含需求源頭，是誰提出？在什么場景下提出的即需求的描述詳情？該需求的優先級如何，排在什么時間點做？處理該需求會影響那些因素？后續的計劃是什么樣的？
四、驗證需求
如果前面的三步都做得比較好，那其實第四步就相對很容易了，只需要將處理好的需求（產品）再找相應的用戶確認就好。但就怕前面三步都沒有處理好而且也不做第四步進行驗證就將產品投入市場，那會導致很多的問題。就像一個生意在沒有確認是否可復制的時候就進行了盲目的擴張一樣的道理。
需求的驗證方法有很多，比如AB測試、比如定性定量分析等。具體用哪種方法，具體問題具體分析，下面我講述一下較為通用的方法。
《四步創業法》里告訴我們如何來驗證一個產品，其實也可以把方法應用到需求的驗證上：將處理好的需求找特定的用戶，看是否解決他們的實際需求就好。這里我們不談論是軟件產品還是硬件產品，方法都一樣，只是周期長短不一樣罷了。但是問題來了：我們上面說的通過問卷得來的需求，這些都是基于當前的市場來做的，適合于成熟的行業，那非成熟的行業如何驗證？
- 用最快的方法做出原型，這個原型可以只包含核心的功能。
- 找到在這個行業的精英以及有創新意識的客戶試用。這里為什么要有兩種人群，因為行業的精英有可能也比較墨守成規。
- 收集通過使用之后反饋出來的意見再講原型改進，然后再找與產品定位的目標人群進行廣泛測試。
以上，包含了一個需求的整個生命周期，這個周期我花費了差不多兩年時間才對其形成一套完整的認知。如果你讀到了這里，請反思一下這篇文章是否對你有所幫助。如果有不對的地方，歡迎指出，不勝感激。
本文由 @筆尖輕觸 原創發布于人人都是產品經理。未經許可，禁止轉載。
撕逼這事常有，一般還是需求沒有進行系統的爭論，沒有抓住重點，然后就扯各種需求，程序員不行，項目經理也不行，感覺程序員缺少大局觀，太鉆細節，項目經理太水，根本不懂系統邏輯，也不能把意思很好地傳遞給程序。
我的微信公眾號：筆尖輕觸，歡迎大家與我討論產品相關的知識或者是互聯網行業的問題思考。
已經關注啦。