作者：李江
9月27日，經過之前很長一段時間的思考，我決定在團隊內部嘗試一種新的打法，利用增長黑客的方式優化一項業務的核心指標。
我把業務相關的同學召集起來，組建了一隻快速迭代小組：小組成員包括了我這個會議主持人加打雜，一位產品經理負責提供產品視角以及確保優化不偏離產品方向，團隊中的兩位算法工程師扮演了數據分析師的角色，以及另外3位工程師負責系統/策略/算法部分的開發。小組的目標就是爲了快速提升業務的核心指標數據。我並沒有和大家透露是在嘗試增長黑客的方法，我只是說想實驗一種新的方法，讓每個人承擔更多的責任。
整個小組的基本工作方式大致如下：
- 每週爲一個開發週期，進行一批灰度實驗用於優化核心指標；
- 每週一開數據分析討論會，數據分析師提供上一輪各項實驗的數據分析報告，小組基於此討論相關策略是否上線或者放棄；
- 週二會再進行一次策略討論會，要求每位成員至少提供三個新方案，大家共同討論決定哪個方案進入到新一輪的灰度實驗；
- 週三到週五是各項灰度實驗的開發時間。我們的大部分實驗週四能夠完成開發灰度上線，而無法在週五之前完成的實驗則延遲到下一輪；
- 週五/六/日是線上觀察數據的時間；
- 重複上述步驟；
從9月27日啓動，到11月5日完成最後一次的灰度數據分析報告，這一個月多的時間整個團隊一共經歷了4輪迭代實驗測試；我們一共討論了68個新的策略和算法的改進，完成了其中36項的灰度實驗和結果分析；核心指標在此期間上漲了20%+。整個過程中，我很滿意團隊的工作節奏，合作方式以及最終的產出結果，同時也激發了我自己更多的思考，因此有了這篇文章。
增長黑客的三個核心要素
網上搜“增長黑客”，找到的文章大多數是在聊用戶增長和營銷的策略和方案，《增長黑客》這本書也是花費了大部分篇幅介紹用戶漏斗模型和成功的策略與套路。但作爲一個工程師，增長黑客在我看來其實是一套以數據爲驅動的方法論。《增長黑客》洋洋灑灑大幾百頁，最有價值的東西我覺着在前言部分已經介紹完了。這套方法論大致分爲三個關鍵要素：
多角色團隊的集體決策
看幾乎所有的增長黑客案例，它的核心團隊都是由扮演各式角色的成員構成，大部分都包括產品經理，工程師，數據分析師，UI/UE工程師或者市場營銷人員。爲什麼需要這麼多的角色共同參與到核心團隊中？是因爲我們希望在後續的大批量灰度實驗中能夠去嘗試各種角度的可能性。從一個算法工程師的角度，這有點像是將每個人都當成是一個還不錯的“弱分類器”，這些“弱分類器”相互之間越獨立越好，這樣它們有機會共同構成一個效果顯著的“強分類器”。爲了確保討論和實驗的多樣性，另外一個很重要的點是在團隊內部實行“平權”，不應該出現某些人決策權過大的情況。所以我們的討論會只有主持人而沒有負責人，所有的決策共同討論執行。
確保每個人都有充分的討論權，話語權和決策權這一點對於增長黑客團隊非常重要。這次實踐過程中，我印象特別深刻的一次是，我們有位工程師提了一個建議：把推薦輸出得分第一的物料放到第二個位置試試效果。這個建議當時在我看來毫無邏輯可言，因爲如果把算法得分高的物料放到後面，那不就是在否定我們這些算法工程師的價值麼。但這個策略最後我們還是上了灰度實驗，因爲策略並沒有和我們觀察到的數據表現相沖突，更重要的是這個策略的開發工程師是他本人，反正是他自己的工作量.... 最後的結果很意外，這個策略確實有正向的效果，數據有大概1%～1.5%的提升。對於這個結果我事後的理解是，推薦的場景和搜索的場景還是有較大的區別，搜索是用戶有目的的行爲，對於搜索結果用戶的注意力是從上向下的，而推薦是無目的的行爲，用戶的注意力焦點可能更集中於屏幕的中間位置。總而言之，給一些看上去不那麼靠譜的想法和策略留出灰度實驗的空間在黑客增長中是有必要的，也許會帶來非常意外的驚喜，只要確保不要重複實驗同一個錯誤就好。
增長黑客爲什麼能夠允許集體決策這件事情？一方面是因爲我們能夠做大量的灰度實驗，所以不需要在討論的過程中爭個你死我活，可以求同存異，可以允許犯錯。另外一方面是，雖然是集體決策，但最終決定的判斷標準是統一的，就是核心數據指標的增長和提升。我們接下來就要分別聊聊這兩點。
數據驅動
數據驅動談論了很多年，但很多時候都被錯誤的當成了KPI驅動。KPI是我們要達成的目標，但它沒有辦法告訴你怎麼達成，KPI的漲跌只能告訴你結果，但沒法回答原因，也沒法對下一步的方向提供建議。在我看來，數據驅動是一種能力，是增長黑客團隊必須具備的一種能力，我把這種能力拆解成三個方面：
- 設定合理數據觀測指標的能力
正如前述，我們不能僅僅觀測KPI數據，一方面是它反映的角度相對單一，並不能很好的描述整個業務生態內部的變化，無法提供足夠的決策支持；另一方面是，KPI數據有可能是不敏感的，需要長時間的灰度才能夠觀察到數據的變化，此類KPI並不適合作爲灰度實驗的觀測指標。團隊需要提煉出更多的指標作爲除了KPI之外的輔助觀測指標，這些指標能夠反映業務某個維度的變化，並且對於灰度實驗足夠敏感。團隊還應該對這些指標做更多不同維度的細分，觀察各個細分領域的變化。
- 前置的數據挖掘發現問題的能力
爲了支撐能夠快速的做大量的灰度實驗，我們的實驗都不會允許特別複雜，工程上相對易於實驗。那麼如果有一個灰度實驗想法需要投入較大人力的開發怎麼辦？最好的辦法是在實驗之前先從數據上驗證實驗的有效性。能不能事先通過數據分析側面驗證某個想法的可行性，這是一種非常強大的能力，能夠節約大量的開發成本。此外，在沒有好的實驗思路的情況下，數據分析師能否主動從數據挖掘中發現一些有價值的想法和線索給整個團隊提供參考，也是增長黑客團隊的必備技能。
- 後置的實驗結果分析能力
線上灰度不僅僅要驗證這個實驗本身是否有價值，是否能夠上線，還需要爲後續的想法和實驗提供數據支持和依據，最好的循環應該是 實驗 -> 分析 -> 更好的實驗。基於此，對於實驗結果的分析就不能只是YES or No的答案，而是應該儘可能的分析結果背後的原因。另外，對於觀測指標應該在不同維度上做拆分，這樣能夠幫助我們從一個失敗的實驗中找到它可能對於某個細分場景有正向的影響。這樣的全面分析要求團隊的數據分析師同時具備紮實的分析能力和業務能力。
我們團隊的數據分析工程師是由算法工程師兼任的，他們每天玩弄數據，熟悉業務，提取各式有效特徵，但儘管如此，我仍然認爲我們對於數據的分析還不夠深入還不夠細化。此外，即便是我們這個算法團隊，做數據分析的工具還是不夠健全，很多的分析需要重頭寫腳本跑數據，需要消耗大量的人力。數據驅動真的不僅是意識，它是一種實實在在的能力，一種需要各種配套設施和工具，需要團隊反覆打磨反覆提升的能力。
大量快速的灰度實驗
能夠支持大量的快速的灰度實驗是團隊能夠實施增長黑客打法的關鍵。滿足不了這個條件，意味着較長時間內只能嘗試非常有限的灰度實驗，從而意味着團隊討論出來的大部分實驗方案都必須放棄，只能從中挑選有限的進行嘗試，這時候團隊就會碰到決策權歸屬的問題，而一旦碰到這個問題，這個團隊就不再是一個平權團隊，而會慢慢重新演變成一個決策集中的團隊。
因此，能夠支持大量的快速的灰度實驗是增長黑客團隊的核心能力。這裏包含有兩個關鍵詞：“大量” 和 “快速”，爲了解釋這兩個詞，我定義了兩個指標：
用“灰度實驗時間”來定義“快速”。灰度實驗時間又大致可以等於 前期討論方案時間 + 開發上線時間 + 灰度觀測數據時間 + 後期數據分析時間：
- “前期討論時間” 暫且不聊。
- “開發上線時間” 取決於團隊的工程能力，敏捷開發優化的是這部分的效能；同時還取決於工程架構是否支持快速的上線部署，例如，客戶端開發能夠多快的上線新的灰度方案；還取決於我們之前提到的，是否有可能細化大方案，將複雜功能拆解成小型實驗的能力；
- “觀測數據時間” 這個指標取決於兩部分：一部分是數據分析系統支持實驗結果數據能夠多快反饋出來。A公司需要一週時間跑數據，B團隊需要一天完整的時間收集數據進行分析，C家的灰度系統支持上線後十幾分鍾後就能夠獲得反饋報告，那麼C的可迭代速度就是A的幾十甚至幾百倍；另外一部分取決於觀測指標的敏感性。並不是所有的指標都很敏感，比如用戶留存就不太可能通過幾十分鐘的數據變化看出來，而用戶的點擊率能夠在非常短的時間內反饋；
- “後期數據分析時間” 取決於數據分析系統/平臺的能力，強大的平臺能夠讓非數據專家快速觀察分析各類指標和變化，普通的系統需要專人手動的寫腳本執行各種統計。
- 很多情況下，我們會更加聚焦“開發上線時間”，而忽略了“觀測數據時間”和“數據分析時間”，導致無法快速的做到策略的持續迭代。
用“同時可支持的灰度實驗數量”衡量“大量”，它的影響因素包括：
- 足夠的流量。每一個灰度方案都需要有足夠的流量做支撐，這樣才能夠保證最終灰度結果指標的穩定性。所以有一定流量是增長黑客團隊的前提。
- 強大的灰度系統，能夠支持的同時實驗方案的數量。
- 團隊的開發能力，能夠同時開發方案的數量。這裏除了團隊的執行力以外，還需要強調一下團隊的規模。傳統的軟件工程領域有“人月神話”的說法，意思是堆人並不能夠縮短軟件開發的週期。但在這裏，堆人是有幫助的。雖然無法縮短單個方案的開發週期，但可以幫助支持更多方案的並行開發，所謂“韓信點兵，多多益善”。
我們可以用 同時可支持的灰度實驗數量 / 灰度實驗時間 大致表示一個增長黑客團隊的效能，這個效能代表的就是業務的迭代改進速度。迭代改進速度是一個增長黑客團隊綜合實力的體現，它需要融合團隊的數據能力和開發能力，需要有強大的灰度系統和數據分析系統的支撐（看公司最近一個季度的小創新有好幾個是關於AB測試平臺，很贊）。強大的增長黑客團隊的迭代速度能夠是一個普通業務團隊的幾十倍，這是質的提升。
以上三個要素是構建增長黑客團隊的基石，它們相互聯繫，缺一不可。至於其它的什麼AARRR模型，增長祕籍等等在我看來都是這套打法在其他人的實踐中發現的一些成功率比較高的定勢或者套路，但脫離方法論只關注別人成功的具體策略，妄圖完全複製就有些刻舟求劍的意思了。
接下來聊一聊我個人積累的一點點想法和思考。
個人的想法和思考
- 增長黑客到底是指什麼？正如前文反覆陳述的，我認爲它是一個方法論，是一種新的打法。新的打法首先需要新的認知，團隊內部需要認可數據驅動的工作方式，團隊中的每個人都要有對結果負責的主動性，它提倡平權團隊，所以團隊中的強勢人物需要能夠適當約束自己的權利，等等。但光有新的認知不夠，更重要的是要求團隊具備新的能力。它要求你的數據分析師能夠同時熟悉業務，能夠從數據中發現問題而不僅僅是按照要求生成數據報表；它要求技術團隊在考慮技術架構的時候要預先把灰度測試系統和數據分析系統融合其中，要能夠支持多種灰度方案的快速上線（哪怕是客戶端）。這種種能力是在長期實踐中積累磨合出來的，不是隨便看了一本書就可以照搬的。所以我並不看好大部分嘗試增長黑客的團隊，想的太簡單了。
- 增長黑客適合於什麼樣的場景？我的理解，適用於解決目標明確但方法不確定的問題。所謂目標明確，是指期望達到的結果是可量化的，能夠轉換成一個或者少數幾個具體的數據指標。所以構建產品的初期顯然就不適合採用增長黑客的打法。另一方面，所謂方法不確定，是指我們所面臨的是一個開放式的問題，沒有明確的解決方案。一般情況下我們開發產品需求，解決的是一個相對封閉的問題，因爲需求和解決需求的方案是已知的，這時候更強調的是團隊的執行力。而解決開放式問題，更爲重要的是團隊的創造力。
- 爲什麼增長黑客現在越來越火？我覺着主要是兩個原因：一是早幾年前中國互聯網還停留在“對標”階段，照着國外的產品做，大家比的就是誰“對標”的更快。而最近幾年開始精細化耕作，發現光“對標”已經不太夠用了，創新的重要性越來越突出；二是人口紅利的結束。人口紅利的時代PK的對象是競品，比的是誰的功能更豐富，誰的速度更快能更早的搶佔用戶。人口紅利的結束，意味着所有其它佔用用戶時間的產品都成爲了競品，遊戲要開始和小視頻搶奪用戶時間，競爭中的不確定性變得更大，因此會更加強調產品的創新性和應變能力。
- 傳統打法的團隊組織架構，以產品經理或者業務負責人爲中心節點，他們負責和其它成員的溝通以及決策的制定，而其它成員各司其職主要負責方案的執行。雖然有時候團隊也會在一起開個溝通會議，但基本就是一個星狀的組織結構。這種組織結構的優勢在於決策的效率和執行力。增長黑客團隊的組織架構更類似於網狀的結構，沒有特別明確的中心節點，強調通過相互之間的碰撞和協作產生創造力，同時通過數據驅動的方式讓團隊能夠按照同一方向前進。（這小節的理解有點像《賦能》這本書裏面的內容...）
- 增長黑客團隊中誰最重要？我覺着多樣化的角色每個都挺重要，但如果非要找一個的話，我認爲是數據分析專家。增長黑客團隊對於數據分析專家的要求很高，需要他能夠主動的從數據中發現業務的問題和給業務的發展方向提供建議和思路。這需要數據分析專家同時具備業務理解能力和很強的數據挖掘能力，而不是像現在很多團隊中的數據分析師，只是業務負責人進行數據分析的一個輔助幫手和工具。我也曾經想過，有沒有可能產品經理或者業務負責人來扮演數據分析專家的角色。後來琢磨覺着不太可行。一方面是因爲好的數據分析師需要有很強的數據思維和分析能力，這個能力是需要經過長期的實踐打磨的。即便我們團隊的算法工程師來做這事我仍然感覺還欠缺一些功底，更何況是產品經理；另一方面是數據分析師如果要有好的產出，需要長時間沉浸在數據清洗和分析挖掘的過程中，需要花費大量的時間幹着沙子裏面淘金的髒活累活，產品經理很難有精力能夠投入這麼多的時間。我覺着最理想的狀態是團隊裏面有一個具備一定數據思維的業務專家，以及一個熟悉業務的數據分析專家，雙引擎驅動效果應該最好。
- 我看過一些增長黑客的資料，似乎很多人強調增長黑客能夠帶來社會化自我營銷或者爆炸式的增長，連《增長黑客》這本書爲了宣揚它的觀點舉的例子都是那種特別戲劇性的創意，我個人不認可這種觀點。黑客增長的目的如果只是爲了達成某個“引爆點（The Tipping Point）”，那這種打法的適用範圍就太小了，因爲並不是所有場景和產品都存在一個“引爆點”的。我覺着增長黑客最大的能力是通過大量的灰度實驗，持續性的發現新的增長點，從而實現長時間的複利增長。和投資領域一樣，長期的可持續的複利增長才是我們應該追求的目標。舉個最簡單的例子，假設我們的灰度實驗能夠幫助我們在每週都發現一個效果僅僅提升2%的策略或者方案，那麼6個月之後會發生什麼呢？
- 我是一個算法工程師，會很不自覺的將增長黑客的工作方式和做算法的方式做對比。算法工程師爲了解決所面臨的問題，首先需要對問題進行分析和建模；而一個產品也是爲了解決用戶的某個需求而提出的模型，這個模型裏面包含了最基本的產品邏輯和規則。算法模型中大量的參數需要調節；產品也有很多的細節需要打磨。爲了調節模型中的參數，我們需要準備兩個東西：定義清楚模型訓練的損失函數（Loss），以及準備充足的訓練數據；爲了優化產品的體驗，增長黑客同樣需要兩個東西：定義清楚增長的具體數據指標，以及一定的流量進行灰度實驗。算法模型的訓練通過計算訓練樣本的損失，調節參數擬合損失最小的梯度方向；增長黑客通過利用流量做大量灰度實驗，挑選出能夠獲得增長的方案。兩者都需要持續的快速迭代。所以在我這個算法工程師眼中，增長黑客其實是把我們做算法模型的流程移植到了產品優化和市場推廣的工作中。
- 增長黑客應該很難解決產品建模這個問題，這件事情還是交給專業的產品經理和創業者去做。增長黑客能夠做到的是快速的優化產品模型，如果說產品模型本身決定了這個產品的上界，那麼增長黑客能做的就是儘快儘可能的擬合到這個上限。所以一種可能的打法是，迅速的複製市場上剛剛起來的經過驗證的產品模型，然後用增長黑客的方式藉助於流量實驗進行快速的優化迭代，趕超原有產品。所謂“後發先至”。我覺着這可能會是大廠山寨其它產品的新思路，不僅僅利用流量更迅速接觸到用戶佔領市場，而且可以利用流量比小廠做更快速的演進。
- 做算法的人都知道，訓練模型的時候通過小步梯度下降不斷迭代，最後收斂到的往往是局部最優而不是全局最優。算法工程師爲了繞過這一點一般都會把模型改造成凸優化的問題，這樣局部最優同時也是全局最優。我個人猜測，採用黑客增長方式優化產品可能同樣會碰到這個問題，而產品模型可能要比爲我們的算法模型更爲複雜，很難保證會是一個凸優化。怎麼解決局部最優的問題？我覺着可能有兩個手段：一個方式是讓產品儘可能的簡單，如果非要把產品做的複雜加特別多的功能，那就可以考慮把產品分拆成產品矩陣的方式。另外一點就需要增長團隊的負責人在已經擬合到局部最優的時候有勇氣跳出現有思路另闢蹊徑。（本小節純屬個人臆斷）
結尾
增長黑客的打法要用好了其實是件挺難的事情，我們自己的實踐也就是做了點皮毛工作。難點在於需要重新調整組織工作的方式，需要有一系列的系統來支撐新的工作流程，更難的在於它對於團隊成員的要求很高。團隊中的每個人都需要有更加積極主動的態度，需要對業務有更加深入的理解，能夠在發散的討論和強執行力之間順利的切換。很慶幸我們的團隊成員如此優秀，謹以此文獻給他們。