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

團隊數(shù)據(jù)驅(qū)動需要六個步驟可能很多人都會有一個困惑：做運營是關(guān)注增長策略的學(xué)習(xí)還是埋點的學(xué)習(xí)？本文以此為出發(fā)點，探討增長的策略。本文總結(jié)了團隊數(shù)據(jù)驅(qū)動需要的六個步驟，希望對你有所幫助。做運營是關(guān)注增長策略的學(xué)習(xí)還是埋點的學(xué)習(xí)？這讓我想到了很多事情你深度思考后的出來結(jié)果和大眾認知往往是不一樣的。通常我們認為增長的策略是非常重要的。俞軍老師講過稀缺度的問題，找產(chǎn)品經(jīng)理是找邏輯嚴密的，因為邏輯嚴密是比較稀缺的。相比較基礎(chǔ)的產(chǎn)品知識是好學(xué)的。所以同樣的邏輯大家面試時候多半會找懂運營策略和分析的。因為這樣的人更加稀缺。但是這里面有一個隱含的假設(shè)：獲取數(shù)據(jù)環(huán)境也很好。所以有了很好的增長策略運營，你只要不斷的獲取數(shù)據(jù)，不斷的分析就可以持續(xù)的產(chǎn)生非常好的策略。很多管理者認為招聘到好的策略分析者（本身他們很稀缺）就認為可以做數(shù)據(jù)驅(qū)動了。但是任何事情都是團隊來實現(xiàn)的。好的分析者只是冰山一角。只有整個組織鏈條都開始數(shù)據(jù)驅(qū)動化，不斷賦能業(yè)務(wù)人員，才能保證有持續(xù)的策略產(chǎn)出。招聘到好的增長策略的運營其實只是數(shù)據(jù)驅(qū)動的開始。因為我最近咨詢的公司都或多或少因為這些因素?zé)o法數(shù)據(jù)驅(qū)動。通常造成這種阻力的原因：他們都只看到了無法數(shù)據(jù)驅(qū)動的某個切片問題，或者某個節(jié)點問題。但是按照我上一篇文章寫的大處著眼小處著手。往往找到的解法都是頭疼醫(yī)頭，腳疼醫(yī)腳的方案。如果真的想把團隊轉(zhuǎn)化為一個數(shù)據(jù)驅(qū)動的團隊，就要從整體梳理清楚阻礙團隊無法數(shù)據(jù)驅(qū)動的點有哪些。這個過程非常像解開一堆非常亂的線頭，你要先從整體梳理好，然后再一個一個解開。除此之外別無辦法。其次任何團隊的改革都是一個循序漸進的過程，這里面拋開利益關(guān)系的問題，團隊成員能力模型，工作流程，工作習(xí)慣都是需要逐步引導(dǎo)的。貿(mào)然大動都會導(dǎo)致團體排異（如果我們把組織看作一個有機體）所以我會給到您一個查驗清單按照這個邏輯，找到冰山以下「水面下」影響增長驅(qū)動的因素。希望你的組織也能夠轉(zhuǎn)化到數(shù)據(jù)驅(qū)動的流程上來。數(shù)據(jù)獲取是整個團隊和多個系統(tǒng)持續(xù)向業(yè)務(wù)賦能，通常我們只能看到數(shù)據(jù)分析師。一、啟動數(shù)據(jù)驅(qū)動前你要思考什么1.1為什么要數(shù)據(jù)驅(qū)動美國科學(xué)家做過一個思想實驗：把魔方打亂，交由一個盲人還原，假設(shè)盲人永生且不需要休息，每秒轉(zhuǎn)動一次，理論上他需要多久才能將魔方復(fù)原？答案是一百幾十億年，也就是從宇宙大爆炸到現(xiàn)在，還需要再等幾十億年才能實現(xiàn)。如果加入一個變量——每轉(zhuǎn)動一次魔方，就有人向他反饋一個信息，告訴他是更接近目標了，還是更遠離目標了，請問盲人需要多久才能把魔方還原？答案是兩分半！這個思想實驗揭示了一個秘密：迭代反饋是一種強大的宇宙法則。我們做數(shù)據(jù)化就是為了讓我們所有的策略變得可視，可以看到結(jié)果的量化，就意味著每次轉(zhuǎn)動魔方知道是轉(zhuǎn)對了還是轉(zhuǎn)錯了，就可以提升迭代的速度。1.2數(shù)據(jù)驅(qū)動能做什么數(shù)據(jù)驅(qū)動就是讓結(jié)果可以被量化，整體的業(yè)務(wù)可以被量化，數(shù)據(jù)只能告訴你現(xiàn)狀，好比病人去醫(yī)院看病，醫(yī)生告訴你高血壓，他不能給你開降壓藥，如果我們把人的身體比作業(yè)務(wù)，數(shù)據(jù)驅(qū)動只能告訴你當(dāng)前你的業(yè)務(wù)狀態(tài)，他并不能告訴你造成這個狀態(tài)的原因。當(dāng)然如果你的數(shù)據(jù)基數(shù)非常大的時候，這種情況下你通過做一些策略，一些修改迭代找到策略和結(jié)果的相關(guān)度就是可以的。但是我們依然不鼓勵這么做，最好還是需要你做數(shù)據(jù)驅(qū)動，還需要做用戶調(diào)研和需求分析。所以數(shù)據(jù)驅(qū)動只能做到正確的做事兒。正確地轉(zhuǎn)動魔方。事實上我們的業(yè)務(wù)比轉(zhuǎn)動魔方要復(fù)雜的多，因為轉(zhuǎn)動魔方包含的隱含下設(shè)是：錯誤和正確的信息反饋本身就包含了策略解決方案。即你不向著錯誤的方向旋轉(zhuǎn)魔方，你就一定向著正確的方向旋轉(zhuǎn)他。但是大多數(shù)現(xiàn)實情況，現(xiàn)實的狀態(tài)反饋不會直接給到你解決方案。（這種邊的變化量復(fù)雜度，我會再寫一篇文章。）但是長期正確的做事可以極大地提升做正確的事情的概率。我們最終的訴求是把事情做正確，但是這并不是數(shù)據(jù)驅(qū)動業(yè)務(wù)必然的結(jié)果，數(shù)據(jù)驅(qū)動業(yè)務(wù)是做正確的事情的基礎(chǔ)。1.3你的業(yè)務(wù)是否可以數(shù)據(jù)驅(qū)動在啟動數(shù)據(jù)驅(qū)動前，還需要了解的是那么就需要去思考三個問題看下看你的業(yè)務(wù)是否可以數(shù)據(jù)驅(qū)動。這也就引出了我們的第二章節(jié)，數(shù)據(jù)驅(qū)動的三個問題：第一個問題，你的行業(yè)是否是一個增長的行業(yè)？第二個問題，你的業(yè)務(wù)是否用戶量和商業(yè)價值非常大，數(shù)據(jù)驅(qū)動價值可以支撐團隊成本。第三個問題，你的業(yè)務(wù)是不是一個可以被拆解為多個獨立小閉環(huán)的業(yè)務(wù)。二、數(shù)據(jù)驅(qū)動需要滿足的條件2.1增長產(chǎn)生了策略第1問：你的行業(yè)是否是一個增長的行業(yè)？用戶量和數(shù)據(jù)量是策略產(chǎn)生的原因，而不是策略產(chǎn)生的結(jié)果。很多老板認為當(dāng)前業(yè)務(wù)不增長，我去找增長類的人才，是不是就解決了這個問題了。這就是我說的頭疼醫(yī)頭，腳疼醫(yī)腳。首先你要想的是這個行業(yè)是否在增長。你把張小龍放到教育行業(yè)他也很難讓他增長。所以增長的最底層是你的業(yè)務(wù)本來可以在現(xiàn)有的渠道下增長，或者尋找新的渠道把用戶轉(zhuǎn)化過來。本來就是用戶有需求沒有發(fā)現(xiàn)渠道，或者說外部環(huán)境使得用戶會變得越來越多。增長的第一層天花板就是市場的用戶到底有多少。但是很多老板大邏輯沒有想清楚。就去找人去獲客。認為只要我有策略就會有用戶。依照這個例子，我請來張小龍就會產(chǎn)生增長，不一定的。2.2有價值才有組織結(jié)構(gòu)第2問：你的業(yè)務(wù)是否用戶量和商業(yè)價值非常大，數(shù)據(jù)驅(qū)動價值可以支撐團隊成本？接著第一條講解，就是你預(yù)估這個行業(yè)有多少用戶量，越大的用戶量，你做優(yōu)化產(chǎn)生的價值越大，可以提供的薪資和職位就會多。業(yè)務(wù)體量決定組織結(jié)構(gòu)，你們用戶量每天千萬，你做個數(shù)據(jù)驅(qū)動的算法和策略才有價值，你提升個百分之一ARPU值，你用戶基數(shù)這么大。一年下來你創(chuàng)造的價值足夠養(yǎng)活你們這些算法工程師了，可能他們創(chuàng)造的收益還遠遠大于他們的工資（通常業(yè)務(wù)體量大的公司一定是這樣的）。如果你的業(yè)務(wù)天花板很小，不會有很大量用戶的可能，那么你就不需要做數(shù)據(jù)驅(qū)動，因為這個團隊，這些人才，他們創(chuàng)造不了這個價值，也就意味著這個業(yè)務(wù)也養(yǎng)活不起這樣的團隊。如果還有疑問可以看這篇文章：哪類公司適合無埋點分析工具GrowingIO2.3業(yè)務(wù)可以被拆分獨立閉環(huán)迭代第3問：你的業(yè)務(wù)是不是一個可以被拆解為多個獨立小閉環(huán)的業(yè)務(wù)？數(shù)據(jù)一直在服務(wù)商業(yè)：傳統(tǒng)企業(yè)用財務(wù)數(shù)據(jù)，長周期的業(yè)務(wù)結(jié)果數(shù)據(jù)做商業(yè)分析，也是數(shù)據(jù)服務(wù)于商業(yè)。所以從這角度看業(yè)務(wù)并不能說傳統(tǒng)企業(yè)不是數(shù)據(jù)驅(qū)動的。互聯(lián)網(wǎng)業(yè)務(wù)的本質(zhì)是線上化：今天互聯(lián)網(wǎng)業(yè)務(wù)的數(shù)據(jù)驅(qū)動，根本變化在于業(yè)務(wù)發(fā)生的主體過程線上化了，業(yè)務(wù)動作線上化了，衍生出來快速迭代和重視流量等新的特點。因為用戶所有的行為都「線上閉環(huán)」的。其次最好支持你的業(yè)務(wù)的系統(tǒng)都是線上化的這樣方便你把業(yè)務(wù)切分成獨立閉環(huán)。刨除用戶量你還需要考慮三個要素：SKU量大：SKU量大說白了就是內(nèi)容分發(fā)，策略推薦，如果你業(yè)務(wù)的內(nèi)容非常少，那么對于內(nèi)容。你就比較難找到數(shù)據(jù)化的意義，主要是通過數(shù)據(jù)化過高效的撮合交易產(chǎn)生杠桿，要知道內(nèi)容也是符合冪律分布的。品類管理和內(nèi)容供給是「增長黑客」中很重要的一部分。交易高頻：交易單價和交易頻次是成反比的。越是價格高，交易的人也越少，頻次也越低。越是依靠銷售團隊。交易頻次越高，就意味著用戶的反饋越多。真正用戶價值=活躍用戶數(shù)*賬戶平均交易量。供應(yīng)生產(chǎn)端反饋周期短：也就是說對于需求的供給也一定要能夠快速迭代，因為供應(yīng)鏈的迭代速度決定了你可以提供的「內(nèi)容」以及用戶價值。這樣才能夠快速迭代產(chǎn)生更大的價值。三、如何讓團隊啟動數(shù)據(jù)驅(qū)動整體上我們會從數(shù)據(jù)，工作流程，產(chǎn)品架構(gòu)，組織分工，組織動員這五個方向來做逐步的講解可以讓你做到數(shù)據(jù)驅(qū)動。我們會先講如何把你的業(yè)務(wù)短期需求數(shù)據(jù)驅(qū)動。會涉及幾個業(yè)務(wù)方。如果讀者們覺得同時推動幾個業(yè)務(wù)方?jīng)]有話語權(quán)，我會再講如何把內(nèi)部團隊做到數(shù)據(jù)驅(qū)動。3.1核心邏輯是矩陣式分工因為你的業(yè)務(wù)可以被拆分成多個獨立迭代的小閉環(huán)，也就意味著你的核心指標可以被劃分成很多獨立的小指標，下發(fā)給各個團隊。這就是一個還原論的邏輯，我的大系統(tǒng)可以被拆分成小系統(tǒng)。我的小系統(tǒng)可以加總等于我的大系統(tǒng)，如果我的小系統(tǒng)增長了，那么我的大系統(tǒng)就增長了。所以我們單看一個指標如下圖：Facebook把自己的業(yè)務(wù)拆分成了200多個獨立閉環(huán)迭代的團隊拆分到單一指標后，給這個指標配置團隊，這個團隊大面上不依靠外部迭代起來，考慮到軟件開發(fā)有些系統(tǒng)不是這些工程師開發(fā)的。但是一個需求的獨立承接肯定是可以的。我們看這個指標下包含了，數(shù)據(jù)分析師，工程師，產(chǎn)品經(jīng)理，設(shè)計師，所以他們接了需求就是可以自己做需求評估，或者自己做需求迭代。而不依靠「外部資源」。只要包含越多的支持方，你數(shù)據(jù)驅(qū)動失敗的可能性就會越大。下面我們看下針對多個指標的團隊矩陣。指標和角色以及部門關(guān)聯(lián)關(guān)系當(dāng)你給多個指標分發(fā)團隊的時候，就形成了指標和管理的矩陣。每個指標由橫向的崗位來驅(qū)動他的增長。注意這里說的是崗位，因為當(dāng)指標多的時候，不一定會有足夠的自然人，但是崗位必須要按照指標來設(shè)計。如果你業(yè)務(wù)足夠大，每個指標都可以養(yǎng)活一個團隊，那么每個崗位下都有一個。還是我上面說的那個問題。用戶量，用戶價值決定支撐你多少人的團隊?？赡芸吹竭@里您不太明白如何劃分，您只要知道可以按照指標橫向搭建分工角色，縱向進行管理即可。切分還有很多種方案，我們在后續(xù)的文章中再去解答。3.2成事者以找替身為第一要務(wù)無論您再怎么想做數(shù)據(jù)驅(qū)動上面說的小團隊里面的人是不能或缺的。找對人后就能把一個方向或者部門的業(yè)務(wù)做好。畢竟管理者不能親自擼起袖子去做所有的事兒。在繁瑣的日常中活活累死。所以找對人是非常重要的。其次還是我昨天說的。業(yè)務(wù)上他要做什么你們配合的邊界在哪里這個人的能力邊界在哪里從什么角度上考核這個人如何判斷這個人能力行不行這些問題要想清楚。所以既然找替身是第一重要的事情，我所以我們先從找人說起。3.3啟動數(shù)據(jù)驅(qū)動的核心要點我們覺得招聘人員來做數(shù)據(jù)驅(qū)動事情。那么招聘來的人，要做什么呢，我們總結(jié)了以下六個方向的事情。從數(shù)據(jù)，工作流程，產(chǎn)品架構(gòu)，組織分工，只有把這四個方向都做好了才能做到數(shù)據(jù)驅(qū)動。3.3.1數(shù)據(jù)可獲取能力數(shù)據(jù)可獲取能力是數(shù)據(jù)驅(qū)動的基礎(chǔ)，任何業(yè)務(wù)維度，如果我們連數(shù)據(jù)都無法獲取，那么這個業(yè)務(wù)維度就無法做到數(shù)據(jù)驅(qū)動。通常情況行業(yè)管這個團隊叫做數(shù)倉團隊。數(shù)倉團隊核心聚焦于「數(shù)據(jù)驅(qū)動決策賦能」「數(shù)據(jù)驅(qū)動產(chǎn)品增長」這兩個部分。數(shù)據(jù)獲取的能力絕非簡單的讀取與展示，它是一個系統(tǒng)獲取數(shù)據(jù)的架構(gòu)。很多管理者想當(dāng)然的認為我找一個會寫SQL的人來獲取數(shù)據(jù)不就行了。但是這樣會導(dǎo)致未來某個時間段你的數(shù)據(jù)獲取遇到瓶頸，你業(yè)務(wù)發(fā)展速度越快，這個瓶頸越快的來臨。我的建議最好還是有專人負責(zé)數(shù)據(jù)存儲系統(tǒng)的搭建和前期輕量化的數(shù)據(jù)提取工作。就算是初始啟動期也要有相應(yīng)的數(shù)據(jù)架構(gòu)來滿足獲取數(shù)據(jù)的需求。從「數(shù)據(jù)采集」「傳輸」「存儲」「處理」「應(yīng)用」六個維度來思考最終賦能業(yè)務(wù)方。有一個初始團隊數(shù)據(jù)賦能的架構(gòu)，后續(xù)從這六個維度上來逐步豐富整個數(shù)據(jù)賦能的架構(gòu)。數(shù)據(jù)獲取的成本和范圍，品類，很大程度上取決于數(shù)據(jù)系統(tǒng)體系。大部分我們覺得數(shù)據(jù)分析成本過高，很大程度上都是冰山理論事實上是水面下的數(shù)據(jù)獲取架構(gòu)做的不行，不能夠提供低成本的獲取數(shù)據(jù)的方案。初始數(shù)據(jù)團隊的工作內(nèi)容業(yè)務(wù)的初始時候，我們更多的是以報表的形式來提供，比如說你的數(shù)倉團隊剛剛成立的時候，業(yè)務(wù)也在初步的發(fā)展也在持續(xù)的一個發(fā)展初期，你的人員的構(gòu)成都屬于在一個磨合期，這業(yè)務(wù)其實也是在一個相當(dāng)于一個探索期，所以在這里邊其實數(shù)倉團隊更多的是你提供報表。比如說其實我們最開始我們可能只需要關(guān)注的是流量數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，以及他們之間的關(guān)聯(lián)先把流量和留存兩部分關(guān)聯(lián)起來即知道流量的價值，也知道當(dāng)前產(chǎn)品留存的情況，等到業(yè)務(wù)方發(fā)展到一定的階段，我們慢慢就開始做安全體驗相關(guān)的數(shù)據(jù)建設(shè)。其實它是隨著業(yè)務(wù)的發(fā)展而逐步迭代的，還有一個整個重心的變化，數(shù)倉整個建設(shè)也會逐步迭代。所以你要去關(guān)注你的關(guān)鍵業(yè)務(wù)，在某個階段，它的關(guān)鍵業(yè)務(wù)是什么？對應(yīng)的就是我們的關(guān)鍵數(shù)據(jù)源，因為你知道你需要什么，才知道說你去采集什么，比如產(chǎn)品和研發(fā)有上萬張表，我們不可能什么把所有的表都可以采集到「數(shù)倉」里面，所以你要有一定的就是相對要有一定的范圍，所以在這里邊其實就是通過關(guān)鍵業(yè)務(wù)為抓手，來去做對應(yīng)的關(guān)鍵數(shù)據(jù)源的采集。在這時候我們同時要做元數(shù)據(jù)的一個規(guī)范化的管理，數(shù)倉產(chǎn)出一張表，表的comment(每個字段說明)是空的，或者說不準確的，你的表的特征它也是不準的。所以當(dāng)數(shù)據(jù)分析師去用的時候，或者說相關(guān)同學(xué)去用的時候，就發(fā)現(xiàn)你做這個事情，你做這個產(chǎn)出物是沒有什么太大的價值。因為整個的數(shù)據(jù)不是很規(guī)范，大家也不理解。比如下單，又有很多種命名，很多的業(yè)務(wù)線都有記錄，很多的表上都有這個字段的名稱。有五六種其實大家不知道到底哪個是下單的字段。其實這個就是一個很痛的點，所以元數(shù)據(jù)的規(guī)范化，在數(shù)倉的一個初始階段就要去做，業(yè)務(wù)圖譜，對于數(shù)倉團隊，他首先要去理解業(yè)務(wù)，才能去做對應(yīng)的數(shù)據(jù)建設(shè)，還有指標化的建設(shè)。所以我們最開始比如說做訂單的時候，我們就會先去做整個交易主鏈路的流程，從開始他的發(fā)單和接單到整個鏈路支付完成，我們是把整個的主鏈路去梳理出來，然后針對于每個主鏈路，它里面具體的一些業(yè)務(wù)過程是什么，其實這個就是數(shù)倉團隊在整個業(yè)務(wù)圖中怎么去梳理出來，在這里面我們才能提煉出哪些關(guān)鍵的點。所以這個就是業(yè)務(wù)統(tǒng)籌，其實也是通過這個層面來讓數(shù)倉的同學(xué)更好地去理解業(yè)務(wù)，更加站在業(yè)務(wù)的視角，用戶的視角去理解數(shù)據(jù)能去做什么。然后統(tǒng)一的需求把控。這個在初始階段其實也是一個很重要。大家會講煙囪式的建設(shè)，其實煙囪式建設(shè)要兩面性來看，不是煙囪式建設(shè)就不好，特別是在業(yè)務(wù)發(fā)展初期，它的驗證式建設(shè)，其實它能快速的去迭代去發(fā)展，如果你的整個規(guī)范性，你的很多流程其實OK的。其實煙囪式建設(shè)其實還是在一個可控的范圍內(nèi)了，但在這個層面我們就要做整體的需求把控，其實是做一些適當(dāng)?shù)娜哂嗍荗K的，因為在這個時候，其實我們的相關(guān)的數(shù)據(jù)的口徑是不確定的，其實業(yè)務(wù)也不清楚說我們的口徑到底是什么樣，其實也是在一個探索的過程。這就要講到一個統(tǒng)一的指標體系，統(tǒng)一的指標體系是所有的數(shù)據(jù)團隊，或者說我們對用戶都是一個非常痛的點，其實我們后面會講一下。所以在這個初始階段，核心的關(guān)注是這些內(nèi)容等到了發(fā)展階段，收藏團隊發(fā)展階段，當(dāng)時我們收藏團隊讓那個看的是人的能力，還有整個團隊的協(xié)同，已經(jīng)有了一定的默契，然后同時呢業(yè)務(wù)的發(fā)展我們也有一定的沉淀和積累，所以在這個里面我們會幫助用戶去做對應(yīng)的一些分析跟應(yīng)用應(yīng)用型的一些產(chǎn)品。所以在這個層面上，比如我們初始階段更多是幫助用戶快速的看數(shù)據(jù)去去做決策，所以這里面更多的是以核心的報表和看板為主，等到你的發(fā)展階段的時候，用戶要做一些精細化的運營，所以在這里面我們要提供一些相關(guān)的一些分析類的產(chǎn)品。啊，還有一些策略診斷類的行為，或者評估類的一些產(chǎn)品。3.3.2指標拆解能力可以理解業(yè)務(wù)，反饋領(lǐng)導(dǎo)側(cè)，可以測算收益，對需求可以權(quán)衡如果我們有了獲取數(shù)據(jù)的能力，具備對用戶，交易，獲客渠道的基本分析，我們就要針對業(yè)務(wù)進行指標拆解。渠道端做到每個渠道流量數(shù)據(jù)清晰，包含每個渠道帶來的業(yè)務(wù)數(shù)據(jù)，例如GMV等等。可以評估渠道價值的數(shù)據(jù)。交易側(cè)可以看清留存，激活，對于活躍的構(gòu)成，交易的品類，對于用戶側(cè)可以看清高價值用戶。這個過程需要一個可以拆解業(yè)務(wù)指標的人，有拆解能力的。但是建議核心管理層都要嘗試拆解一下?；蛘哌€有能力快速理解這個拆解邏輯。拆解指標主要是為了對核心業(yè)務(wù)的主要影響因素有一個理性的數(shù)據(jù)上，「劑量」上的認知，而不是感性的，例如我知道它的影響很大。這可以給到領(lǐng)導(dǎo)側(cè)方便領(lǐng)導(dǎo)側(cè)看清業(yè)務(wù)。同時我自己工作的經(jīng)驗發(fā)現(xiàn)很多領(lǐng)導(dǎo)要看數(shù)，事實上是上一個環(huán)節(jié)沒有搞懂，就是他自己對于要看哪些指標他們反應(yīng)了什么并不是很清楚。導(dǎo)致每次給到他們數(shù)據(jù)，他們還是覺得數(shù)據(jù)不夠。但是豐富哪些又說不出來。最后一個邏輯是你有了數(shù)據(jù)，就可以評估大概一個功能的轉(zhuǎn)化率。就可以測算收益，以及數(shù)據(jù)評估可以預(yù)估這個需求的用戶，有了收益預(yù)估，又有了用戶價值你就可以權(quán)衡需求的優(yōu)先級。所以就具備了基本的數(shù)據(jù)驅(qū)動的環(huán)境。3.3.3需求開發(fā)流程一切從源頭開始，互聯(lián)網(wǎng)公司大部分核心價值是通過線上產(chǎn)品或者軟件產(chǎn)品把價值傳達給用戶的。那么需求的量化管理是數(shù)據(jù)驅(qū)動真正的開始。如果說之前的兩步：獲取數(shù)據(jù)能力，以及拆解數(shù)據(jù)能力是打掃家門，那么從量化需求開始數(shù)據(jù)驅(qū)動，則真正做到了迎接客人。即后續(xù)的新增需求都會按照量化權(quán)衡優(yōu)先級的方式來判斷先開發(fā)哪些功能，后開發(fā)哪些功能。就能夠真正做到數(shù)據(jù)驅(qū)動，有效通過量化來權(quán)衡優(yōu)先級，逐步釋放業(yè)務(wù)壓力。同時能夠很大程度上激勵開發(fā)人員，反向管理業(yè)務(wù)方，在這里我要論證一下為什么要業(yè)務(wù)方提需求寫需求文檔，我之前也在小的公司工作過，這些公司很多時候都是一句話需求，和真正完善的需求文檔也是有差別的，差別不在字數(shù)上，而是要把問題講明白。我們認為撰寫文檔有如下好處：有利于業(yè)務(wù)方整理需求內(nèi)容。寫作本身是一種思考和反向輸出，所以在寫的過程中就助于整理業(yè)務(wù)方的思路。需求背景，針對的用戶，現(xiàn)狀，痛點，因此要做哪些功能，解決的問題，預(yù)估收益都有一個很好的梳理思考。有利于業(yè)務(wù)方圈定需求范圍。通常業(yè)務(wù)方會頻發(fā)的改需求，除了上面沒有梳理好自己的想要什么之外，通常的情況是雙方并沒有針對需求達成范圍。業(yè)務(wù)方和產(chǎn)品對于解決方案的功能范圍認知存在偏差。所以寫出來流程和大體規(guī)則與功能有助于產(chǎn)品經(jīng)理和業(yè)務(wù)方在認知上快速達成一致。有利于產(chǎn)品經(jīng)理理解業(yè)務(wù)方需求。就算是業(yè)務(wù)方自己確定要什么，隨著時間的推移可能也會產(chǎn)生偏差。以及如果是口述的需求需要被迫產(chǎn)品經(jīng)理記住。這樣的溝通是非常低效的。文檔存在本身就是有價值的。無論通過的，還是沒有通過的需求。對于通過的需求后續(xù)的產(chǎn)品經(jīng)理接手后知道在之前什么情況下迭代了什么需求。同時需求方也可以明白，哪些用戶的需求做到什么樣了。新來的人知道過去哪些需求被否定過了，為什么被否定了，是不是現(xiàn)在條件還不成立，那就不用再次浪費時間提出了?；蛘哒f條件有變化了，也可以在原來被駁回的需求上思考。很多人會反駁說業(yè)務(wù)方都很忙沒有時間寫需求文檔，我的看法是一個需求啟動后，要經(jīng)歷產(chǎn)品，設(shè)計，研發(fā)，測試，數(shù)據(jù)等等多種人員的環(huán)節(jié)，要花費這些人員的時間，相比較這些人員的成本來說，把需求描述清晰，量化了反而是一個提高效率的方法。有一種說法是提錯誤需求的人還不如不提需求，因為它還占用了資源。對于這種人發(fā)工資什么都不做，都好過這些人提需求。其次一個需求如果不值得寫，基本上它并不值得開發(fā)。因為每個節(jié)點的撰寫量是成倍增加的，從需求文檔，到產(chǎn)品需求文檔，再到代碼。最后也不建議上來就讓業(yè)務(wù)方量化提需求文檔，最好是有產(chǎn)品和數(shù)據(jù)分析師輔助，注意是輔助而不是帶寫。在產(chǎn)品和數(shù)據(jù)分析師充分了解需求后可以在固定的文檔格式上給予業(yè)務(wù)方一些撰寫建議，包括數(shù)據(jù)提取，哪些數(shù)據(jù)輔證需求的一些建議。最終目標都是為了可以讓業(yè)務(wù)方獨立完成數(shù)據(jù)提取的求證以及獨立撰寫需求文檔。3.3.4產(chǎn)品和研發(fā)剝離如果前三項基本滿足那么第四項是一個邏輯必然推導(dǎo)的結(jié)果，如果你的需求方可以量化的提需求，你可以量化的評估需求，評估過后就要有產(chǎn)品和開發(fā)能夠?qū)崿F(xiàn)需求，同時也能夠做好這些需求的數(shù)據(jù)監(jiān)控。所以說如果想做到數(shù)據(jù)驅(qū)動，最好對組織結(jié)構(gòu)做相應(yīng)的改造，核心的思路是讓運營和業(yè)務(wù)類需求和長期用戶價值的需求走兩個堆棧。逐步實現(xiàn)研發(fā)側(cè)逐步小閉環(huán)分工化。我們認為指標，功能，以及對應(yīng)的開發(fā)是有相關(guān)度的。當(dāng)然并不是絕對的。但是盡量我們要做到可以切分成獨立的閉環(huán)（盡管可能存在藕斷絲連的情況）但是大體趨勢上是獨立的。整體的切割邏輯在3.1章節(jié)核心邏輯是矩陣式分工那節(jié)已經(jīng)進行了講解，我這里做另外一個角度的陳述就是大體思路可以把偏向營銷的如落地頁工具，運營引擎，投放引擎，消息觸達中心等等這些屬于偏向與運營和銷售類的功能并攏到增長產(chǎn)品方研發(fā)團隊，另外一類會偏向于用戶價值長期建設(shè)，我們以電商舉例比如類目，品類，商鋪管理，偏向于核心價值的作為另外一個研發(fā)團隊負責(zé)的內(nèi)容。當(dāng)然這個過程最重要的就是和研發(fā)leader和產(chǎn)品leader規(guī)劃好產(chǎn)品的架構(gòu)圖，因為有了架構(gòu)圖才能知道哪些功能可以合并給到相似的開發(fā)和產(chǎn)品團隊。從數(shù)據(jù)驅(qū)動的角度上講優(yōu)先把業(yè)務(wù)方需求量化和需求上線后的結(jié)果量化是核心，因為業(yè)務(wù)需求方通常涉及到的需求范圍是有限的。當(dāng)然他們也會提出偏向長期用戶價值側(cè)的需求，在《運營之光：我的互聯(lián)網(wǎng)運營方法論與自白》一書里作者談道：產(chǎn)品團隊負責(zé)界定和提供長期用戶價值；而運營團隊負責(zé)創(chuàng)造短期用戶價值和協(xié)助產(chǎn)品完善長期價值。在團隊劃分上基本上業(yè)務(wù)方短期迭代的需求會高很多。3.3.5團隊配合工具抓手團隊之間如何合作，驅(qū)動需求實現(xiàn)。前四項如果滿足的話，業(yè)務(wù)方也愿意用數(shù)據(jù)量化的提需求，產(chǎn)品研發(fā)也愿意承接這些需求。那么剩下的問題就是需求如何自始至終的通過系統(tǒng)傳導(dǎo)到需求同步需求的狀態(tài)，團隊之間如何同步信息。就這涉及到團隊協(xié)同工作的工具，這些工具包括但不限于以下：需求管理工具：主要是負責(zé)記錄業(yè)務(wù)方提出的需求文檔。包含需求后續(xù)啟動后的狀態(tài)。文檔同步：產(chǎn)品經(jīng)理需求文檔，研發(fā)的文檔，數(shù)據(jù)文檔等等。IM工具，郵件工具，研發(fā)需求跟進工具，測試管理工具等等我就不在這里贅述了，總之管理工具要遵循的就是最小可用原則。其次是團隊盡可能的使用相似的系統(tǒng)來進行溝通，能夠合并就進行合并，這樣能夠最大程度上降低信息傳播的門檻。我之前工作過的一家中型公司會發(fā)現(xiàn)公司有些人習(xí)慣用QQ，有些人習(xí)慣用釘釘，有些人習(xí)慣用微信，導(dǎo)致團隊彼此找不到對方。需求UI維護在tower上，產(chǎn)品有些人維護在Excel，有些人維護在禪道上。需求是分散的，當(dāng)然就無法做到統(tǒng)一的評審。所以數(shù)據(jù)驅(qū)動可以盡量讓大家的信息一致，同時需求的量化和一個好的評審流程可以讓團隊工作效率提高，大家千萬不要覺得這種流程化方式是低效的，遠不如業(yè)務(wù)方直接拉著產(chǎn)品和研發(fā)開發(fā)高效。但是這個流程可以保證有價值的需求可以持續(xù)的優(yōu)先被開發(fā)。走得對，走得穩(wěn)，比走得快重要。而有了流程之后，通過整個團隊對于流程的熟悉可以做到走得又快又穩(wěn)。3.3.6組織能力數(shù)據(jù)驅(qū)動涉及部門多，要有極高的組織動員力最后我們會發(fā)現(xiàn)推動數(shù)據(jù)驅(qū)動團隊需要從需求方到產(chǎn)品，UI，研發(fā)，數(shù)據(jù)工程師，分析師的配合。所以邏輯順下來，按照矩陣式的管理方式，我們會發(fā)現(xiàn)這個人要可以影響或者管理：需求方到產(chǎn)品，UI，研發(fā)，數(shù)據(jù)工程師，分析師等很多部門，這也就是說職級越高越容易推動這個事情。因為它可以針對每個總監(jiān)下面的組能夠獨立出部分人員來針對增長或者業(yè)務(wù)方形成獨立的小閉環(huán)才能做這個事情。下面我們說一下如果你沒有這么大的行政權(quán)力，又想影響你的團隊去做數(shù)據(jù)驅(qū)動，或者我們說的直白點，你想做的專業(yè)一些，讓自己起碼數(shù)據(jù)量化一起來，提升一下職場身價，你只需要兩個人的支持，或者只需要一個人。那么你只需要一個工程師來接受你量化的需求，以及一個數(shù)據(jù)分析師來幫你提取數(shù)據(jù)就可以了。不過這個環(huán)境是否可行，極大程度上，取決于你和團隊的關(guān)系以及，團隊的管理是否有這樣的空間。極端的情況在沒有數(shù)據(jù)分析師的情況下，如果工程師很配合的話，他也是可以幫你獲取一些業(yè)務(wù)數(shù)據(jù)的，但是這樣的問題是，因為這樣拉新的需求由于沒有投放的追蹤工具，你還是沒有辦法量化。但是你可以先把產(chǎn)品上的用戶進行分析。同時考