產品的日常工作都是圍繞著需求展開的，那么在實際挖掘需求中，需要圍繞著六步走。本文結合服裝供應鏈SaaS系統的一個小功能展開，探討需求的挖掘和解決方案，希望對你有所啟發。

身邊總有同事問，你每天怎么有那么多問題，大概是經常用到5Why法吧。正好最近打算做些輸出，今天就結合日常工作，分享下自己平時如何做需求挖掘。這個也是產品日常工作、求職高頻問題了，希望對看到文章的你有所幫助。全文篇幅2000字左右~

產品日常工作都是圍繞需求展開的，從需求收集、需求挖掘與分析、需求規劃、優先級排序、需求設計、需求評審、需求開發、測試到最終產品上線，一個完整的產品生命周期，需求貫穿始終。前期的需求挖掘與分析至關重要，可以說需求挖掘分析如果錯了，整個產品會錯的離譜、很難挽救。

挖掘用戶需求：自己平時主要是需求調研＋5Why法來結合進行。至于需求調研，了解用戶在什么場景，想解決什么問題，現在遇到的問題和難點，現有解決方案等。所謂5Why分析法，又稱”5問法”。最早由豐田汽車創始人父親——豐田佐吉提出，在豐田汽車制造方法學得到應用，也是常見是問題求解方法，并且在豐田之外也得到了廣泛采用，主要用于根本原因深挖。

在實際挖掘需求工作中，我主要圍繞這6步進行：識別確認需求、需求現狀了解、需求分解、查找要點、把握需求邊界、需求原因目的了解、需求解決方案。結合之前做服裝供應鏈SAAS系統一個小功能進行展開。

一、識別確認需求：明確需求及提出方

公司的種子客戶，XX服裝廠老板提出員工計件功能需求，希望解決給員工發工資需求。

這里特別注意：不論需求大小，所有需求都要明確到具體提出人，而不是轉述方。需求池日常維護中，需要直接記錄具體需求提出人。才能深入調研、挖掘需求，即使初級產品、產品助理，都要注意這點，當然這一步需求還是很粗糙的。

二、需求現狀了解：業務現狀，如何運轉，遇到的問題、難點

這里通過一個業務流程圖來簡單體現，了解到梭織面料生產流程（此處只截取裁剪開始的部分流程）。

這一步通過需求提出方可以初步了解，在后期需求溝通時會逐步細化。

三、需求分解、查找要點

拆分需求，梳理調研大綱，查找要點。我一般從需求涉及的角色/業務方出發，梳理對應業務問題，帶著問題去了解需求和業務。顯然這里涉及的角色有：工廠老板/生產負責人、財務、具體業務人員（流水線工人/小組長/主管）。

業務問題可以通過線上線下了解行業知識、借鑒優秀解決方案、結合自己理解等，通過頭腦風暴的方式進行思維發散。對應到員工計件，顯然需要了解服裝生產流程、MES系統常見解決方案，行業產業都要進行了解。

不推薦上來就貼臉開大直接溝通，業務方自己講述，很容易遺漏關鍵信息、揪著一個點跑偏等，自己很難對問題延伸、思路被帶走。最好帶著梳理好的問題去溝通，先引導業務方自己講述，再根據調研大綱做針對性補充提問。

四、把握需求邊界

需求現狀了解、需求分解查找要點、把握需求邊界，這3步實際操作中基本結合進行。涉及隱私，根據員工計件需求簡單寫了一些調研問題供參考，自己整理只需列出問題即可，溝通完成后對溝通結果做記錄。問題目的可以幫助自己，在業務方理解無法理解問題時，進行問題縱深追問。此處其實還要往業務前后延伸，像服裝行業，條碼生成、打印就考慮到跟裁床單結合了，篇幅有限不再贅述。

五、需求原因、目的了解

通過前邊反復溝通確認，需求原因、目的其實基本摸透了，只要把調研大綱的溝通記錄進行補充提煉。偷個懶這里就略過啦~

六、需求解決方案

在這一步，我一般會先梳理出業務流程圖，需求解決方案，實際的功能點說明等。這一步完成后，會根據實際情況做需求內評（這里根據實際可能是跟CTO、客戶等），再之后才是原型設計，PRD輸出。

1、需求解決方案

這個一般都是思維導圖去梳理，涉及隱私這里把自己做過的多個系統糅雜在一起來貼圖了，結合員工計件簡單寫了一個方案參考。

a、員工計件解決方案

1. 初階：只是系統上簡單做匯報計數
2. 中階：掃碼單件計件
3. 高階：掃包碼計件、合格/不合格數審核、除了業務功能

關聯功能有員工計數統計，計件工資計算，訂單生產進度統計等

b、掃碼方案：哪個環節生成條碼，哪個環節貼條碼，如何貼條碼

2、掃碼方案：條碼需要包含什么信息

通過需求調研、流程梳理，發現員工計件這個功能，計數只是最基礎的需求，還涉及到質檢，所以會有合格/不合格數延伸。不同工序需要技能、加工時間、復雜程度等不一致，所以工價不同，此處了解的信息，就是工序后期可擴展延伸的屬性信息。結合統計相關需求，條碼需要包含產品規格信息、加工時間等。

3、功能點說明示例

涉及隱私，附圖其他的系統功能點說明。這里除了表格，有時候也會用例圖形式展現

用例圖展現形式：

這里輸出的需求解決方案，一般會有多種，最后需要結合實際產品規劃、資源等，綜合考慮選擇現階段最適合的方案即可。前邊需求挖掘也確保對需求足夠了解，當下、未來的解決方案，而不只是埋頭做功能，稍有變動就要重新調整整個設計邏輯，避免對需求知其然，而不知其所以然。市面上已經有太多成熟解決方案了，但是好的產品經理，一定不是只會抄軟件功能。

篇幅有限，就不進行過多展開了，歡迎大家一起探討交流，坐標杭州，歡迎來撩~