團隊數(shù)據(jù)驅動需要六個步驟

通常我們認為增長的策略是非常重要的。俞軍老師講過稀缺度的問題，找產(chǎn)品經(jīng)理是找邏輯嚴密的，因為邏輯嚴密是比較稀缺的。相比較基礎的產(chǎn)品知識是好學的。所以同樣的邏輯大家面試時候多半會找懂運營策略和分析的。因為這樣的人更加稀缺。

但是這里面有一個隱含的假設：獲取數(shù)據(jù)環(huán)境也很好。所以有了很好的增長策略運營，你只要不斷的獲取數(shù)據(jù)，不斷的分析就可以持續(xù)的產(chǎn)生非常好的策略。很多管理者認為招聘到好的策略分析者（本身他們很稀缺）就認為可以做數(shù)據(jù)驅動了。但是任何事情都是團隊來實現(xiàn)的。好的分析者只是冰山一角。只有整個組織鏈條都開始數(shù)據(jù)驅動化，不斷賦能業(yè)務人員，才能保證有持續(xù)的策略產(chǎn)出。招聘到好的增長策略的運營其實只是數(shù)據(jù)驅動的開始。

因為我最近咨詢的公司都或多或少因為這些因素無法數(shù)據(jù)驅動。通常造成這種阻力的原因：他們都只看到了無法數(shù)據(jù)驅動的某個切片問題，或者某個節(jié)點問題。但是按照我上一篇文章寫的大處著眼小處著手。

往往找到的解法都是頭疼醫(yī)頭，腳疼醫(yī)腳的方案。如果真的想把團隊轉化為一個數(shù)據(jù)驅動的團隊，就要從整體梳理清楚阻礙團隊無法數(shù)據(jù)驅動的點有哪些。這個過程非常像解開一堆非常亂的線頭，你要先從整體梳理好，然后再一個一個解開。除此之外別無辦法。

其次任何團隊的改革都是一個循序漸進的過程，這里面拋開利益關系的問題，團隊成員能力模型，工作流程，工作習慣都是需要逐步引導的。貿(mào)然大動都會導致團體排異（如果我們把組織看作一個有機體）

所以我會給到您一個查驗清單按照這個邏輯，找到冰山以下「水面下」影響增長驅動的因素。

希望你的組織也能夠轉化到數(shù)據(jù)驅動的流程上來。

數(shù)據(jù)獲取是整個團隊和多個系統(tǒng)持續(xù)向業(yè)務賦能，通常我們只能看到數(shù)據(jù)分析師

Part1

啟動數(shù)據(jù)驅動前你要思考什么

1.1 為什么要數(shù)據(jù)驅動

美國科學家做過一個思想實驗：把魔方打亂，交由一個盲人還原，假設盲人永生且不需要休息，每秒轉動一次，理論上他需要多久才能將魔方復原？答案是一百幾十億年，也就是從宇宙大爆炸到現(xiàn)在，還需要再等幾十億年才能實現(xiàn)。如果加入一個變量——每轉動一次魔方，就有人向他反饋一個信息，告訴他是更接近目標了，還是更遠離目標了，請問盲人需要多久才能把魔方還原？答案是兩分半！這個思想實驗揭示了一個秘密：迭代反饋是一種強大的宇宙法則。

我們做數(shù)據(jù)化就是為了讓我們所有的策略變得可視，可以看到結果的量化，就意味著每次轉動魔方知道是轉對了還是轉錯了，就可以提升迭代的速度。

1.2 數(shù)據(jù)驅動能做什么

數(shù)據(jù)驅動就是讓結果可以被量化，整體的業(yè)務可以被量化，數(shù)據(jù)只能告訴你現(xiàn)狀，好比病人去醫(yī)院看病，醫(yī)生告訴你高血壓，他不能給你開降壓藥，如果我們把人的身體比作業(yè)務，數(shù)據(jù)驅動只能告訴你當前你的業(yè)務狀態(tài)，他并不能告訴你造成這個狀態(tài)的原因。

當然如果你的數(shù)據(jù)基數(shù)非常大的時候，這種情況下你通過做一些策略，一些修改迭代找到策略和結果的相關度就是可以的。但是我們依然不鼓勵這么做，最好還是需要你做數(shù)據(jù)驅動，還需要做用戶調(diào)研和需求分析。

所以數(shù)據(jù)驅動只能做到正確的做事兒。正確地轉動魔方。事實上我們的業(yè)務比轉動魔方要復雜的多，因為轉動魔方包含的隱含下設是：錯誤和正確的信息反饋本身就包含了策略解決方案。即你不向著錯誤的方向旋轉魔方，你就一定向著正確的方向旋轉他。但是大多數(shù)現(xiàn)實情況，現(xiàn)實的狀態(tài)反饋不會直接給到你解決方案。

但是長期正確的做事可以極大地提升做正確的事情的概率。

我們最終的訴求是把事情做正確，但是這并不是數(shù)據(jù)驅動業(yè)務必然的結果，數(shù)據(jù)驅動業(yè)務是做正確的事情的基礎。

1.3.你的業(yè)務是否可以數(shù)據(jù)驅動

在啟動數(shù)據(jù)驅動前，還需要了解的是那么就需要去思考三個問題看下看你的業(yè)務是否可以數(shù)據(jù)驅動。這也就引出了我們的第二章節(jié)，數(shù)據(jù)驅動的三個問題，第一個問題，你的行業(yè)是否是一個增長的行業(yè)？第二個問題，你的業(yè)務是否用戶量和商業(yè)價值非常大，數(shù)據(jù)驅動價值可以支撐團隊成本。第三個問題，你的業(yè)務是不是一個可以被拆解為多個獨立小閉環(huán)的業(yè)務

Part2

數(shù)據(jù)驅動需要滿足的條件

2.1增長產(chǎn)生了策略

第1問：你的行業(yè)是否是一個增長的行業(yè)？

用戶量和數(shù)據(jù)量是策略產(chǎn)生的原因，而不是策略產(chǎn)生的結果。很多老板認為當前業(yè)務不增長，我去找增長類的人才，是不是就解決了這個問題了。這就是我說的頭疼醫(yī)頭，腳疼醫(yī)腳。

首先你要想的是這個行業(yè)是否在增長。你把張小龍放到教育行業(yè)他也很難讓他增長。別說張小龍就是李小龍來了，李顯龍來了，都沒有用。所以增長的最底層是你的業(yè)務本來可以在現(xiàn)有的渠道下增長，或者尋找新的渠道把用戶轉化過來。本來就是用戶有需求沒有發(fā)現(xiàn)渠道，或者說外部環(huán)境使得用戶會變得越來越多。增長的第一層天花板就是市場的用戶到底有多少。但是很多老板大邏輯沒有想清楚。就去找人去獲客。認為只要我有策略就會有用戶。依照這個例子，我請來張小龍就會產(chǎn)生增長，不一定的。

2.2 有價值才有組織結構

第2問：你的業(yè)務是否用戶量和商業(yè)價值非常大，數(shù)據(jù)驅動價值可以支撐團隊成本？

接著第一條講解，就是你預估這個行業(yè)有多少用戶量，越大的用戶量，你做優(yōu)化產(chǎn)生的價值越大，可以提供的薪資和職位就會多。

業(yè)務體量決定組織結構，你們用戶量每天千萬，你做個數(shù)據(jù)驅動的算法和策略才有價值，你提升個百分之一ARPU值，你用戶基數(shù)這么大。一年下來你創(chuàng)造的價值足夠養(yǎng)活你們這些算法工程師了，可能他們創(chuàng)造的收益還遠遠大于他們的工資（通常業(yè)務體量大的公司一定是這樣的）。如果你的業(yè)務天花板很小，不會有很大量用戶的可能，那么你就不需要做數(shù)據(jù)驅動，因為這個團隊，這些人才，他們創(chuàng)造不了這個價值，也就意味著這個業(yè)務也養(yǎng)活不起這樣的團隊。

2.3 業(yè)務可以被拆分獨立閉環(huán)迭代

3問：你的業(yè)務是不是一個可以被拆解為多個獨立小閉環(huán)的業(yè)務？

數(shù)據(jù)一直在服務商業(yè)：傳統(tǒng)企業(yè)用財務數(shù)據(jù)，長周期的業(yè)務結果數(shù)據(jù)做商業(yè)分析，也是數(shù)據(jù)服務于商業(yè)。所以從這角度看業(yè)務并不能說傳統(tǒng)企業(yè)不是數(shù)據(jù)驅動的。

互聯(lián)網(wǎng)業(yè)務的本質是線上化：今天互聯(lián)網(wǎng)業(yè)務的數(shù)據(jù)驅動，根本變化在于業(yè)務發(fā)生的主體過程線上化了，業(yè)務動作線上化了，衍生出來快速迭代和重視流量等新的特點。因為用戶所有的行為都「線上閉環(huán)」的。其次最好支持你的業(yè)務的系統(tǒng)都是線上化的這樣方便你把業(yè)務切分成獨立閉環(huán)。刨除用戶量你還需要考慮三個要素：

1.SKU量大：SKU量大說白了就是內(nèi)容分發(fā)，策略推薦，如果你業(yè)務的內(nèi)容非常少，那么對于內(nèi)容。你就比較難找到數(shù)據(jù)化的意義，主要是通過數(shù)據(jù)化過高效的撮合交易產(chǎn)生杠桿，要知道內(nèi)容也是符合冪律分布的。品類管理和內(nèi)容供給是「增長黑客」中很重要的一部分。

2.交易高頻：交易單價和交易頻次是成反比的。越是價格高，交易的人也越少，頻次也越低。越是依靠銷售團隊。交易頻次越高，就意味著用戶的反饋越多。真正用戶價值=活躍用戶數(shù)*賬戶平均交易量。

3.供應生產(chǎn)端反饋周期短：也就是說對于需求的供給也一定要能夠快速迭代，因為供應鏈的迭代速度決定了你可以提供的「內(nèi)容」以及用戶價值。這樣才能夠快速迭代產(chǎn)生更大的價值。

Part3

如何讓團隊啟動數(shù)據(jù)驅動

整體上我們會從數(shù)據(jù)，工作流程，產(chǎn)品架構，組織分工，組織動員這五個方向來做逐步的講解可以讓你做到數(shù)據(jù)驅動。我們會先講如何把你的業(yè)務短期需求數(shù)據(jù)驅動。會涉及幾個業(yè)務方。

如果讀者們覺得同時推動幾個業(yè)務方?jīng)]有話語權，我會再講如何把內(nèi)部團隊做到數(shù)據(jù)驅動。

3.1 核心邏輯是矩陣式分工

因為你的業(yè)務可以被拆分成多個獨立迭代的小閉環(huán)，也就意味著你的核心指標可以被劃分成很多獨立的小指標，下發(fā)給各個團隊。這就是一個還原論的邏輯，我的大系統(tǒng)可以被拆分成小系統(tǒng)。我的小系統(tǒng)可以加總等于我的大系統(tǒng)，如果我的小系統(tǒng)增長了， 那么我的大系統(tǒng)就增長了。

所以我們單看一個指標如下圖：

Facebook把自己的業(yè)務拆分成了200多個獨立閉環(huán)迭代的團隊

拆分到單一指標后，給這個指標配置團隊，這個團隊大面上不依靠外部迭代起來，考慮到軟件開發(fā)有些系統(tǒng)不是這些工程師開發(fā)的。但是一個需求的獨立承接肯定是可以的。我們看這個指標下包含了，數(shù)據(jù)分析師，工程師，產(chǎn)品經(jīng)理，設計師，所以他們接了需求就是可以自己做需求評估，或者自己做需求迭代。而不依靠「外部資源」。只要包含越多的支持方，你數(shù)據(jù)驅動失敗的可能性就會越大。

下面我們看下針對多個指標的團隊矩陣。

指標和角色以及部門關聯(lián)關系

當你給多個指標分發(fā)團隊的時候，就形成了指標和管理的矩陣。每個指標由橫向的崗位來驅動他的增長。注意這里說的是崗位，因為當指標多的時候，不一定會有足夠的自然人，但是崗位必須要按照指標來設計。如果你業(yè)務足夠大，每個指標都可以養(yǎng)活一個團隊，那么每個崗位下都有一個。還是我上面說的那個問題。用戶量，用戶價值決定支撐你多少人的團隊。

可能看到這里您不太明白如何劃分，您只要知道可以按照指標橫向搭建分工角色，縱向進行管理即可。切分還有很多種方案。

3.2 成事者以找替身為第一要務

無論您再怎么想做數(shù)據(jù)驅動上面說的小團隊里面的人是不能或缺的。找對人后就能把一個方向或者部門的業(yè)務做好。畢竟管理者不能親自擼起袖子去做所有的事兒。在繁瑣的日常中活活累死。所以找對人是非常重要的。其次還是我昨天說的。

1.業(yè)務上他要做什么

2.你們配合的邊界在哪里

3.這個人的能力邊界在哪里

4.從什么角度上考核這個人

5.如何判斷這個人能力行不行

這些問題要想清楚。所以既然找替身是第一重要的事情，我所以我們先從找人說起。

3.3 啟動數(shù)據(jù)驅動的核心要點

我們覺得招聘人員來做數(shù)據(jù)驅動事情。那么招聘來的人，要做什么呢，我們總結了以下六個方向的事情。從數(shù)據(jù)，工作流程，產(chǎn)品架構，組織分工，只有把這四個方向都做好了才能做到數(shù)據(jù)驅動。

3.3.1 數(shù)據(jù)可獲取能力

數(shù)據(jù)可獲取能力是數(shù)據(jù)驅動的基礎，任何業(yè)務維度，如果我們連數(shù)據(jù)都無法獲取，那么這個業(yè)務維度就無法做到數(shù)據(jù)驅動。通常情況行業(yè)管這個團隊叫做數(shù)倉團隊。數(shù)倉團隊核心聚焦于「數(shù)據(jù)驅動決策賦能」「數(shù)據(jù)驅動產(chǎn)品增長」這兩個部分。

數(shù)據(jù)獲取的能力絕非簡單的讀取與展示，它是一個系統(tǒng)獲取數(shù)據(jù)的架構。很多管理者想當然的認為我找一個會寫SQL的人來獲取數(shù)據(jù)不就行了。但是這樣會導致未來某個時間段你的數(shù)據(jù)獲取遇到瓶頸，你業(yè)務發(fā)展速度越快，這個瓶頸越快的來臨。我的建議最好還是有專人負責數(shù)據(jù)存儲系統(tǒng)的搭建和前期輕量化的數(shù)據(jù)提取工作。

就算是初始啟動期也要有相應的數(shù)據(jù)架構來滿足獲取數(shù)據(jù)的需求。從「數(shù)據(jù)采集」「傳輸」「存儲」「處理」「應用」六個維度來思考最終賦能業(yè)務方。有一個初始團隊數(shù)據(jù)賦能的架構，后續(xù)從這六個維度上來逐步豐富整個數(shù)據(jù)賦能的架構。

數(shù)據(jù)獲取的成本和范圍，品類，很大程度上取決于數(shù)據(jù)系統(tǒng)體系

大部分我們覺得數(shù)據(jù)分析成本過高，很大程度上都是冰山理論事實上是水面下的數(shù)據(jù)獲取架構做的不行，不能夠提供低成本的獲取數(shù)據(jù)的方案。

初始數(shù)據(jù)團隊的工作內(nèi)容

業(yè)務的初始時候，我們更多的是以報表的形式來提供，比如說你的數(shù)倉團隊剛剛成立的時候，業(yè)務也在初步的發(fā)展也在持續(xù)的一個發(fā)展初期，你的人員的構成都屬于在一個磨合期，這業(yè)務其實也是在一個相當于一個探索期，所以在這里邊其實數(shù)倉團隊更多的是你提供報表。

比如說其實我們最開始我們可能只需要關注的是流量數(shù)據(jù)和業(yè)務數(shù)據(jù)，以及他們之間的關聯(lián)先把流量和留存兩部分關聯(lián)起來即知道流量的價值，也知道當前產(chǎn)品留存的情況，等到業(yè)務方發(fā)展到一定的階段，我們慢慢就開始做安全體驗相關的數(shù)據(jù)建設，其實它是隨著業(yè)務的發(fā)展而逐步迭代的，還有一個整個重心的變化，數(shù)倉整個建設也會逐步迭代。所以你要去關注你的關鍵業(yè)務，在某個階段，它的關鍵業(yè)務是什么？

對應的就是我們的關鍵數(shù)據(jù)源，因為你知道你需要什么，才知道說你去采集什么，比如產(chǎn)品和研發(fā)有上萬張表，我們不可能什么把所有的表都可以采集到「數(shù)倉」里面，所以你要有一定的就是相對要有一定的范圍，所以在這里邊其實就是通過關鍵業(yè)務為抓手，來去做對應的關鍵數(shù)據(jù)源的采集。

在這時候我們同時要做元數(shù)據(jù)的一個規(guī)范化的管理，數(shù)倉產(chǎn)出一張表，表的comment(每個字段說明)是空的，或者說不準確的，你的表的特征它也是不準的。所以當數(shù)據(jù)分析師去用的時候，或者說相關同學去用的時候，就發(fā)現(xiàn)你做這個事情，你做這個產(chǎn)出物是沒有什么太大的價值，因為整個的數(shù)據(jù)不是很規(guī)范，大家也不理解。比如下單，又有很多種命名，很多的業(yè)務線都有記錄，很多的表上都有這個字段的名稱。有五六種其實大家不知道到底哪個是下單的字段。其實這個就是一個很痛的點，所以元數(shù)據(jù)的規(guī)范化，在數(shù)倉的一個初始階段就要去做，

業(yè)務圖譜，對于數(shù)倉團隊，他首先要去理解業(yè)務，才能去做對應的數(shù)據(jù)建設，還有指標化的建設。所以我們最開始比如說做訂單的時候，我們就會先去做整個交易主鏈路的流程，從開始他的發(fā)單和接單到整個鏈路支付完成，我們是把整個的主鏈路去梳理出來，然后針對于每個主鏈路，它里面具體的一些業(yè)務過程是什么，其實這個就是數(shù)倉團隊在整個業(yè)務圖中怎么去梳理出來，在這里面我們才能提煉出哪些關鍵的點。所以這個就是業(yè)務統(tǒng)籌，其實也是通過這個層面來讓數(shù)倉的同學更好地去理解業(yè)務，更加站在業(yè)務的視角，用戶的視角去理解數(shù)據(jù)能去做什么。

然后統(tǒng)一的需求把控。這個在初始階段其實也是一個很重要。大家會講煙囪式的建設，其實煙囪式建設要兩面性來看，不是煙囪式建設就不好，特別是在業(yè)務發(fā)展初期，它的驗證式建設，其實它能快速的去迭代去發(fā)展，如果你的整個規(guī)范性，你的很多流程其實OK的，其實煙囪式建設其實還是在一個可控的范圍內(nèi)了，但在這個層面我們就要做整體的需求把控，其實是做一些適當?shù)娜哂嗍荗K的，因為在這個時候，其實我們的相關的數(shù)據(jù)的口徑是不確定的，其實業(yè)務也不清楚說我們的口徑到底是什么樣，其實也是在一個探索的過程。

這就要講到一個統(tǒng)一的指標體系，統(tǒng)一的指標體系是所有的數(shù)據(jù)團隊，或者說我們對用戶都是一個非常痛的點，其實我們后面會講一下。所以在這個初始階段，核心的關注是這些內(nèi)容等到了發(fā)展階段，收藏團隊發(fā)展階段，當時我們收藏團隊讓那個看的是人的能力，還有整個團隊的協(xié)同，已經(jīng)有了一定的默契，然后同時呢業(yè)務的發(fā)展我們也有一定的沉淀和積累，所以在這個里面我們會幫助用戶去做對應的一些分析跟應用應用型的一些產(chǎn)品。所以在這個層面上，比如我們初始階段更多是幫助用戶快速的看數(shù)據(jù)去去做決策，所以這里面更多的是以核心的報表和看板為主，等到你的發(fā)展階段的時候，用戶要做一些精細化的運營，所以在這里面我們要提供一些相關的一些分析類的產(chǎn)品。啊，還有一些策略診斷類的行為，或者評估類的一些產(chǎn)品。

3.3.2 指標拆解能力

可以理解業(yè)務，反饋領導側，可以測算收益，對需求可以權衡

如果我們有了獲取數(shù)據(jù)的能力，具備對用戶，交易，獲客渠道的基本分析，我們就要針對業(yè)務進行指標拆解。渠道端做到每個渠道流量數(shù)據(jù)清晰，包含每個渠道帶來的業(yè)務數(shù)據(jù)，例如GMV等等?？梢栽u估渠道價值的數(shù)據(jù)。交易側可以看清留存，激活，對于活躍的構成，交易的品類，對于用戶側可以看清高價值用戶。

這個過程需要一個可以拆解業(yè)務指標的人，有拆解能力的。但是建議核心管理層都要嘗試拆解一下?；蛘哌€有能力快速理解這個拆解邏輯。拆解指標主要是為了對核心業(yè)務的主要影響因素有一個理性的數(shù)據(jù)上，「劑量」上的認知，而不是感性的，例如我知道它的影響很大。

這可以給到領導側方便領導側看清業(yè)務。同時我自己工作的經(jīng)驗發(fā)現(xiàn)很多領導要看數(shù)，事實上是上一個環(huán)節(jié)沒有搞懂，就是他自己對于要看哪些指標他們反應了什么并不是很清楚。導致每次給到他們數(shù)據(jù)，他們還是覺得數(shù)據(jù)不夠。但是豐富哪些又說不出來。

最后一個邏輯是你有了數(shù)據(jù)，就可以評估大概一個功能的轉化率。就可以測算收益，以及數(shù)據(jù)評估可以預估這個需求的用戶，有了收益預估，又有了用戶價值你就可以權衡需求的優(yōu)先級。所以就具備了基本的數(shù)據(jù)驅動的環(huán)境。

3.3.3 需求開發(fā)流程

一切從源頭開始，互聯(lián)網(wǎng)公司大部分核心價值是通過線上產(chǎn)品或者軟件產(chǎn)品把價值傳達給用戶的。那么需求的量化管理是數(shù)據(jù)驅動真正的開始。如果說之前的兩步：獲取數(shù)據(jù)能力，以及拆解數(shù)據(jù)能力是打掃家門，那么從量化需求開始數(shù)據(jù)驅動，則真正做到了迎接客人。即后續(xù)的新增需求都會按照量化權衡優(yōu)先級的方式來判斷先開發(fā)哪些功能，后開發(fā)哪些功能。就能夠真正做到數(shù)據(jù)驅動，有效通過量化來權衡優(yōu)先級，逐步釋放業(yè)務壓力。

同時能夠很大程度上激勵開發(fā)人員，反向管理業(yè)務方，在這里我要論證一下為什么要業(yè)務方提需求寫需求文檔，我之前也在小的公司工作過，這些公司很多時候都是一句話需求，和真正完善的需求文檔也是有差別的，差別不在字數(shù)上，而是要把問題講明白。我們認為撰寫文檔有如下好處：

1）有利于業(yè)務方整理需求內(nèi)容。寫作本身是一種思考和反向輸出，所以在寫的過程中就助于整理業(yè)務方的思路。需求背景，針對的用戶，現(xiàn)狀，痛點，因此要做哪些功能，解決的問題，預估收益都有一個很好的梳理思考。

2）有利于業(yè)務方圈定需求范圍。通常業(yè)務方會頻發(fā)的改需求，除了上面沒有梳理好自己的想要什么之外，通常的情況是雙方并沒有針對需求達成范圍。業(yè)務方和產(chǎn)品對于解決方案的功能范圍認知存在偏差。所以寫出來流程和大體規(guī)則與功能有助于產(chǎn)品經(jīng)理和業(yè)務方在認知上快速達成一致。

3）有利于產(chǎn)品經(jīng)理理解業(yè)務方需求。就算是業(yè)務方自己確定要什么，隨著時間的推移可能也會產(chǎn)生偏差。以及如果是口述的需求需要被迫產(chǎn)品經(jīng)理記住。這樣的溝通是非常低效的。

4）文檔存在本身就是有價值的。無論通過的，還是沒有通過的需求。對于通過的需求后續(xù)的產(chǎn)品經(jīng)理接手后知道在之前什么情況下迭代了什么需求。同時需求方也可以明白，哪些用戶的需求做到什么樣了。新來的人知道過去哪些需求被否定過了，為什么被否定了，是不是現(xiàn)在條件還不成立，那就不用再次浪費時間提出了?；蛘哒f條件有變化了，也可以在原來被駁回的需求上思考。

很多人會反駁說業(yè)務方都很忙沒有時間寫需求文檔，我的看法是一個需求啟動后，要經(jīng)歷產(chǎn)品，設計，研發(fā)，測試，數(shù)據(jù)等等多種人員的環(huán)節(jié)，要花費這些人員的時間，相比較這些人員的成本來說，把需求描述清晰，量化了反而是一個提高效率的方法。有一種說法是提錯誤需求的人還不如不提需求，因為它還占用了資源。對于這種人發(fā)工資什么都不做，都好過這些人提需求。

其次一個需求如果不值得寫，基本上它并不值得開發(fā)。因為每個節(jié)點的撰寫量是成倍增加的，從需求文檔，到產(chǎn)品需求文檔，再到代碼。

最后也不建議上來就讓業(yè)務方量化提需求文檔，最好是有產(chǎn)品和數(shù)據(jù)分析師輔助，注意是輔助而不是帶寫。在產(chǎn)品和數(shù)據(jù)分析師充分了解需求后可以在固定的文檔格式上給予業(yè)務方一些撰寫建議，包括數(shù)據(jù)提取，哪些數(shù)據(jù)輔證需求的一些建議。最終目標都是為了可以讓業(yè)務方獨立完成數(shù)據(jù)提取的求證以及獨立撰寫需求文檔。

3.3.4 產(chǎn)品和研發(fā)剝離

如果前三項基本滿足那么第四項是一個邏輯必然推導的結果，如果你的需求方可以量化的提需求，你可以量化的評估需求，評估過后就要有產(chǎn)品和開發(fā)能夠實現(xiàn)需求，同時也能夠做好這些需求的數(shù)據(jù)監(jiān)控。所以說如果想做到數(shù)據(jù)驅動，最好對組織結構做相應的改造，核心的思路是讓運營和業(yè)務類需求和長期用戶價值的需求走兩個堆棧。逐步實現(xiàn)研發(fā)側逐步小閉環(huán)分工化。

我們認為指標，功能，以及對應的開發(fā)是有相關度的。當然并不是絕對的。但是盡量我們要做到可以切分成獨立的閉環(huán)（盡管可能存在藕斷絲連的情況）但是大體趨勢上是獨立的。整體的切割邏輯在3.1章節(jié)核心邏輯是矩陣式分工那節(jié)已經(jīng)進行了講解，我這里做另外一個角度的陳述就是大體思路可以把偏向營銷的如落地頁工具，運營引擎，投放引擎，消息觸達中心等等這些屬于偏向與運營和銷售類的功能并攏到增長產(chǎn)品方研發(fā)團隊，另外一類會偏向于用戶價值長期建設，我們以電商舉例比如類目，品類，商鋪管理，偏向于核心價值的作為另外一個研發(fā)團隊負責的內(nèi)容。

當然這個過程最重要的就是和研發(fā)leader和產(chǎn)品leader規(guī)劃好產(chǎn)品的架構圖，因為有了架構圖才能知道哪些功能可以合并給到相似的開發(fā)和產(chǎn)品團隊。

從數(shù)據(jù)驅動的角度上講優(yōu)先把業(yè)務方需求量化和需求上線后的結果量化是核心，因為業(yè)務需求方通常涉及到的需求范圍是有限的。當然他們也會提出偏向長期用戶價值側的需求，在《運營之光：我的互聯(lián)網(wǎng)運營方法論與自白》一書里作者談道：產(chǎn)品團隊負責界定和提供長期用戶價值；而運營團隊負責創(chuàng)造短期用戶價值和協(xié)助產(chǎn)品完善長期價值。在團隊劃分上基本上業(yè)務方短期迭代的需求會高很多。

3.3.5 團隊配合工具抓手

團隊之間如何合作，驅動需求實現(xiàn)

前四項如果滿足的話，業(yè)務方也愿意用數(shù)據(jù)量化的提需求，產(chǎn)品研發(fā)也愿意承接這些需求。那么剩下的問題就是需求如何自始至終的通過系統(tǒng)傳導到需求同步需求的狀態(tài)，團隊之間如何同步信息。就這涉及到團隊協(xié)同工作的工具，這些工具包括但不限于以下：

需求管理工具：主要是負責記錄業(yè)務方提出的需求文檔。包含需求后續(xù)啟動后的狀態(tài)。文檔同步：產(chǎn)品經(jīng)理需求文檔，研發(fā)的文檔，數(shù)據(jù)文檔等等。IM工具，郵件工具，研發(fā)需求跟進工具，測試管理工具等等我就不在這里贅述了，總之管理工具要遵循的就是最小可用原則。其次是團隊盡可能的使用相似的系統(tǒng)來進行溝通，能夠合并就進行合并，這樣能夠最大程度上降低信息傳播的門檻。

我之前工作過的一家中型公司會發(fā)現(xiàn)公司有些人習慣用QQ，有些人習慣用釘釘，有些人習慣用微信，導致團隊彼此找不到對方。需求UI維護在tower上，產(chǎn)品有些人維護在Excel，有些人維護在禪道上。需求是分散的，當然就無法做到統(tǒng)一的評審。

所以數(shù)據(jù)驅動可以盡量讓大家的信息一致，同時需求的量化和一個好的評審流程可以讓團隊工作效率提高，大家千萬不要覺得這種流程化方式是低效的，遠不如業(yè)務方直接拉著產(chǎn)品和研發(fā)開發(fā)高效。但是這個流程可以保證有價值的需求可以持續(xù)的優(yōu)先被開發(fā)。

走得對，走得穩(wěn)，比走得快重要。

而有了流程之后，通過整個團隊對于流程的熟悉可以做到走得又快又穩(wěn)。

3.3.6 組織能力

數(shù)據(jù)驅動涉及部門多，要有極高的組織動員力

最后我們會發(fā)現(xiàn)推動數(shù)據(jù)驅動團隊需要從需求方到產(chǎn)品，UI，研發(fā)，數(shù)據(jù)工程師，分析師的配合。所以邏輯順下來，按照矩陣式的管理方式，我們會發(fā)現(xiàn)這個人要可以影響或者管理：需求方到產(chǎn)品，UI，研發(fā)，數(shù)據(jù)工程師，分析師等很多部門，這也就是說職級越高越容易推動這個事情。

因為它可以針對每個總監(jiān)下面的組能夠獨立出部分人員來針對增長或者業(yè)務方形成獨立的小閉環(huán)才能做這個事情。

下面我們說一下如果你沒有這么大的行政權力，又想影響你的團隊去做數(shù)據(jù)驅動，或者我們說的直白點，你想做的專業(yè)一些，讓自己起碼數(shù)據(jù)量化一起來，提升一下職場身價，你只需要兩個人的支持，或者只需要一個人。

那么你只需要一個工程師來接受你量化的需求，以及一個數(shù)據(jù)分析師來幫你提取數(shù)據(jù)就可以了。不過這個環(huán)境是否可行，極大程度上，取決于你和團隊的關系以及，團隊的管理是否有這樣的空間。極端的情況在沒有數(shù)據(jù)分析師的情況下，如果工程師很配合的話，他也是可以幫你獲取一些業(yè)務數(shù)據(jù)的，但是這樣的問題是，因為這樣拉新的需求由于沒有投放的追蹤工具，你還是沒有辦法量化。但是你可以先把產(chǎn)品上的用戶進行分析。同時考慮到?jīng)]有埋點工具你可能也沒法分析行為和業(yè)務數(shù)據(jù)之間的關系。這種情況最好的辦法就是學會數(shù)據(jù)分析能力，以及通過這個小團隊做出一些成果，盡快換一家成熟的公司。

最后我們總結一下團隊無法數(shù)據(jù)驅動的六個原因，他們是有邏輯關系的，如果你的公司團隊無法數(shù)據(jù)驅動，并不是找一個增長官或者找一個分析師就可以讓您的團隊數(shù)據(jù)驅動，他是一個系統(tǒng)的問題，只有每個環(huán)節(jié)都向數(shù)據(jù)賦能才能夠讓最終的業(yè)務進入到數(shù)據(jù)的軌道上來。這個流程好似拆線團，需要你從整體上看清問題的癥結，然后明白先解開哪個線頭，后解開哪個線頭，直接上剪刀或者解開最大的線頭（數(shù)據(jù)驅動最大的卡點）是沒有用的！難點在于規(guī)劃路徑，逐步拆解，要相信每個果都是因產(chǎn)生的，那么這個因又是由它上一個因產(chǎn)生的，逐層找因，逐步解決才行。所以我們按照邏輯在順以下如何數(shù)據(jù)驅動：

第一步：你要有數(shù)據(jù)，可以看到數(shù)據(jù)，這是數(shù)據(jù)驅動的基礎。你需要一個數(shù)據(jù)倉的同學來持續(xù)維護數(shù)據(jù)的采集到可視化的賦能。

第二步：有了數(shù)據(jù)，你就需要逐步明白看哪些數(shù)據(jù)，他們的變化意味著什么，他們彼此之間的關系是什么。這些前期可以通過增長產(chǎn)品經(jīng)理，或者產(chǎn)品負責人代為拆解，后期由分析師持續(xù)維護，當然如果你一開始就有了數(shù)據(jù)分析師那也很好，但是一定要在數(shù)據(jù)倉基本搭建完畢，再請數(shù)據(jù)分析師，否則他也沒有什么數(shù)據(jù)可以獲取。

第三步：你就要讓需求逐步量化，上線后的效果逐步量化，通過量化評估需求的優(yōu)先級，通過量化需求調(diào)度資源。所以你需要集中評審需求，管理需求。

第四步：基于需求評審通過后要快速響應業(yè)務方，就需要一個單獨的堆棧來解決業(yè)務方的需求。這樣能夠快速得實現(xiàn)需求的量化，效果量化。其次畢竟業(yè)務方辛苦的寫完文檔，告訴他要等排期會極大的打擊整體驅動的動力。

第五步：這個過程中大家如何工作你需要在啟動需求之前鋪設好大家協(xié)同信息的工具，包括需求自始至終管理的工具。這五步完成以后基本上你可以從業(yè)務方那里接受到量化的需求了。

但是這些都要建立在一個基礎上就是領導確實意識到數(shù)據(jù)量化的重要度，愿意自上而下推進這個事情。因為涉及到部門太多所以自上而下的推進是最快的。

這五步就是邏輯上因果推演下來的。每一個下一層要處理的需求，是因為上一層的邏輯導致的。這像不像拆線團。只有都解決了，才能夠讓那個數(shù)據(jù)驅動起來。

如果兩輛速度為光速的車迎面開來，那么根據(jù)相對速度他們應該是2倍的光速，但是任何速度不會超過光速，那么只有時間變變了這個才成立。

引用這個思考是想說明，邏輯上事情推理的必然也是一種令人愉悅的事情。做團隊的數(shù)據(jù)驅動要做好邏輯上的推導，對，就是拆線團。

作者：阿潤 用理工科的思維理解增長，以科學方法與概率統(tǒng)計來看待增長。