產品需求分析：從使用者到需求文件的歷練
產品定位
這是產品設計的方向，也是需求文件和設計產出的判斷標準。
此外，產品定位也是團隊成員形成統一的目標和對產品的認識，提高團隊的凝聚力和工作效率，可以這麼說，產品定位是需求中的需求。那什麼是產品定位呢？
一些產品經理和設計師溝通時候，往往會把功能、業務邏輯梳理得很清楚，但卻忘記了把產品主要面向物件、他們的使用場景如何，還有產品的功能、特色等也說清楚，這就會導致設計師很難做決策。
這裡可以看出，產品定位實際上就是關於產品的目標，範圍、特徵等約束條件，主要包括兩個方面的內容：產品定義和使用者需求。
產品定義由PM得出，使用者需求由UED得出，但這一般只出現在大型專案or有充足團隊配置的情況中，實戰案例更多是PM一手操辦，Orz，三頭六臂的哪（P）吒（M）啊。
其中產品定義中的主要功能、產品特色和使用者需求中的目標使用者形成了產品定位中最核心的內容，是產品設計最主要的依據和方向。
產品定義
產品定義就是用一句話概括某個產品，一般可以這麼說：
該產品主要面向XX使用者提供XX功能，具有XX特色。
這裡可能會有疑問，對於一些全使用者的產品例如微信、淘寶怎樣準確描述呢？這其實有個小小的誤區，對於這些發展歷程已久，業務迭代升級變化較大的產品，現在的意識形態早已不是當初的樣子。微信當初不就是想取代手機簡訊的功能嗎。所以產品定義也是會升級迭代的。
如果你的產品很難用一句話描述清楚，要麼就是定位不清晰、方向不明確，要麼你正在做的是類似微信一樣的超級產品，企圖連線一切。而對於創業者來說，連自己都無法流利簡潔描述你的產品，那麼跟著混的兄弟似乎就要對這個leader多一點存疑了。
舉個栗子：陌陌
使用人群：80後、90後單身人群
主要功能：發展基於地理位置的陌生關係
產品特色：LBS搜尋使用者和群組
有了產品定義之後，可以迫使產品經理努力思考產品的方向和機會，在競爭中尋找差異化，也限定大致的範圍，讓團隊不至於茫然。
使用者需求
使用者需求就是在具體場景中，目標使用者的目標事件。根據一定方法（頭腦風暴、調研訪談等），可以得出使用者需求示意列表。
值得注意的是，使用者型別不是絕對的互斥和獨立，更多是以主要取向為區分標準，這不影響後面的篩選和匹配。
其中目標使用者是最為關鍵的，明確目標人群可以使你更專注於服務某一類特定人群，這樣更容易提升這類人群的滿意度，也更容易使產品做到差異化和成功。
產品是給使用者用的，錢也是使用者掏的。選擇哪種型別的使用者作為目標使用者，需要綜合權衡使用者對公司的價值和潛在使用者量。
通常會優先考慮最右上角的使用者（潛在量大，價值高）。
確定目標使用者型別後，就可以篩選匹配出相應的場景和需求。整個過程包含大量思考和決策，因此產品經理需要做足準備工作，包括：瞭解市場調研結果（趨勢、相關聯行業或者產品的態勢）、瞭解市場上同類產品的情況（競品分析）、瞭解潛在使用者的基本情況、瞭解公司、團隊的優勢和劣勢等等。
需求來源
確定產品定位之後，然後通過不同的方式來收集大量的需求，然後根據這些需求的有效性和真實性、產品定位和專案資源情況進行篩選和匹配，提煉出產品需求，定義出優先順序。從產品定位到需求優先順序，整個過程不僅涉及對使用者的分析和理解，還包括了對產品定位、專案資源的考慮。
需求來源可以大致分為以下幾種，其中競品分析、產品資料、用研是從產品層提出，老闆敏銳的眼光則是“人為”思考的結果。
通過五花八門的渠道收集到一堆需求之後，不可能全部都能做，需要按照一定規則和流程，篩選出來最有價值的需求，將有限的投入產出最大化。
其中有一個較重要的環節，也是考驗PM能力的地方，透過現象看本質，挖掘使用者的真實需求（有個經典的故事：汽車之父亨利·福特曾有一個經典的句子：“如果我問客戶他們想要什麼，他們總是說想要更快的馬。
這裡謹記兩條：
傾聽使用者不等於聽從使用者
使用者想要什麼不等於真實需求
需求文件
經歷完需求篩選和優先順序定義之後，通常可以得到需求列表，負責各個功能的產品經理就可以領任務去寫PRD了（對於一般更新迭代的需求，可能篩選完之後只有一兩條需求，優先順序都不需要定義，就可以直接開寫了）。
下面是標準需求文件的內容示例：
-
文件備案：包括文件日期、版本號、修改人、修改內容和稽核人等資訊，一般以表格形式位於文件開頭。
-
目錄：方便閱讀
-
背景描述：為什麼要做這個產品/模組，市場行情，業務目標，產品定位等
-
使用者型別：簡單地描述目標使用者的情況
-
專案時間安排：啟動、結束等時間節點
-
資訊結構：簡單理解為內容和頁面的層級
-
業務流程說明：以流程圖形式說明業務各個狀態間的切換邏輯（例如：遊戲伺服器滿人時候需要切換到排隊登入狀態）
-
需求說明：每一條需求的詳細說明（包括：使用場景、UI描述、功能描述、優先順序、輸入/輸出條件、處理流程、補充說明等）
-
涉及關聯業務部門的支援，還需要特別備忘。
如同設計稿，程式碼一樣，需求文件很難一次成型，需要不斷修改，在評審中發現問題是很正常的。
需求分析廣義上看包括了需求獲取和分析篩選兩個方面。產品定位是確定產品需求的根本依據，而目標使用者則是產品定位的標尺。要想得到正確的需求，PM需要全程參與，充分準備，深入到各個關節中，並且充分聽取不同成員的意見。
上述方法論是標準化流程，實戰運用，不同公司不同專案會有更接地氣的一套過程，本文謹對新人作分享和啟發之用。需求文件的撰寫同理，引用在京東實習時候，曾經就PRD模版和導師有關一些討論，最後導師給出的意見是：根據需求和進度來靈活變通，切勿迷戀所謂模版。尤其移動網際網路時代。僅以此話與諸君分享。
文章內容提煉於劉津老師和李月老師的《使用者體驗設計師的成長之路》，力薦閱讀原作，之後會出系列讀書筆記，圍繞使用者體驗設計相關話題而談。