需求分析是產品經理的核心技能，網上有很多從需求收集到需求落地的理論，但是如何從實例出發剖析要點，如何保證自己的產品設計思路全面嚴謹，幾乎沒有可以參考的文章。在這裡我總結下自己填坑后總結的經驗，藉此拋磚引玉~
目錄
需求收集
為什麼要加入這一步呢？一是為了展示需求分析的全流程的每一個步驟，另一個是產品要關注需求收集的用戶角色和場景，這會跟需求分析直接產生聯繫。
- 競品分析。假如你是從0開始的產品，可以最大減少試錯成本的方法就是去看各類競品，不過這種方法有一個很核心的要點就是產品經理要保持自己的判斷力。所以同樣是產品經理去學習競品，初級的可能是有什麼抄什麼，高級的知道什麼功能最適合自己再抄過來，再優化下交互形式。還有個比較傻但是比較有效的辦法是，就是統計所有競品涉及的功能點，篩選出通用的。
用戶反饋。用戶反饋來自很多方面，比如測試、運營等，但是有時候他們是站在自己的角度去思考問題，所以產品經理很難做出判斷，這時候可以運用一些需求利器，比如卡諾模型。
業務需求。B端業務方就是老大，很多時候客戶可能是基於某個地方想做這個功能。客戶覺得某個欄位里的欄位值排序不符合閱讀習慣，就會提出自定義排序欄位值的功能，這時我們都會把客戶提出問題看的報表要過來，至於為什麼，留個懸念。接下來，我們就這個需求進行示例來進行需求分析。
需求背景
角色：決策層
場景：某次客戶表明在看報表時更關心「是否諮詢」的「是」多於「否」。
功能：可以對當前圖表某個欄位設置欄位值排序功能，將欄位值「是」排在欄位值「否」前面。
需求拓展
通過需求分析我們大概可以構思出滿足用戶需求的交互界面，但是這樣就夠了嗎？ 因為用戶這次基於功能點的某一方面提出需求，你滿足了，下次基於功能點的另一方面提出需求，你就懵逼了，上次設計界面的交互形式根本無法容納這次的需求，這時候你又要完全改變交互界面和交互形式。所以雖然都只是做一個功能，有一做一的產品和由一想到二三的產品是完全不一樣的境界，思考全面的產品會知道未來產品發展形態，從而在產品設計中留下拓展性，避免下次加功能點需要改造界面甚至系統。
那很多產品就擔心了，要是我經驗不足真的想不到呢？那就可以去看競品了。業內很多都是傳產品經理就是抄競品的，但是這並不是一件丟臉的事，有東西可以借鑒，你可以避開前人踩的坑（競品公司砸了那麼多錢，請了那麼多大牛，迭代那麼多次幫你踩的坑。。。）。但是抄要建立在這個產品有足夠的判斷力的基礎上，不要為了抄襲而抄襲，在下面一點就會感受到。
基於自定義排序的功能，筆者如饑似渴地去看了一堆競品。
BDP個人版-數據表級別排序
BDP個人版-圖表級別排序
大數據魔鏡-SQL執行錯誤
數據觀-圖表級別排序
不出所料，還是BDP的功能比較全面，其他的有這個功能的競品寥寥無幾，有這個功能的競品其中一個還有問題。。。不過大部分的產品經理到了抄完競品這一步就結束了，所以這也是產品經理經常被人指責就是抄競品的原因，要讓自己的思維更進一步的方法是：
歸納競品規則，思考競品這麼做的原因。
從競品中了解到自定義排序分為數據表級別排序和圖表級別排序。
數據表級別排序：排序規則對用到這份數據表的圖表都生效。
圖表級別排序：排序規則只對當前設置規則的圖表生效。
為什麼會有這兩種呢？因為一份數據表可能用於做多張適應不同主題的圖表。所以用戶可能對數據表進行統一排序來規範所有圖表的欄位值排序規則，也可能是某張圖表的特殊需求而暫時性改變該圖表的欄位值排序規則。根據業務場景，優化競品的交互體驗。
很多人都覺得參考完競品就完事了，沒有去想競品的交互體驗是不是可以優化，比如本來是三步操作簡化成一步就好了，頁面是否可以更友好等等。像是對於參考的bdp交互形式，我覺得已經很完美了，不過之前專門總結過表單設計，所以我稍微改動了下按鈕的位置。根據自己的思考，能對競品有所補充。
最後一步也是比較難的，當你在設計一個小產品，參考的是BAT的產品時，你會覺得自己沒什麼可以補充的。。。就像我做數據分析類產品，每次看別人家的產品，我都覺得競品的場景覆蓋已經很全面了。但是你要相信，沒有什麼是絕對完美的，等你有一天你發現一個他們沒考慮到的點，你的成就感也是double的。基於這個點筆者在「需求挖掘」中進行深入闡述。
需求挖掘
每個產品中，都有一個特殊要考慮的要素，像是BI中欄位類型和表的結構等要素對產品設計會產生影響。
在BI裡面欄位類型分為文本欄位、數值欄位、時間欄位，對於相同的功能，欄位類型不同也會展現不同的界面。比如同樣是篩選器功能。不同欄位類型的欄位篩選是截然不同的，文本類型的篩選包含文字的模糊匹配，數值類型則是包含具體數值篩選，時間類型需要調用時間相關的設置。
文本類型
數值類型
時間類型
文本類型中還要分出普通結構和層級結構，為什麼文本類型中特意劃分出這兩大類？因為普通結構中的各欄位沒有關聯的，層級結構中的欄位與它的上一層級和下一層級都會有關聯，比如省份欄位上一層級是國家欄位，下一層級是地區欄位。
普通結構
層級結構
行政區欄位-自定義排序
像這個需求還有個要考慮的點，因為欄位類型的緣故，自定義排序是分為全局排序和局部排序，普通結構是要全局排序，層級結構則需要局部排序，比如帶層級結構的行政區欄位。
杭州只有與溫州、湖州這些同省欄位值互換排序位置才有意義，如果僅僅是設計的那樣（全局排序），將杭州移到福州上面，他們分別歸屬於不同省時，這樣的排序是毫無意義的。因此這類欄位必須建立在上一層級的基礎上進行自定義排序的，即只能局部排的。
行政欄位只是層級結構中的一種，可能你說帶行政區欄位的數據並不是很常見，並不是的，可以看看下列數據，就可以聯想很多相似場景了。二級分類是要在一級分類的前提下進行自定義排序，比如營養成分只需要與一級分類是營養保健下的二級分類的各成員（保健器械和營養健康）進行排序。
層級結構
需求規劃
由此我們可以看到這個需求其實是分為：
1.數據表級別，只能全局排序。
2.圖表級別，其中分為全局排序和局部排序。
頁面布局
Q1：為什麼數據表級別不用分為全局排序和局部排序？
因為綠色框中擺放多個欄位才可以建立欄位的層級結構，可以進行局部排序。而黃色區域的欄位都是獨立的，無法與其他欄位建立層級結構，所以只有全局排序。
Q2：為什麼不是如下排序？
1.全局排序，其中分為數據表級別排序和圖表級別排序。
2.局部排序，只能圖表級別排序。
因為是當初我們頁面布局的屬性決定的，圖表設計里左邊的欄位列表都是代表在數據集中永久加一個欄位，對所有引用該數據表的圖表都會產生相同設置。中間的代表只在對當前圖表的設置，另一個圖表可以用其他的設置。所以建立在原有系統結構上，我們按第一種分類進行劃分功能屬性。
Q3：同時存在數據表級別排序和圖表級別排序怎麼處理？
圖表級別的排序優先順序大於數據表級別排序，因為圖表級別相當於個性化定製排序，數據表級別相同於通用排序。
因為是B端產品，所以我們比較好分析功能優先順序。在開發時間有限的情況下，先滿足客戶提出需求的這張報表即可，在後期迭代時再完善其他功能，並要給後續功能留有拓展性。還記得為什麼要分析用戶角色和場景、以及展示圖表嗎？
1.因為用戶角色是決策層，僅對自己查看的圖表有需求，而不是對數據表進行規範管理的執行層。所以確定先上「圖表級別排序」。
2.該張圖表沒涉及層級結構，所以先上「圖表級別-全局排序」，再上「圖表級別-局部排序」。
3.最後業務量較大，需要自定義排序的圖表需求增多時，再上「數據表級別排序」。
所以迭代順序是：1.圖表級別-全局排序；2.圖表級別-全局排序；3.數據表級別排序
需求設計
根據確定的功能進行交互，要給將來迭代的功能留下入口。
圖表設計
一期：圖表級別-全局排序。在綠色區域點擊「自定義排序」彈出設置框。
一期：圖表級別-全局排序
二期：圖表級別-全局排序。一期的功能入口不變，只需要在彈出框上加上可切換的標籤。
二期：圖表級別-全局排序
二期：圖表級別-局部排序
三期：數據表級別排序。二期的功能入口不變，只需要在黃色區域增加功能入口，彈出該設置框。
三期：數據表級別排序
在這裡展示三期完成後的自定義排序交互稿
需求說明
以三期完成後的完整交互稿，書寫規範。
圖表級別-全局排序
圖表級別-局部排序
數據表級別排序
需求驗收
產品將產品方案交付后，需要跟進需求的落地，是否產出物符合自己的設計。
操作：將「營養成分」移到「保健器械」前面。
排序前
排序后：數據表級別排序
排序后：圖表級別-全局排序
排序后：圖表級別-局部排序
question：為什麼圖表級別-全局排序在排序后很多已合併單元格會被拆開，你是不是有一絲錯亂？
總結
應用場景豐富性
數據的不同應用場景決定了很多功能，比如自定義排序其實涉及這麼多種應用場景。設身處地地去思考各個應用場景，這樣你的思維能力才會有所進步。功能拓展性
很多時候你做一個功能，要想到這個功能最完善的時候是什麼形態的。這樣，即時你現在上一個簡單的版本，下次迭代也不會對系統有太大的改造。思考全面性
在產品設計中，有意識地鍛煉自身的邏輯縝密性。我經常忘記新增或修改的功能對其他模塊產生的影響，也不斷地根據產品自查清單一遍遍地提醒自己，雖然我現在還是有時候會忘記，但是至少我比昨天的自己更好了。
建議
多多跟開發溝通學習
有技術背景的人邏輯能力比較強，所以對於開發的建議，產品人員應該大力鼓勵（如果是不負責的開發，完全可以說什麼做什麼，而不會去提還缺什麼）。一個產品永遠不可能把所有的細節考慮到，只有這個團隊所有人從自己的崗位角度思考問題，才會盡量避免錯誤，而產品人員不能太過強勢去扼殺這種良性循環的可能性。倒推競品產品文檔
很多人會去問怎麼學習，看什麼資料快速了解產品，我的建議是去看優秀競品的幫助文檔，不斷去玩他們的產品，然後倒推他們的產品文檔，這樣你會發現你進步的特別快。在這裡推薦一篇文章倒推「餓了么」App產品需求文檔
- 完善知識體系
定期的總結，可以幫助你建立自己的知識體系，不斷地補充自己的技能短板，在這裡推薦產品知識體系框架
參考資料
PS：這裡是以bdp做示範來加功能，所以根據bdp的產品特點（比如頁面布局的屬性）和交互形式而進行交互設計。不同產品要加上這個功能肯定入口和交互形式也不同，本文僅供參考，有些地方我還沒細講，還是有很多門道的，或許你在深入思考後會發現另一片深淵···
作者：安琪Angela，公眾號：idatadesign。互聯網數據行業PM&UX，參與過數據中心，商業智能和數據分析平台等產品設計。關注大數據、人工智慧和互聯網金融。歡迎大家一起交流~