編輯導語：需求處理是數據分析的前期階段，前期階段做得如何會直接影響到后續的工作和發展，在本篇文章中，作者就針對需求處理這方面進行詳細的介紹和講解，推薦想要學習數據分析的群體閱讀。

需求處理是數據分析的前期階段，前期階段的準備工作直接決定了后續分析工作的方向以及分析的價值。所以，需求處理至關重要。本文專針對需求這塊，做下詳細的講解。

需求處理階段包括三階段：發現問題、需求確認、需求處理。

一、?發現問題

1. 以數據分析思維看待問題

先引入下王大爺的故事。

我去王大爺攤位買烤串，嘮嗑中王大爺說現在現在賺的不行了。我甚是同情王大爺，安慰王大爺說賺點錢買買菜，夠日常花銷就行，人嘛就要過的開心點。

王大爺：買菜肯定…

我：不夠？

王大爺：花不完，就是想置換一套內環內的房子了，現在五套不夠住。

我……

那問題來了，王大爺口中的“賺的不行了”是通過什么得到的結論？

與過去比？過去日賺1W，現在日賺8000，這么比確實少了；

與目標比？目標希望賺個千萬，買套內環內大房子，這么比確實賺的不行；

與行業平均水平比？烤串行業平均日賺5000，王大爺已經是烤串中的佼佼者了；

與其他烤串大爺比？這個“其他”的對比群體怎么劃分？選擇和王大爺攤位所在商圈類似的烤串攤主？還是選擇與王大爺串串產品類似的攤主？還是相同年齡段相同性別的攤主？還是平均客單價同一水平的攤主？（以上王大爺收入金額純屬虛構）

怎么判別王大爺的烤串是賺的多的還是少了？

這個其實就是根據王大爺拋出的問題延伸出來的新的問題。實際工作中，「問題」可以是領導或者業務方直接拋出，也可以是自己主動發現。但不管哪方發起，思考問題均離不開數據分析思維的支撐。

2. 找到有效問題

數據分析的過程其實就是發現問題并解決問題的過程。一個好的問題，時間與人力的付出才不會竹籃打水一場空，分析工作才有價值。發現有效問題，顯得尤為重要。

有效問題的5個特點：

（1）是否有價值

此“價值”是建立在公司利益之上的。有價值的問題并不是說角度新穎、前所未有，而是觸及到了公司的重要層面。

該“問題”是否與公司、部門的OKR相關，是否有跟著公司的整體方向走。比如某個產品已經流量見頂了，公司整體策略由之前的拉新獲客變更為提升活躍留存、維護老客，那么即使產品的用戶體量趨勢即使逐漸趨于平穩，孛離公司整體策略，也不需要再在這上面過于下功夫研究探索。

（2）是否涉及核心指標

首先需要熟悉公司有哪些指標，尤其是核心指標具體是哪些。其次，需要繼續了解這個問題是否涉及核心指標，且涉及了哪些核心指標。

（3）是否影響面廣

是否關系到公司的整體策略？這個問題如果不解決的話，會產生多大的影響？如果解決了的話，會有多大的利好？

（4）是否可規避

受宏觀影響還是微觀影響？無法避免還是本可避免？

若這個問題受宏觀政策的影響，比如疫情原因導致的線下門店銷售下滑，再比如國家出臺政策規定篇p2p年化利率最高36%，這是宏觀因素，不可避免；宏觀因素下，公司業績指標變化較大，原因眾所周知，且無法規避。此時單純研究這個問題則意義不大。

若這個問題未受宏觀影響，比如，某個產品的最近復購率下降，宏觀上并未有任何政策影響，就莫名其妙的復購下降了，此時需要深入探索是不是產品本身存在了問題，還是競品導致，或是其他。這個問題可以說是本可規避但未規避。

（5）是否有時效

時效性的理解就是，如果這個問題現在不解決，對業務后續發展會產生一定的影響。

比如，研究前年10月銷售下跌的原因則沒必要，要保證數據與時俱進，避免數據過于陳舊；再比如，當前時間節點若是處于市場競爭激烈的態勢，則需實時把握產品的數據變化，及時發現問題并解決，當前的問題延期到未來作用性衰減。

（6）是否波動大

波動“大”沒有絕對的標準，但有相對的標準。比如，整個行業的波動是1%，你的產品波動5%；再比如，波動一直處于1%上線，但突然有一天波動了5%。只看波動5%可能覺得也就5%而已，影響不大，但相對來看，5%已超出了正常范圍。

3. 通過什么方式發現問題

與歷史對比：是否符合歷史慣例趨勢，比如數據一直平穩波動還是突增or突降？

與同期對比：如周同期、月同期，年同期。比如2020年雙11期間銷售額較去年同期是漲了還是跌了？

與總體對比：比如某個sku盈利情況與所在品類盈利情況的對比，該sku對總體的的貢獻率如何？

與競品對比：與有相同應用場景、相同用戶群體、存在競爭關系的產品進行對比，尋找差異點。

與目標對比：與公司目標、部門目標相匹配的可衡量指標進行對比，是否有跟著公司戰略方向走？

與經驗對比：以經驗第一時間迅速洞察問題，比如雙11某門店營收不升反降。經驗不需要數據支持，但需要敏感的數據思維以及數據分析經驗支撐。

與預測對比: 與預測數據的差距是否在正常范圍內？

4. 問題拆解與歸類

工作中面對的問題大大小小會很多，即使是同一個問題也可能會被不同人的發起。每獲取一個問題就記錄下來，加以歸類再去選擇性的攻克。

常見的問題歸類方式有：

按照四象限法則進行歸類：緊急不重要、緊急且重要、不緊急不重要、不緊急重要

按照問題類型進行歸類：交易相關、流量相關、用戶體驗相關、數據安全相關、財務數據相關……

按照優先級進行歸類：P0（重要緊急，當前亟待解決）、P1（非緊急，可適當延后騰出時間優先解決P0）、P2（非緊急，可后續再做）……

有時候我們遇到的問題很棘手，大且復雜。一片迷茫，思維混亂。如何著手去解決？這時候，我們需要將復雜的問題“拆而解之”，而非將焦點浮在問題表面，把大問題圍繞核心點拆解成可以行動的小問題，找到切入點。

打個比方，某個線上產品營收下降了10%，將10%拆解到各個子產品線、各個地區維度等，拆解出下降由哪方面帶來，再針對性的逐個分析。

5. 站在業務角度想問題

做分析，很容易陷入一個圈：為了分析而分析。

看到一個問題，會想可以用xx模型、xx技巧、xx模板來分析了。使用了一圈的技能，復雜的過程，密密麻麻的公式等，感動了自己，迷茫了需求方。不是說不能使用，而是要回歸業務本質，先從業務角度出發，思考這個問題的價值。分析方法向業務靠攏，而非業務需求向分析方法靠攏。

了解清楚了問題的業務價值，以后最起碼可以站在一個更高的公司策略層面的角度，談論這個問題的核心意義。

我最初做分析的時候，就陷入了這種圈子。辭職的時候，跟領導說不想做這種只跟業務方打交道的分析，也沒涉及任何模型，想去做涉及模型的分析。現在想來，好愚昧的想法。

做分析需求不一定需要復雜的模型，反過來，做模型一定需要深入了解業務知識，哪怕數據科學家這種對分析模型深入熟練的角色，也有著深入的業務了解程度。不管怎么說，深入了解業務，不虧。

發現問題之后，有了初步的方向，下一步就是需求確認。

二、?需求確認與梳理

1. 確認需求背景

了解清楚需求背景，才能明白這個需求的意義，是為了解決什么問題而出發的，不至于迷茫的做分析。需求背景就是需求產生的原因以及想要達成的目標。

需求產生的原因:當前現狀是怎樣的？為什么會提此需求？遇到了什么問題？

需求要達到的目標: 此需求期望在什么時間通過什么樣的方式達到什么樣的目標？（when、how、what）

2. 確認指標口徑

需要確認清楚這個需求涉及什么指標，哪些是核心指標哪些不是核心指標。每個指標的口徑是什么，最近有沒有更改口徑。

比如客單價，即使大家都知道客單價=GMV/用戶數，但是不能想當然以為需求方肯定知道，需求方也以為你肯定也知道，雙方未核對口徑直接開工干活。這樣會存在兩波客單價口徑不一致的風險。分子什么維度、分母什么維度，都需要對清楚。

說白了就是，我以為你知道，你以為我知道，但是，咱們還是要對一下口徑。

因為分析角色是干活的一方，需求方是發布需求的一方，所以面對需求，自身需要想的更多些，有些點需求方可能沒想到，此時分析師需要具備更多的主動性。引導溝通、多方核對。畢竟，不溝通清楚需求直接干，容易背鍋且被投訴，也竹籃打水一場空，浪費了時間。

所以前期不要怕溝通。最好是沉淀成文檔，點對點溝通。

3. 確認數據維度

數據維度可以理解為研究數據的角度，比如地區、城市、用戶名等。

需要向需求方了解清楚:

• 需要什么維度的數據？
• 此維度按照什么方式聚合？
• 去重還是非去重？
• 直接聚合還是累積聚合？
• ……

4. 確認底層邏輯

需求方提需求，一般只會討論需求詳情，但是需求怎么做，數據從哪里獲取，他們不需要關心。

比如，需要看某個商品的七日復購率，數據庫表中有七日復購率指標么？若有指標口徑是否和需求方的口徑一致？若無，需要從哪些數據庫表進行關聯得到所需數據？自己關聯計算的邏輯需要數倉落表還是直接應用？

5. 確認資源配置

資源配置包括人力資源與排期資源。比如需要大致評估下需要什么團隊安排幾位人手做需求，以及安排的人員是否有排期。所以分析師在這里還扮演了一個協調的角色，協調好需求方、數倉、分析師等人員的配合。

需求緊急，排期緊張，還需要去協調是否將此需求優先級前調，其他需求暫且延后。

6. 確認需求完成時間

需求方大多數只給了一個最終的時間，比如這個需求2月10日需要完成。那么每個環節的詳細時間計劃，需要分析師去領頭協調了。比如：

清晰的排期計劃：便于需求方及時隨時查看進度、便于自己有個需求跟進的時間參考。

7. 確認數據安全

分析師可以接觸到很多底層數據，所以需要有數據安全意識。有的公司劃分比較嚴格，某個模塊的需求專門安排某個分析來一一對接。但有的公司沒這么嚴格，所以需要判別下需求方是否可以查看該數據。

（1）需求方是否可查看該數據

即使是同一個公司的人，各自的數據權限也并不一樣，一般不允許非必要性情況下獲取本職工作以外的數據。比如，兩個部門做著類似的產品，有著類似的用戶群體，也背負著各自績效，數據不能相通。

但對方都是希望可以獲取另一方數據來做對比，這種情況有的公司不被允許。分析師自然也要判別這種情況，該給給，不該給則果斷拒絕這個需求。

（2）明細數據是否涉及數據安全

另一方面，需求方有時候需要明細數據，即數據粒度較細的非聚合數據，比如ods層、dwd層的數據，還需要判別下是否能夠提供明細數據。有的公司明細數據會受到公司安全部門的監管。畢竟，明細在手，各種角度的分析都能搞。

三、?面對不合理需求

工作中會面對各種各樣的需求，確認需求是否合理也是一項重要的步驟。合理的需求建立在利益最大化的基礎上的，就是以合理的資源做著合乎公司整體規劃的需求。

但若是遇到了不合理的需求呢？

分析師雖然作為服務方，服務于需求方，但不需要將“滿足一切需求”作為行事標準，這樣解決的只是“量”的問題，并不會解決“質”的問題。其實工作中不必一味的迎合用戶，當然也不是說直接擲地有聲的拒絕，而是扮演好需求的引導角色與管理角色。

1. 引導角色

以前曾經接過一個大領導的需求，涉及一張圖表，需要看不同商品在不同地區的趨勢表現，比如看辦公用品在北京、上海、杭州、蘇州、南京等城市的銷售額對比，還需要看學習用品在北京、上海、杭州、蘇州、南京等城市的銷售額對比，等等。

我其實做的是篩選器上篩選不同商品來看城市對比即可，但是這位大領導已經習慣了以前的做法，就是相同的圖表一直平鋪排列下去，需要一直上下滾動來看。

我的直屬領導說，篩選的方式自然是很便捷的，只是還沒習慣，也不必非要按照他以前的方法來做，你可以先嘗試著去引導他，講解下這種方式有什么便捷性。

這是個小例子。

還有個例子是，有需求方需要的是明細數據，數據量上百萬，以表格形式展示出來供他們下載即可。用戶是這么需求的。

但是作為分析，需要進一步考慮，為什么需求方要把BI當作一個下載數據的平臺，而不是直接看數據的平臺？在需求溝通的階段，其實就要了解清楚需求方下載下來的目的？是BI看著不方便？還是用著不習慣？

如果說需求方下載下來之后需要進一步在excel上做數透、函數等處理，是不是可以引導需求方直接在BI上實現即可。因為明細數據的量一般不會小，經常跑明細任務給平臺自身也帶來了很大的壓力，需求方的數據處理時間也增加不少。

所以，其實有時候也沒必要非要被需求方牽著鼻子走。如果是個雙贏的局面，不如加以合理的引導。

2. 協調角色

如果正在按部就班的處理著需求，突然插進來一個需求怎么辦？工作中都會有這種情況。

需求方會說“我這個需求很簡單，你先處理下吧” “我這個需求很緊急，大佬們都在盯著呢，麻煩你優先處理” “我這個需求10分鐘之內就要出結果” “別人都能立即搞定，為什么你要明天才可以？”等。

（1）自己協調

如果手中需求的優先級已經跟各需求方確認好，穿插需求先考慮到會不會打亂其他需求。

如果好幾個需求都喊著緊急，先緊急做影響面廣的。其他的直接表明態度需要適當延后即可，但是最好可以給到一個具體的延后排期給需求方，溝通確認延期后的時間需求方可以認可，而不是直接一句“沒時間”就完事了哈。

（2）適當求助

優先級如果自己不能做主，或者自己協調的時間需求方不認可，也可以適當求助上級領導，共同商討下手中需求的優先級。畢竟領導經驗更多考慮的因素會多些。

四、?沉淀需求文檔

其實需求要梳理的內容基本上都在需求確認環節都確認清楚了。需求確認和需求梳理并沒有嚴格的前后關系，可以同步進行。

只需要將口頭溝通、會議溝通等全部沉淀成需求文檔，一般來說包括以下內容：

1. 需求背景；
2. 需求描述；
3. 指標口徑及數據維度；
4. 人員配置及執行計劃。

需求文檔沉淀完畢之后，還需與需求方再過一下。若需求后續有更改，也需要將需求更改時間標明上去，便于回溯。

以前我接需求特別不愛沉淀文檔，覺得浪費時間，就直接開干。過了一段時間后，會出現：

• 需求方說當初討論的明明不是這樣的；
• 有使用方問指標口徑為什么這么定呢；
• 其他人問這個需求為了解決什么問題；
• ……

能完整的將以前的需求討論細節講出來嗎？甚至忘記也不好說。所以，沉淀很重要。如果需求確實緊急，也可以先開干，后續再抽空將需求整理出來。

做好需求梳理的沉淀，還有一個好處是，會讓你想的更多更細，比起直接開干更可能及時的發現些問題。

?

作者：Janie Liu；公眾號：溜溜筆記說

本文由 @溜溜筆記說 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議