需求分析是產(chǎn)品經(jīng)理的核心技能，網(wǎng)上有很多從需求收集到需求落地的理論，但是如何從實例出發(fā)剖析要點，如何保證自己的產(chǎn)品設計思路全面嚴謹，幾乎沒有可以參考的文章。在這里我總結下自己填坑后總結的經(jīng)驗，借此拋磚引玉~

目錄

需求收集

為什么要加入這一步呢？一是為了展示需求分析的全流程的每一個步驟，另一個是產(chǎn)品要關注需求收集的用戶角色和場景，這會跟需求分析直接產(chǎn)生聯(lián)系。

競品分析

假如你是從0開始的產(chǎn)品，可以最大減少試錯成本的方法就是去看各類競品，不過這種方法有一個很核心的要點就是產(chǎn)品經(jīng)理要保持自己的判斷力。

所以同樣是產(chǎn)品經(jīng)理去學習競品，初級的可能是有什么抄什么，高級的知道什么功能最適合自己再抄過來，再優(yōu)化下交互形式。還有個比較傻但是比較有效的辦法是，就是統(tǒng)計所有競品涉及的功能點，篩選出通用的。

用戶反饋

用戶反饋來自很多方面，比如測試、運營等，但是有時候他們是站在自己的角度去思考問題，所以產(chǎn)品經(jīng)理很難做出判斷，這時候可以運用一些需求利器，比如卡諾模型。

業(yè)務需求

B端業(yè)務方就是老大，很多時候客戶可能是基于某個地方想做這個功能?？蛻粲X得某個字段里的字段值排序不符合閱讀習慣，就會提出自定義排序字段值的功能，這時我們都會把客戶提出問題看的報表要過來，至于為什么，留個懸念。接下來，我們就這個需求進行示例來進行需求分析。

需求背景

• 角色：決策層
• 場景：某次客戶表明在看報表時更關心“是否咨詢”的“是”多于“否”。
• 功能：可以對當前圖表某個字段設置字段值排序功能，將字段值“是”排在字段值“否”前面。

需求拓展

通過需求分析我們大概可以構思出滿足用戶需求的交互界面，但是這樣就夠了嗎？ 因為用戶這次基于功能點的某一方面提出需求，你滿足了，下次基于功能點的另一方面提出需求，你就懵逼了，上次設計界面的交互形式根本無法容納這次的需求，這時候你又要完全改變交互界面和交互形式。

所以雖然都只是做一個功能，有一做一的產(chǎn)品和由一想到二三的產(chǎn)品是完全不一樣的境界，思考全面的產(chǎn)品會知道未來產(chǎn)品發(fā)展形態(tài)，從而在產(chǎn)品設計中留下拓展性，避免下次加功能點需要改造界面甚至系統(tǒng)。

那很多產(chǎn)品就擔心了，要是我經(jīng)驗不足真的想不到呢？那就可以去看競品了。業(yè)內(nèi)很多都是傳產(chǎn)品經(jīng)理就是抄競品的，但是這并不是一件丟臉的事，有東西可以借鑒，你可以避開前人踩的坑（競品公司砸了那么多錢，請了那么多大牛，迭代那么多次幫你踩的坑。）但是抄要建立在這個產(chǎn)品有足夠的判斷力的基礎上，不要為了抄襲而抄襲，在下面一點就會感受到。

基于自定義排序的功能，筆者如饑似渴地去看了一堆競品。

BDP個人版-數(shù)據(jù)表級別排序

BDP個人版-圖表級別排序

大數(shù)據(jù)魔鏡-SQL執(zhí)行錯誤

數(shù)據(jù)觀-圖表級別排序

不出所料，還是BDP的功能比較全面，其他的有這個功能的競品寥寥無幾，有這個功能的競品其中一個還有問題……不過大部分的產(chǎn)品經(jīng)理到了抄完競品這一步就結束了，所以這也是產(chǎn)品經(jīng)理經(jīng)常被人指責就是抄競品的原因，要讓自己的思維更進一步的方法是：

歸納競品規(guī)則，思考競品這么做的原因

從競品中了解到自定義排序分為數(shù)據(jù)表級別排序和圖表級別排序。

• 數(shù)據(jù)表級別排序：排序規(guī)則對用到這份數(shù)據(jù)表的圖表都生效。
• 圖表級別排序：排序規(guī)則只對當前設置規(guī)則的圖表生效。

為什么會有這兩種呢？因為一份數(shù)據(jù)表可能用于做多張適應不同主題的圖表。所以用戶可能對數(shù)據(jù)表進行統(tǒng)一排序來規(guī)

范所有圖表的字段值排序規(guī)則，也可能是某張圖表的特殊需求而暫時性改變該圖表的字段值排序規(guī)則。

根據(jù)業(yè)務場景，優(yōu)化競品的交互體驗

很多人都覺得參考完競品就完事了，沒有去想競品的交互體驗是不是可以優(yōu)化，比如本來是三步操作簡化成一步就好了，頁面是否可以更友好等等。像是對于參考的bdp交互形式，我覺得已經(jīng)很完美了，不過之前專門總結過表單設計，所以我稍微改動了下按鈕的位置。

根據(jù)自己的思考，能對競品有所補充

最后一步也是比較難的，當你在設計一個小產(chǎn)品，參考的是BAT的產(chǎn)品時，你會覺得自己沒什么可以補充的……就像我做數(shù)據(jù)分析類產(chǎn)品，每次看別人家的產(chǎn)品，我都覺得競品的場景覆蓋已經(jīng)很全面了。

但是你要相信，沒有什么是絕對完美的，等你有一天你發(fā)現(xiàn)一個他們沒考慮到的點，你的成就感也是double的。基于這個點筆者在“需求挖掘”中進行深入闡述。

需求挖掘

每個產(chǎn)品中，都有一個特殊要考慮的要素，像是BI中字段類型和表的結構等要素對產(chǎn)品設計會產(chǎn)生影響。

在BI里面字段類型分為文本字段、數(shù)值字段、時間字段，對于相同的功能，字段類型不同也會展現(xiàn)不同的界面。比如同樣是篩選器功能。

不同字段類型的字段篩選是截然不同的，文本類型的篩選包含文字的模糊匹配，數(shù)值類型則是包含具體數(shù)值篩選，時間類型需要調(diào)用時間相關的設置。

文本類型

數(shù)值類型

時間類型

文本類型中還要分出普通結構和層級結構，為什么文本類型中特意劃分出這兩大類？因為普通結構中的各字段沒有關聯(lián)的，層級結構中的字段與它的上一層級和下一層級都會有關聯(lián)，比如省份字段上一層級是國家字段，下一層級是地區(qū)字段。

普通結構

層級結構

行政區(qū)字段-自定義排序

像這個需求還有個要考慮的點，因為字段類型的緣故，自定義排序是分為全局排序和局部排序，普通結構是要全局排序，層級結構則需要局部排序，比如帶層級結構的行政區(qū)字段。

杭州只有與溫州、湖州這些同省字段值互換排序位置才有意義，如果僅僅是設計的那樣（全局排序），將杭州移到福州上面，他們分別歸屬于不同省時，這樣的排序是毫無意義的。因此這類字段必須建立在上一層級的基礎上進行自定義排序的，即只能局部排的。

行政字段只是層級結構中的一種，可能你說帶行政區(qū)字段的數(shù)據(jù)并不是很常見，并不是的，可以看看下列數(shù)據(jù)，就可以聯(lián)想很多相似場景了。二級分類是要在一級分類的前提下進行自定義排序，比如營養(yǎng)成分只需要與一級分類是營養(yǎng)保健下的二級分類的各成員（保健器械和營養(yǎng)健康）進行排序。

層級結構

需求規(guī)劃

由此我們可以看到這個需求其實是分為：

• 數(shù)據(jù)表級別，只能全局排序。
• 圖表級別，其中分為全局排序和局部排序。

頁面布局

Q1：為什么數(shù)據(jù)表級別不用分為全局排序和局部排序？

因為綠色框中擺放多個字段才可以建立字段的層級結構，可以進行局部排序。而黃色區(qū)域的字段都是獨立的，無法與其他字段建立層級結構，所以只有全局排序。

Q2：為什么不是如下排序？

1. 全局排序，其中分為數(shù)據(jù)表級別排序和圖表級別排序。
2. 局部排序，只能圖表級別排序。

因為是當初我們頁面布局的屬性決定的，圖表設計里左邊的字段列表都是代表在數(shù)據(jù)集中永久加一個字段，對所有引用該數(shù)據(jù)表的圖表都會產(chǎn)生相同設置。中間的代表只在對當前圖表的設置，另一個圖表可以用其他的設置。所以建立在原有系統(tǒng)結構上，我們按第一種分類進行劃分功能屬性。

Q3：同時存在數(shù)據(jù)表級別排序和圖表級別排序怎么處理？

圖表級別的排序優(yōu)先級大于數(shù)據(jù)表級別排序，因為圖表級別相當于個性化定制排序，數(shù)據(jù)表級別相同于通用排序。

因為是B端產(chǎn)品，所以我們比較好分析功能優(yōu)先級。在開發(fā)時間有限的情況下，先滿足客戶提出需求的這張報表即可，在后期迭代時再完善其他功能，并要給后續(xù)功能留有拓展性。還記得為什么要分析用戶角色和場景、以及展示圖表嗎？

1. 因為用戶角色是決策層，僅對自己查看的圖表有需求，而不是對數(shù)據(jù)表進行規(guī)范管理的執(zhí)行層。所以確定先上“圖表級別排序”。
2. 該張圖表沒涉及層級結構，所以先上“圖表級別-全局排序”，再上“圖表級別-局部排序”。
3. 最后業(yè)務量較大，需要自定義排序的圖表需求增多時，再上“數(shù)據(jù)表級別排序”。

所以迭代順序是：1.圖表級別-全局排序；2.圖表級別-全局排序；3.數(shù)據(jù)表級別排序

需求設計

根據(jù)確定的功能進行交互，要給將來迭代的功能留下入口。

圖表設計

一期：圖表級別-全局排序。在綠色區(qū)域點擊“自定義排序”彈出設置框。

一期：圖表級別-全局排序

二期：圖表級別-全局排序。一期的功能入口不變，只需要在彈出框上加上可切換的標簽。

二期：圖表級別-全局排序

二期：圖表級別-局部排序

三期：數(shù)據(jù)表級別排序。二期的功能入口不變，只需要在黃色區(qū)域增加功能入口，彈出該設置框。

三期：數(shù)據(jù)表級別排序

在這里展示三期完成后的自定義排序交互稿。

需求說明

以三期完成后的完整交互稿，書寫規(guī)范。

圖表級別-全局排序

圖表級別-局部排序

數(shù)據(jù)表級別排序

需求驗收

產(chǎn)品將產(chǎn)品方案交付后，需要跟進需求的落地，是否產(chǎn)出物符合自己的設計。

操作：將“營養(yǎng)成分”移到“保健器械”前面。

排序前

排序后：數(shù)據(jù)表級別排序

排序后：圖表級別-全局排序

排序后：圖表級別-局部排序

question：為什么圖表級別-全局排序在排序后很多已合并單元格會被拆開，你是不是有一絲錯亂？

總結

應用場景豐富性

數(shù)據(jù)的不同應用場景決定了很多功能，比如自定義排序其實涉及這么多種應用場景。設身處地地去思考各個應用場景，這樣你的思維能力才會有所進步。

功能拓展性

很多時候你做一個功能，要想到這個功能最完善的時候是什么形態(tài)的。這樣，即時你現(xiàn)在上一個簡單的版本，下次迭代也不會對系統(tǒng)有太大的改造。

思考全面性

在產(chǎn)品設計中，有意識地鍛煉自身的邏輯縝密性。我經(jīng)常忘記新增或修改的功能對其他模塊產(chǎn)生的影響，也不斷地根據(jù)產(chǎn)品自查清單一遍遍地提醒自己，雖然我現(xiàn)在還是有時候會忘記，但是至少我比昨天的自己更好了。

建議

多多跟開發(fā)溝通學習

有技術背景的人邏輯能力比較強，所以對于開發(fā)的建議，產(chǎn)品人員應該大力鼓勵（如果是不負責的開發(fā)，完全可以說什么做什么，而不會去提還缺什么）。一個產(chǎn)品永遠不可能把所有的細節(jié)考慮到，只有這個團隊所有人從自己的崗位角度思考問題，才會盡量避免錯誤，而產(chǎn)品人員不能太過強勢去扼殺這種良性循環(huán)的可能性。

倒推競品產(chǎn)品文檔

很多人會去問怎么學習，看什么資料快速了解產(chǎn)品，我的建議是去看優(yōu)秀競品的幫助文檔，不斷去玩他們的產(chǎn)品，然后倒推他們的產(chǎn)品文檔，這樣你會發(fā)現(xiàn)你進步的特別快。在這里推薦一篇文章倒推“餓了么”App產(chǎn)品需求文檔

完善知識體系

定期的總結，可以幫助你建立自己的知識體系，不斷地補充自己的技能短板，在這里推薦產(chǎn)品知識體系框架

參考資料

B端產(chǎn)品需求分析的實踐與思考

需求分析：它從哪里來，到哪里去?

實戰(zhàn)總結：如何將需求轉化為PRD？

PS：這里是以bdp做示范來加功能，所以根據(jù)bdp的產(chǎn)品特點（比如頁面布局的屬性）和交互形式而進行交互設計。不同產(chǎn)品要加上這個功能肯定入口和交互形式也不同，本文僅供參考，有些地方我還沒細講，還是有很多門道的，或許你在深入思考后會發(fā)現(xiàn)另一片深淵···

作者：安琪Angela，公眾號：idatadesign?；ヂ?lián)網(wǎng)數(shù)據(jù)行業(yè)PM&UX，參與過數(shù)據(jù)中心，商業(yè)智能和數(shù)據(jù)分析平臺等產(chǎn)品設計。關注大數(shù)據(jù)、人工智能和互聯(lián)網(wǎng)金融。歡迎大家一起交流~

本文由 @安琪Angela 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自unsplash，基于CC0協(xié)議