需求的生命周期管理是一項難度不小，但實實在在值得去做的事情。數(shù)據(jù)團隊也應(yīng)該緊跟甚至需要超前于業(yè)務(wù)團隊，做到「事前感知，事后追蹤」。

本文是個人工作中的一些心得，雖是「個人心得」，其實內(nèi)容卻不乏有數(shù)據(jù)工作中客觀存在的事實，你躲不過也繞不開。主要面向于數(shù)據(jù)相關(guān)的從業(yè)者，如：數(shù)據(jù)分析師、數(shù)據(jù)工程師等。

在我們團隊內(nèi)部，有一個「需求流程」，雖然粗暴、簡陋，但卻簡潔有效。我也將會從流程中的各個節(jié)點聊一聊。站在「陳述事實」的角度把需求流程這件事講清楚，也希望能得到一個共鳴與修正。

下文按照「需求流程」講解：「新建→規(guī)劃中→開發(fā)中→測試中→上線」和「需求生命周期」。

一、新建中

這個環(huán)節(jié)是業(yè)務(wù)需求落實到具體「文檔」最初始的階段，也是數(shù)據(jù)產(chǎn)品經(jīng)理最早跟需求有接觸的階段（當(dāng)然不排除有些口頭需求，業(yè)務(wù)及數(shù)據(jù)產(chǎn)品同學(xué)口頭約定描述需求概況及可行性調(diào)研的部分），這時候數(shù)據(jù)產(chǎn)品需要做：

1.1 判斷合理性

1. 從需求的背景描述，以及與業(yè)務(wù)方的溝通中確定對方想要解決的問題是什么？數(shù)據(jù)是否可解決？
2. 是否已有數(shù)據(jù)？因為有部分需求會因為不同業(yè)務(wù)方之間沒交集而產(chǎn)生需求重復(fù)的現(xiàn)象，而且很多。
3. 是否有數(shù)據(jù)產(chǎn)品工具可供業(yè)務(wù)方自行實現(xiàn)？有些數(shù)據(jù)產(chǎn)品工具就可解決業(yè)務(wù)問題，但產(chǎn)品卻因為「信息不對稱」而不為人所知。
4. 需求邊界問題，有些更適合業(yè)務(wù)團隊自行實現(xiàn)的需求，被提到了數(shù)據(jù)團隊，則需要過濾掉。

1.2 檢驗完整性

1. 報表類需求：檢驗「維度x指標(biāo)」是否完整合理，確認指標(biāo)計算邏輯、口徑是否完善。所謂巧婦難為無米之炊，沒有給出指標(biāo)精確的計算邏輯和所依賴的庫、表，是沒有辦法啟動施工的；
2. 非報表類需求：如工具產(chǎn)品，賦能類等，需要判斷業(yè)務(wù)方是否有足夠的使用場景來支撐工具的開發(fā)。否則一個產(chǎn)品化的工具需求被開發(fā)出來，使用者聊聊無幾，實在得不償失。

1.3 確定優(yōu)先級

最常見也最符合心理學(xué)的一個現(xiàn)象，是每個業(yè)務(wù)方提過來的需求都火急火燎，都把自己的需求優(yōu)先級設(shè)為最高，這些多數(shù)需求只不過是在業(yè)務(wù)同學(xué)提出時恰好「被緊急」了。而實際上卻并沒有我們想象中的那么緊急，甚至被標(biāo)記為最高優(yōu)的需求，在隔日就被遺忘，一周內(nèi)也不再被提起。這種就屬于是「腦熱型需求」。而另外卻存在一類真實高優(yōu)的需求，直接涉及到頂層決策。

我們該如何判斷？

• 需求受益方是誰，這是最直接的方法。比如是CEO的需求，那毫無疑問就是最高優(yōu)，因為將會直接影響「頂層決策」。
• 需求本身所覆蓋的業(yè)務(wù)，是單業(yè)務(wù)還是多業(yè)務(wù)？如果是多業(yè)務(wù)，則缺少當(dāng)前這個需求這一環(huán)是否會影響的是全局的進度？則需要酌情提高優(yōu)先級。
• 需求實現(xiàn)成本如何？需要判斷需求實現(xiàn)的難易程度，如果是一個大型需求需要占用很多工時，若被提高優(yōu)，那么則會直接影響開發(fā)人員手中項目的進度。若是簡單的，「順手」就能完成的需求，則亦可酌情提高優(yōu)先級。

二、規(guī)劃中

開發(fā)同學(xué)不理解需求怎么辦，如何快速上手？關(guān)鍵字：學(xué)會提問。

當(dāng)需求從「新建」移動到了「規(guī)劃中」，則是完成了產(chǎn)品層面的把關(guān)。但這并不等于產(chǎn)品經(jīng)理的工作就完成了。因為在規(guī)劃中的需求，需要產(chǎn)品同學(xué)去推動開發(fā)人員給出明確的排期。開發(fā)人員對需求的排期能力也是考驗自身開發(fā)能力的重要標(biāo)桿，對于規(guī)劃中的需求，開發(fā)同學(xué)需要知道：

2.1 是什么？

需求背景，要解決的問題是什么。

2.2 在什么時間，做到什么程度？

需求的優(yōu)先級如何，數(shù)據(jù)的實時性及準(zhǔn)確性有何要求？

2.3 怎么做？

1. 能預(yù)估需求計算會依賴哪些數(shù)據(jù)庫、表，計算邏輯的復(fù)雜度如何？
2. 需要預(yù)估存儲及計算資源的消耗如何？
3. 其他。

三、開發(fā)中

如何避免蒙頭做事？

3.1 評估

• 是否有現(xiàn)成數(shù)據(jù)？因為有些現(xiàn)成的數(shù)據(jù)在產(chǎn)品層面根本不知道或沒有能力知道，但開發(fā)間會相互知曉（例如：在服務(wù)器中，在倉庫里，在某個只有開發(fā)人員才有權(quán)限的系統(tǒng)中）。
• 數(shù)據(jù)是否已具備？（不具備則需要推動上游解決）

3.2 開發(fā)

依賴的相關(guān)指標(biāo)，有沒有其他同學(xué)計算過，邏輯是否可復(fù)用或可借鑒。

3.3 優(yōu)化

有沒有更巧妙，優(yōu)雅的解決方案。這方面則需要長期不斷的總結(jié)積累。你會發(fā)現(xiàn)同樣的需求，開發(fā)人員能力的不同，最終的方案「優(yōu)雅」程度也會不一樣。

四、測試中

如何進行數(shù)據(jù)測試？

有些公司數(shù)據(jù)團隊里已經(jīng)配備專業(yè)的測試人員，會有嚴謹?shù)臏y試用例，有的測試人員也會手寫SQL及各種小工具來校驗數(shù)據(jù)準(zhǔn)確性。但如果沒有配備測試人員，開發(fā)及產(chǎn)品同學(xué)需要怎么辦呢？

4.1 精確

首先，務(wù)必要保證自己開發(fā)的邏輯與需求無偏差。如果是需求本身模糊，則必須要確認精確的邏輯。數(shù)據(jù)計算這事兒，只能嚴謹。

4.2 心中有數(shù)

開發(fā)好了計算邏輯，在校驗數(shù)據(jù)的時候，需要開發(fā)人員自己心中有數(shù)。即無論是用戶、交易、商品等范疇內(nèi)的基礎(chǔ)數(shù)據(jù)，也都要有最基礎(chǔ)的業(yè)務(wù)量級感知，這能有助于快速判斷一個數(shù)據(jù)計算結(jié)果是否合理（多看報表、郵件）。

4.3 校驗

與線上或業(yè)務(wù)線相關(guān)指標(biāo)做對比（前提是可比）。

五、上線后

5.1 新上線的報表業(yè)務(wù)方質(zhì)疑數(shù)據(jù)不準(zhǔn)確，該怎么辦？

老鐵穩(wěn)住，別慌！對自己的開發(fā)邏輯要求嚴苛，然后有信心。

思考：為何業(yè)務(wù)同學(xué)會覺得數(shù)據(jù)不準(zhǔn)確？無非就是兩個方面：

1. 用新開發(fā)出來的數(shù)據(jù)與歷史同名指標(biāo)數(shù)據(jù)作對比（邏輯上可能會不一樣，不具有可比性）；
2. 與第三方數(shù)據(jù)對標(biāo)（數(shù)據(jù)源及計算邏輯無法確認是否一致，不具有可比性）。

以上兩點思考完了，也就有了解決方案。

5.2 遇到數(shù)據(jù)異常怎么辦？

需求上線一段時間后，某天發(fā)現(xiàn)數(shù)據(jù)產(chǎn)生異常了，該怎么辦？

思考兩點：

1. 先從自身看，去快速思考數(shù)據(jù)流從上到下是否有問題。收集、ETL、計算、展現(xiàn)等，順藤摸瓜
2. 讓信息對稱（多問，多咨詢，看看數(shù)據(jù)是否是因業(yè)務(wù)活動、渠道原因、不可抗力、競品等導(dǎo)致）

六、需求生命周期

業(yè)務(wù)數(shù)據(jù)需求上線后，是不是就結(jié)束了？

每個數(shù)據(jù)人，都應(yīng)該有這樣的基本操守：「需求上線是開始不是結(jié)束」，至少還需要注意兩方面事情：

（1）告警及任務(wù)監(jiān)控機制建立

（2）傾聽業(yè)務(wù)反饋

1. 需求上線后，是否對業(yè)務(wù)方有幫助？追反饋。
2. 是否有優(yōu)化空間？何時該下線？做加法的同時，減法如何做。
3. 能不能做到自動化「任務(wù)/報表/郵件」的自動生命周期管理。

如今，整個市場瞬息萬變，業(yè)務(wù)也會跟著市場的步伐在跑，這對任何一個數(shù)據(jù)團隊都是不小的考驗。你會發(fā)現(xiàn)一個月前還非常重要，還有很多人使用的模塊/報表現(xiàn)在卻沒人理會，那是因為方向標(biāo)變了，一切都在變。需求的生命周期管理是一項難度不小，但實實在在值得去做的事情。數(shù)據(jù)團隊也應(yīng)該緊跟甚至需要超前于業(yè)務(wù)團隊，做到「事前感知，事后追蹤」。

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

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