可能很多人都會有一個困惑：做運營是關注增長策略的學習還是埋點的學習？本文以此為出發點，探討增長的策略。本文總結了團隊數據驅動需要的六個步驟，希望對你有所幫助。

做運營是關注增長策略的學習還是埋點的學習？

這讓我想到了很多事情你深度思考后的出來結果和大眾認知往往是不一樣的。通常我們認為增長的策略是非常重要的。

俞軍老師講過稀缺度的問題，找產品經理是找邏輯嚴密的，因為邏輯嚴密是比較稀缺的。

相比較基礎的產品知識是好學的。所以同樣的邏輯大家面試時候多半會找懂運營策略和分析的。因為這樣的人更加稀缺。

但是這里面有一個隱含的假設：獲取數據環境也很好。所以有了很好的增長策略運營，你只要不斷的獲取數據，不斷的分析就可以持續的產生非常好的策略。

很多管理者認為招聘到好的策略分析者（本身他們很稀缺）就認為可以做數據驅動了。但是任何事情都是團隊來實現的。好的分析者只是冰山一角。只有整個組織鏈條都開始數據驅動化，不斷賦能業務人員，才能保證有持續的策略產出。

招聘到好的增長策略的運營其實只是數據驅動的開始。

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

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

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

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

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

數據獲取是整個團隊和多個系統持續向業務賦能，通常我們只能看到數據分析師。

一、啟動數據驅動前你要思考什么

1.1 為什么要數據驅動

美國科學家做過一個思想實驗：把魔方打亂，交由一個盲人還原，假設盲人永生且不需要休息，每秒轉動一次，理論上他需要多久才能將魔方復原？

答案是一百幾十億年，也就是從宇宙大爆炸到現在，還需要再等幾十億年才能實現。

如果加入一個變量——每轉動一次魔方，就有人向他反饋一個信息，告訴他是更接近目標了，還是更遠離目標了，請問盲人需要多久才能把魔方還原？答案是兩分半！

這個思想實驗揭示了一個秘密：迭代反饋是一種強大的宇宙法則。

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

1.2 數據驅動能做什么

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

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

所以數據驅動只能做到正確的做事兒。正確地轉動魔方。

事實上我們的業務比轉動魔方要復雜的多，因為轉動魔方包含的隱含下設是：錯誤和正確的信息反饋本身就包含了策略解決方案。即你不向著錯誤的方向旋轉魔方，你就一定向著正確的方向旋轉他。

但是大多數現實情況，現實的狀態反饋不會直接給到你解決方案。（這種邊的變化量復雜度，我會再寫一篇文章。）

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

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

1.3 你的業務是否可以數據驅動

在啟動數據驅動前，還需要了解的是那么就需要去思考三個問題看下看你的業務是否可以數據驅動。

這也就引出了我們的第二章節，數據驅動的三個問題：

1. 第一個問題，你的行業是否是一個增長的行業？
2. 第二個問題，你的業務是否用戶量和商業價值非常大，數據驅動價值可以支撐團隊成本。
3. 第三個問題，你的業務是不是一個可以被拆解為多個獨立小閉環的業務。

二、數據驅動需要滿足的條件

2.1 增長產生了策略

第1問：你的行業是否是一個增長的行業？

用戶量和數據量是策略產生的原因，而不是策略產生的結果。

很多老板認為當前業務不增長，我去找增長類的人才，是不是就解決了這個問題了。這就是我說的頭疼醫頭，腳疼醫腳。

首先你要想的是這個行業是否在增長。你把張小龍放到教育行業他也很難讓他增長。

所以增長的最底層是你的業務本來可以在現有的渠道下增長，或者尋找新的渠道把用戶轉化過來。

本來就是用戶有需求沒有發現渠道，或者說外部環境使得用戶會變得越來越多。增長的第一層天花板就是市場的用戶到底有多少。但是很多老板大邏輯沒有想清楚。就去找人去獲客。認為只要我有策略就會有用戶。

依照這個例子，我請來張小龍就會產生增長，不一定的。

2.2 有價值才有組織結構

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

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

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

如果還有疑問可以看這篇文章：哪類公司適合無埋點分析工具 Growing IO

2.3 業務可以被拆分獨立閉環迭代

第3問：你的業務是不是一個可以被拆解為多個獨立小閉環的業務？

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

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

1. SKU量大：SKU量大說白了就是內容分發，策略推薦，如果你業務的內容非常少，那么對于內容。你就比較難找到數據化的意義，主要是通過數據化過高效的撮合交易產生杠桿，要知道內容也是符合冪律分布的。品類管理和內容供給是「增長黑客」中很重要的一部分。
2. 交易高頻：交易單價和交易頻次是成反比的。越是價格高，交易的人也越少，頻次也越低。越是依靠銷售團隊。交易頻次越高，就意味著用戶的反饋越多。真正用戶價值=活躍用戶數*賬戶平均交易量。
3. 供應生產端反饋周期短：也就是說對于需求的供給也一定要能夠快速迭代，因為供應鏈的迭代速度決定了你可以提供的「內容」以及用戶價值。這樣才能夠快速迭代產生更大的價值。

三、如何讓團隊啟動數據驅動

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

如果讀者們覺得同時推動幾個業務方沒有話語權，我會再講如何把內部團隊做到數據驅動。

3.1 核心邏輯是矩陣式分工

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

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

Facebook把自己的業務拆分成了200多個獨立閉環迭代的團隊

拆分到單一指標后，給這個指標配置團隊，這個團隊大面上不依靠外部迭代起來，考慮到軟件開發有些系統不是這些工程師開發的。

但是一個需求的獨立承接肯定是可以的。我們看這個指標下包含了，數據分析師，工程師，產品經理，設計師，所以他們接了需求就是可以自己做需求評估，或者自己做需求迭代。而不依靠「外部資源」。只要包含越多的支持方，你數據驅動失敗的可能性就會越大。

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

指標和角色以及部門關聯關系

當你給多個指標分發團隊的時候，就形成了指標和管理的矩陣。

每個指標由橫向的崗位來驅動他的增長。

注意這里說的是崗位，因為當指標多的時候，不一定會有足夠的自然人，但是崗位必須要按照指標來設計。如果你業務足夠大，每個指標都可以養活一個團隊，那么每個崗位下都有一個。

還是我上面說的那個問題。用戶量，用戶價值決定支撐你多少人的團隊。

可能看到這里您不太明白如何劃分，您只要知道可以按照指標橫向搭建分工角色，縱向進行管理即可。切分還有很多種方案，我們在后續的文章中再去解答。

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

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

• 業務上他要做什么
• 你們配合的邊界在哪里
• 這個人的能力邊界在哪里
• 從什么角度上考核這個人
• 如何判斷這個人能力行不行

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

3.3 啟動數據驅動的核心要點

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

3.3.1 數據可獲取能力

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

數據獲取的能力絕非簡單的讀取與展示，它是一個系統獲取數據的架構。很多管理者想當然的認為我找一個會寫SQL的人來獲取數據不就行了。

但是這樣會導致未來某個時間段你的數據獲取遇到瓶頸，你業務發展速度越快，這個瓶頸越快的來臨。我的建議最好還是有專人負責數據存儲系統的搭建和前期輕量化的數據提取工作。

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

數據獲取的成本和范圍，品類，很大程度上取決于數據系統體系。

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

初始數據團隊的工作內容

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

比如說其實我們最開始我們可能只需要關注的是流量數據和業務數據，以及他們之間的關聯先把流量和留存兩部分關聯起來即知道流量的價值，也知道當前產品留存的情況，等到業務方發展到一定的階段，我們慢慢就開始做安全體驗相關的數據建設。

其實它是隨著業務的發展而逐步迭代的，還有一個整個重心的變化，數倉整個建設也會逐步迭代。所以你要去關注你的關鍵業務，在某個階段，它的關鍵業務是什么？

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

在這時候我們同時要做元數據的一個規范化的管理，數倉產出一張表，表的comment(每個字段說明)是空的，或者說不準確的，你的表的特征它也是不準的。所以當數據分析師去用的時候，或者說相關同學去用的時候，就發現你做這個事情，你做這個產出物是沒有什么太大的價值。

因為整個的數據不是很規范，大家也不理解。比如下單，又有很多種命名，很多的業務線都有記錄，很多的表上都有這個字段的名稱。有五六種其實大家不知道到底哪個是下單的字段。其實這個就是一個很痛的點，所以元數據的規范化，在數倉的一個初始階段就要去做，

業務圖譜，對于數倉團隊，他首先要去理解業務，才能去做對應的數據建設，還有指標化的建設。所以我們最開始比如說做訂單的時候，我們就會先去做整個交易主鏈路的流程，從開始他的發單和接單到整個鏈路支付完成，我們是把整個的主鏈路去梳理出來，然后針對于每個主鏈路，它里面具體的一些業務過程是什么，其實這個就是數倉團隊在整個業務圖中怎么去梳理出來，在這里面我們才能提煉出哪些關鍵的點。

所以這個就是業務統籌，其實也是通過這個層面來讓數倉的同學更好地去理解業務，更加站在業務的視角，用戶的視角去理解數據能去做什么。

然后統一的需求把控。這個在初始階段其實也是一個很重要。

大家會講煙囪式的建設，其實煙囪式建設要兩面性來看，不是煙囪式建設就不好，特別是在業務發展初期，它的驗證式建設，其實它能快速的去迭代去發展，如果你的整個規范性，你的很多流程其實OK的。

其實煙囪式建設其實還是在一個可控的范圍內了，但在這個層面我們就要做整體的需求把控，其實是做一些適當的冗余是OK的，因為在這個時候，其實我們的相關的數據的口徑是不確定的，其實業務也不清楚說我們的口徑到底是什么樣，其實也是在一個探索的過程。

這就要講到一個統一的指標體系，統一的指標體系是所有的數據團隊，或者說我們對用戶都是一個非常痛的點，其實我們后面會講一下。

所以在這個初始階段，核心的關注是這些內容等到了發展階段，收藏團隊發展階段，當時我們收藏團隊讓那個看的是人的能力，還有整個團隊的協同，已經有了一定的默契，然后同時呢業務的發展我們也有一定的沉淀和積累，所以在這個里面我們會幫助用戶去做對應的一些分析跟應用應用型的一些產品。

所以在這個層面上，比如我們初始階段更多是幫助用戶快速的看數據去去做決策，所以這里面更多的是以核心的報表和看板為主，等到你的發展階段的時候，用戶要做一些精細化的運營，所以在這里面我們要提供一些相關的一些分析類的產品。啊，還有一些策略診斷類的行為，或者評估類的一些產品。

3.3.2 指標拆解能力

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

如果我們有了獲取數據的能力，具備對用戶，交易，獲客渠道的基本分析，我們就要針對業務進行指標拆解。渠道端做到每個渠道流量數據清晰，包含每個渠道帶來的業務數據，例如GMV等等?？梢栽u估渠道價值的數據。

交易側可以看清留存，激活，對于活躍的構成，交易的品類，對于用戶側可以看清高價值用戶。

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

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

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

3.3.3 需求開發流程

一切從源頭開始，互聯網公司大部分核心價值是通過線上產品或者軟件產品把價值傳達給用戶的。那么需求的量化管理是數據驅動真正的開始。

如果說之前的兩步：獲取數據能力，以及拆解數據能力是打掃家門，那么從量化需求開始數據驅動，則真正做到了迎接客人。

即后續的新增需求都會按照量化權衡優先級的方式來判斷先開發哪些功能，后開發哪些功能。就能夠真正做到數據驅動，有效通過量化來權衡優先級，逐步釋放業務壓力。

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

1. 有利于業務方整理需求內容。寫作本身是一種思考和反向輸出，所以在寫的過程中就助于整理業務方的思路。需求背景，針對的用戶，現狀，痛點，因此要做哪些功能，解決的問題，預估收益都有一個很好的梳理思考。
2. 有利于業務方圈定需求范圍。通常業務方會頻發的改需求，除了上面沒有梳理好自己的想要什么之外，通常的情況是雙方并沒有針對需求達成范圍。業務方和產品對于解決方案的功能范圍認知存在偏差。所以寫出來流程和大體規則與功能有助于產品經理和業務方在認知上快速達成一致。
3. 有利于產品經理理解業務方需求。就算是業務方自己確定要什么，隨著時間的推移可能也會產生偏差。以及如果是口述的需求需要被迫產品經理記住。這樣的溝通是非常低效的。
4. 文檔存在本身就是有價值的。無論通過的，還是沒有通過的需求。對于通過的需求后續的產品經理接手后知道在之前什么情況下迭代了什么需求。同時需求方也可以明白，哪些用戶的需求做到什么樣了。新來的人知道過去哪些需求被否定過了，為什么被否定了，是不是現在條件還不成立，那就不用再次浪費時間提出了?；蛘哒f條件有變化了，也可以在原來被駁回的需求上思考。

很多人會反駁說業務方都很忙沒有時間寫需求文檔，我的看法是一個需求啟動后，要經歷產品，設計，研發，測試，數據等等多種人員的環節，要花費這些人員的時間，相比較這些人員的成本來說，把需求描述清晰，量化了反而是一個提高效率的方法。

有一種說法是提錯誤需求的人還不如不提需求，因為它還占用了資源。對于這種人發工資什么都不做，都好過這些人提需求。

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

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

3.3.4 產品和研發剝離

如果前三項基本滿足那么第四項是一個邏輯必然推導的結果，如果你的需求方可以量化的提需求，你可以量化的評估需求，評估過后就要有產品和開發能夠實現需求，同時也能夠做好這些需求的數據監控。

所以說如果想做到數據驅動，最好對組織結構做相應的改造，核心的思路是讓運營和業務類需求和長期用戶價值的需求走兩個堆棧。逐步實現研發側逐步小閉環分工化。

我們認為指標，功能，以及對應的開發是有相關度的。當然并不是絕對的。但是盡量我們要做到可以切分成獨立的閉環（盡管可能存在藕斷絲連的情況）但是大體趨勢上是獨立的。

整體的切割邏輯在3.1章節核心邏輯是矩陣式分工那節已經進行了講解，我這里做另外一個角度的陳述就是大體思路可以把偏向營銷的如落地頁工具，運營引擎，投放引擎，消息觸達中心等等這些屬于偏向與運營和銷售類的功能并攏到增長產品方研發團隊，另外一類會偏向于用戶價值長期建設，我們以電商舉例比如類目，品類，商鋪管理，偏向于核心價值的作為另外一個研發團隊負責的內容。

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

從數據驅動的角度上講優先把業務方需求量化和需求上線后的結果量化是核心，因為業務需求方通常涉及到的需求范圍是有限的。

當然他們也會提出偏向長期用戶價值側的需求，在《運營之光：我的互聯網運營方法論與自白》一書里作者談道：產品團隊負責界定和提供長期用戶價值；而運營團隊負責創造短期用戶價值和協助產品完善長期價值。在團隊劃分上基本上業務方短期迭代的需求會高很多。

3.3.5 團隊配合工具抓手

團隊之間如何合作，驅動需求實現。

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

需求管理工具：主要是負責記錄業務方提出的需求文檔。包含需求后續啟動后的狀態。

文檔同步：產品經理需求文檔，研發的文檔，數據文檔等等。

IM工具，郵件工具，研發需求跟進工具，測試管理工具等等我就不在這里贅述了，總之管理工具要遵循的就是最小可用原則。其次是團隊盡可能的使用相似的系統來進行溝通，能夠合并就進行合并，這樣能夠最大程度上降低信息傳播的門檻。

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

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

走得對，走得穩，比走得快重要。

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

3.3.6 組織能力

數據驅動涉及部門多，要有極高的組織動員力

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

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

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

那么你只需要一個工程師來接受你量化的需求，以及一個數據分析師來幫你提取數據就可以了。

不過這個環境是否可行，極大程度上，取決于你和團隊的關系以及，團隊的管理是否有這樣的空間。極端的情況在沒有數據分析師的情況下，如果工程師很配合的話，他也是可以幫你獲取一些業務數據的，但是這樣的問題是，因為這樣拉新的需求由于沒有投放的追蹤工具，你還是沒有辦法量化。

但是你可以先把產品上的用戶進行分析。同時考慮到沒有埋點工具你可能也沒法分析行為和業務數據之間的關系。這種情況最好的辦法就是學會數據分析能力，以及通過這個小團隊做出一些成果，盡快換一家成熟的公司。

最后我們總結一下團隊無法數據驅動的六個原因，他們是有邏輯關系的，如果你的公司團隊無法數據驅動，并不是找一個增長官或者找一個分析師就可以讓您的團隊數據驅動，他是一個系統的問題，只有每個環節都向數據賦能才能夠讓最終的業務進入到數據的軌道上來。

這個流程好似拆線團，需要你從整體上看清問題的癥結，然后明白先解開哪個線頭，后解開哪個線頭，直接上剪刀或者解開最大的線頭（數據驅動最大的卡點）是沒有用的！

難點在于規劃路徑，逐步拆解，要相信每個果都是因產生的，那么這個因又是由它上一個因產生的，逐層找因，逐步解決才行。所以我們按照邏輯在順以下如何數據驅動：

1. 第一步：你要有數據，可以看到數據，這是數據驅動的基礎。你需要一個數據倉的同學來持續維護數據的采集到可視化的賦能。
2. 第二步：有了數據，你就需要逐步明白看哪些數據，他們的變化意味著什么，他們彼此之間的關系是什么。這些前期可以通過增長產品經理，或者產品負責人代為拆解，后期由分析師持續維護，當然如果你一開始就有了數據分析師那也很好，但是一定要在數據倉基本搭建完畢，再請數據分析師，否則他也沒有什么數據可以獲取。
3. 第三步：你就要讓需求逐步量化，上線后的效果逐步量化，通過量化評估需求的優先級，通過量化需求調度資源。所以你需要集中評審需求，管理需求。
4. 第四步：基于需求評審通過后要快速響應業務方，就需要一個單獨的堆棧來解決業務方的需求。這樣能夠快速得實現需求的量化，效果量化。其次畢竟業務方辛苦的寫完文檔，告訴他要等排期會極大的打擊整體驅動的動力。
5. 第五步：這個過程中大家如何工作你需要在啟動需求之前鋪設好大家協同信息的工具，包括需求自始至終管理的工具。這五步完成以后基本上你可以從業務方那里接受到量化的需求了。

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

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

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

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