本文結合了筆者在產品行業工作的微薄經驗，整理出從需求收集—需求整理—需求分析的方法論，未必會適用於所有的互聯網工作流中，但希望系統性的思考過程可以幫助理清思路，在繁雜的需求中找到那個破局的線頭。
在進入具體的分析前，我們要知道， 什麽是需求？
首先要明確的壹點， 需求不等於需要。
需要是因某種“缺乏”而產生的物質需要和精神需要，例如，我想要吃飯，這是壹種物質需要。我想要開心，這是壹種精神需要。需要是結果型的指向，而且可能會因為各種因素而不斷變化和發展。
而需求可以當做更為具體的需要，要有具體場景具體人物。滿足需求可以當做壹種可行的選擇，在互聯網的語境下就是，要在什麽場景下，解決了什麽人，的哪些問題。核心關鍵在於解決問題。
例如，我想要吃飯，但是沒有工具，問題產生了，這個就是需求，為了解決這個問題，我們可以提供多種選擇，筷子，勺子，叉子等等，而哪個選擇是真正能滿足需求的選擇，哪個工具能滿足吃飯的這個需求？這個可能又要具體分析，為什麽想要吃飯？在哪吃飯？是誰在吃飯？等等，這些就後文再提到了。
由此可以看到，當面對需求的時候，要警惕它是不是個需求，也要將需求的顆粒度拆解到盡可能的細，只有把需求的顆粒度變細，我們才能做出滿足需求的產品，當妳想從“我想吃飯”這個高度去滿足用戶，而不去分析裏面的原因，很有可能發生的是，用戶只想要個餅，妳卻給了個滿漢全席，成本無限高，這的確是壹種選擇，卻未必是分析後的最優選擇。
在需求收集的階段，並不需要對需求進行歸類或者分析，重要的是將需求在避免收集人主觀意識的影響下，完整的收集起來。
收集需求時壹定要真實、客觀的記錄需求提出者的描述，包括需求背景，產生原因，具體期望等等，以便後續分析時做到可追蹤，可體驗。
可追蹤即可以再次找到需求提出者，針對不清晰的地方進行溝通，因為很多時候，需求收集人和產品設計人未必是壹個人，需求可能由客服，市場調研，銷售等各處收集而來，所以需要盡可能避免需求在轉述中產生的理解歧義，在有不理解的時候也可以找到需求提出者進行再次溝通
可體驗即對於需求發生的場景及問題，可以復現並再次體驗，方便產品設計人真實體驗理解需求或找到準確的目標用戶群去驗證需求。
從需求來源的不同，需求收集有以下幾個渠道：
（1）其它業務部門：此渠道的需求多應用於支撐型或平臺型的產品，例如OA，CRM等。此類需求由於通常是為業務部門的工作服務，所以需求通常都比較明確，但是溝通成本仍然很高。
因為業務部門提供的需求雖然明確，但解決方案未必能真正解決問題，甚至成本還通常較高。此時則需要產品設計人去跟業務部門了解溝通，去了解組織機構，業務部門在組織機構的業務流中處於哪個位置，業務部門的職能職責及工作流程，業務部門的目標及戰略等。
通過了解這些關鍵節點，可以梳理清支撐業務部門的方式，也幫助理解業務部門提出需求的真實原因，然後由產品設計人給出可行的解決方案。
（2）客戶需求：如來自項目投資人，購買產品的用戶等的需求，要去從為客戶達成目標，帶來的價值，提高效率的方面考慮。
（3）老板需求：之所以將這個單拎出來，是因為來自老板的需求在產品經理的職業生涯中是不可避免的，如果不正確對待老板的需求，甚至會打亂產品正常的叠代節奏。所以要去了解老板需求的來源，是由於公司戰略，商業價值，還是體驗中產生的需求，或者是看了下其它的文章等。如果是由於公司戰略，優先級通常要放到最高。
（4）測試需求：壹般都是測試中產生的bug或體驗缺陷等，這些需求由於通常來自已經完成的功能或產品，所以考慮下性價比，具體問題具體分析即可。
（1）競品分析：競品分析是產品經理提供新需求的重要渠道，競品分析適用於產品生命周期的各個階段，通過研究競品，可以了解市場動態和競爭對手的產品方案，挖掘出適用於自身產品的需求，也避免新的idea沒有經過系統性的沈澱和思考。
（2）用戶研究：用戶研究也是了解產品，獲取需求的重要方式。用戶研究發展到現在，也已經有很多切實可行的系統性用戶研究方法，用戶研究可以幫助產品設計者了解真實的目標用戶群體和潛在用戶的需求，避免產品設計天馬行空，脫離真實用戶
（3）數據分析：通常與競品分析和用戶研究結合起來運用，也在產品叠代中可以做行為數據分析，通過數據來挖掘出需求點。
盡管需求的來源渠道有很多種，但在處理這些需求的時候，有個***同點就是要去了解需求產生的真實原因。
當產品不斷叠代，各方產生的需求越來越多時，整理需求可以避免需求遺漏，同時梳理清需求的開發周期。
（1）分類：可以按照各個產品設計者在實際處理需求時的習慣分類方法，例如按照功能需求和非功能需求分，按照業務需求，項目需求和用戶需求分等等，筆者通常按照用戶體驗/新增功能/視覺優化/質量缺陷的需求種類分類。
（2）需求描述：包括問題描述，使用場景，用戶痛點和具體功能描述，這裏的問題描述和使用場景主要由需求提出者提供，用戶痛點和具體功能描述可以由產品設計者經過溝通和分析後寫出
（3）需求處理狀態：針對每壹條需求，給出需求處理的狀態，如不處理，規劃中，暫未啟動，開發中，暫停開發，已處理。
（4）需求進度：當需求正在開發階段，可以壹目了然看出各個需求進展到哪個環節及需求的排期，如產品設計，技術，交互，UI，測試，發布
（5）優先級：對每壹項需求進行優先級判斷，通常高/中/低的優先級已經可以整理需求，具體判斷優先級的方法在後文需求分析的部分提到。
（5）其它：包括功能模塊——需求是哪個功能模塊的需求，提出時間——需求提出時間，提出者——需求提出人，方便追蹤，版本號——可以為問題產生的版本，也可以為需求解決的版本，責任人/責任部門——對於需求收集人來說，收集到的需求可能需要由多個部門解決。
本篇是需求分析的前置準備，需求收集及需求整理篇，下壹篇則進入需求分析篇，面對收集來的海量需求，我們如何分析需求的價值，可行性和優先級，僅供參考，歡迎各位互聯網行業從業者壹起交流。