金戟：如何用增長思維做提效｜阿里技術(shù)

埋點作為記錄用戶行為的常規(guī)手段，伴隨著前端技術(shù)的發(fā)展早已歷經(jīng)春秋，不過直到“增長黑客”系列理論出現(xiàn)，才真正讓埋點分析變得內(nèi)涵豐富且有章可循。

與產(chǎn)品領(lǐng)域的“增長”類似，“提效”一直是研發(fā)領(lǐng)域里長盛不衰的主旋律。在軟件研發(fā)過程中，伴隨著項目開展，同樣會以事件的形式記錄下許多與代碼庫、流水線、任務(wù)相關(guān)的行為數(shù)據(jù)。這些數(shù)據(jù)的來源雖與頁面埋點不盡相同，其實質(zhì)用途卻有許多可類比之處。然而當產(chǎn)品經(jīng)理們紛紛開始通過埋點的實時數(shù)據(jù)爭分奪秒調(diào)整市場營銷策略時，研發(fā)團隊的TL和PM們依然只能使用統(tǒng)計方法+匯總指標為主導的事后分析手段，在每個版本和迭代完成后對團隊效能進行回顧和評估，并樂此不疲地談?wù)撊绾螌⒌芷趶囊粋€月縮短到兩周，從而獲得“更快的反饋”。

本文將討論一種尚未被實踐過的方法論，即能否將“增長黑客”理論作用到研發(fā)過程的改進上，從而實現(xiàn)更可靠的定向效能優(yōu)化？

一  研發(fā)團隊的北極星指標

在進行增長目標制定之前，團隊往往需要先確定一項能夠反映團隊成功情況且易觀測的“北極星指標”，譬如銷售額、簽單率、活躍用戶數(shù)等等。對于研發(fā)團隊來說，關(guān)鍵的指標主要是需求完成時長、功能缺陷率、用戶滿意度，諸如此類。以“需求完成時長”為例，這是一個相對客觀且直接反映開發(fā)團隊響應(yīng)用戶需求速度的指標，即一個需求從提出到最終交付可用，所需要經(jīng)歷的平均時間長度。

接下來我們定義一個相對理想的需求交付過程，并參考產(chǎn)品流量分析的“轉(zhuǎn)化漏斗”結(jié)構(gòu)表示出來：

相應(yīng)的，將項目中的所有需求都添加進來，可以繪制出類似這樣的“需求交付路徑圖”（示例，實際階段劃分應(yīng)該更豐富）：

雖然略顯粗糙，但通過這種展現(xiàn)方式我們確實能夠追回不少在往常只統(tǒng)計結(jié)果數(shù)據(jù)的圖表里丟失了的信息。譬如同樣是兩個花10天完成的需求，一個開發(fā)用了7天，另一個開發(fā)只用了1天，其余時間花在了等待測試上，它們的差異在交付路徑圖上就能被清晰的區(qū)分出來。
這樣做的另幾項好處包括：

• 即使一個需要還未最終交付，而是被阻滯在了某個環(huán)節(jié)、或者出現(xiàn)了返工，也能夠在第一時間以異常流量的形式顯著的展現(xiàn)在路徑圖上，從而及時引起TL和PM的關(guān)注。

• 不但能直觀的看出總體的各階段交付進展情況，也能從單個需求角度查看流經(jīng)的每個節(jié)點，并找到其他情況類似的需求，便于分析它們的共性特征。

• 用于事后分析時，可做交付結(jié)果的反向追溯，譬如查閱未按時交付的需求流經(jīng)此前各節(jié)點的比例。

基于以上參照，我們可以得出以研發(fā)需求價值轉(zhuǎn)化的“效能黑客”模型（對應(yīng)增長黑客的AARRR模型）：

有了北極星指標和可視化的路徑，接下來的關(guān)鍵在于用數(shù)據(jù)指導效能改進。

二  時間軸上的AB測試

并非所有客戶都值得投入大量力氣來維系，增長團隊總是優(yōu)先專注于高價值客戶的留存。在進行效能改進時也應(yīng)當首先識別差異，然后因材施教。

正如增長團隊常用的“RFM模型”客戶分類方法，針對研發(fā)需求，同樣可以通過與效能相關(guān)的正交維度來分類出可采用不同應(yīng)對措施的需求集合，譬如“RIW模型”：

• A（Activity）需求的近期活躍度（相關(guān)事件頻率）
• I（Importance）需求的重要程度（優(yōu)先級、距離計劃完成的剩余時間）
• W（Workload）需求關(guān)聯(lián)的已投入開發(fā)工作量（譬如代碼修改行數(shù)）

三個維度能將所有樣本分為8組，這個粒度非常適合圈定重點，同時又避免信息太多過度發(fā)散。而選擇以上三組屬性，不僅是因為它們具備較高區(qū)分度，還因為這幾項指標的觀測值都較容易獲得且能夠高頻更新，從而在研發(fā)過程中及時發(fā)現(xiàn)異常樣本并進行糾偏。

軟件研發(fā)是一項腦力勞動為主的活動，影響研發(fā)效能的因素包括且不限于開發(fā)者的個人能力、團隊氛圍、公司文化、項目進度壓力、成員間的默契度、外部溝通成本、相關(guān)流程工具等等，其中絕大部分都是無法簡單用數(shù)值化衡量的主觀成分。雖然以往提及研發(fā)提效時，我們會出于技術(shù)可控的角度，著重談?wù)撈脚_能力、研發(fā)流程、工具支持等“療程短，見效快”的方法，但真實世界的研發(fā)提效手段要豐富得多。既可以采用技術(shù)工程手段，如提升構(gòu)建速度、簡化上線流程、改進發(fā)布工具；也可以采用組織文化手段，譬如優(yōu)化獎懲策略、樹立先進標桿、調(diào)整人力結(jié)構(gòu)、提升員工福利、加強技能培訓等等。那么究竟哪種提效方法才最適合研發(fā)團隊呢？

對此，增長理論早就給出了答案，不論黑白貓，只要抓住老鼠就是好貓：做個AB測試。

與面向產(chǎn)品用戶的AB測試不同，進行項目研發(fā)時，不能直接以單個需求為粒度進行AB測試（不便于項目管理），相比之下，團隊或者迭代都是比較合適的AB粒度。具體的AB方法大家一點也會不陌生，譬如讓兩個項目團隊采取不同的提效策略，對比效果，類似于“試點”和“樣板間”?；蛘咦屚粋€團隊在不同的迭代里分別嘗試一些新的提效方法，然后根據(jù)效果來決定保留或放棄，這就是在“時間軸上做的AB測試”。

喏，一個新概念就這么被創(chuàng)造出來了，不過現(xiàn)在還保持清醒著的讀者很快就會發(fā)現(xiàn)，這也不是什么新鮮的主意，迭代回顧和改進會議不就是做這事情的嘛！其實不盡然。以往迭代回顧時的可分析數(shù)據(jù)主要是迭代燃盡圖和需求/缺陷累積圖，反映的是整體的趨勢情況，“整體均值”往往會掩蓋局部問題，這是達不到“AB測試”嚴謹性要求的。而前述的“需求轉(zhuǎn)化路徑”和“RIW分布”情況恰好能夠彌補上迭代過程細節(jié)，為效能改進的方法提供指導依據(jù)。

三  舶來主義的局限

在許多方面，通過埋點分析增長策略與通過研發(fā)事件分析提效策略之間確有共通之處，譬如埋點的四大要素：

此四項要素研發(fā)事件皆有，因而但凡埋點可用之方案，研發(fā)事件皆可套。這是舶來主義。

然而增長關(guān)注的是固定的一群用戶，追求拉新留存；提效面對的是日新月異的需求，追求按時交付。由于兩者的分析對象和目標不同，本質(zhì)上依然存在差別：

• 用戶離開了又會回來，可以持續(xù)追蹤；需求完成就結(jié)束了，下次進來的是新需求。這也是需求不適合做為AB測試粒度的原因。

• 拉新和留存可以越高越好，不設(shè)上限；交付效率不能單方面過度苛求，否則以犧牲質(zhì)量和疲勞戰(zhàn)術(shù)換取“提效”終將得不償失。

• 頁面路徑相對固定，譬如必須先經(jīng)過下單頁才能進入付款頁；需求路徑則不一定，譬如一個“開發(fā)超期”的任務(wù)最終依然可能“按時交付”。

此外，埋點記錄的頁面點擊總是實時準確的，而需求的狀態(tài)依賴人工更新，實際操作未必及時，采集的事件數(shù)據(jù)因此經(jīng)常存在時間偏差，這是研發(fā)數(shù)據(jù)分析的一項老大難問題。更充分的自動化是一種解決思路，譬如在阿里云·云效的新版協(xié)作產(chǎn)品中，支持通過規(guī)則讓研發(fā)行為與任務(wù)更新關(guān)聯(lián)（比如代碼提交觸發(fā)任務(wù)開始、流水線發(fā)布觸發(fā)任務(wù)完成等），此舉將十分有助于增加效能分析的準確度。

最終，即便是模式化的借鑒，是否有效還需要實踐來證明。

四  暢想與小結(jié)

增長和提效，兩個看似風馬牛不相及的主題，由于一個腦洞，被聯(lián)系到了一起。

用產(chǎn)品思路運營技術(shù)團隊，用埋點數(shù)據(jù)還原研發(fā)過程，用轉(zhuǎn)化路徑洞察關(guān)鍵瓶頸。效能黑客，讓項目進度更客觀，讓研發(fā)過程更透明。

—— 如果覺得文章還OK，請轉(zhuǎn)發(fā) ——

特別提示：關(guān)注本專欄，別錯過行業(yè)干貨！

PS：本司承接 小紅書 / 淘寶逛逛 / 抖音 / 百度系 / 知乎 / 微博/大眾點評 等 全網(wǎng)各平臺推廣；

咨詢微信：139 1053 2512 (同電話)

首席增長官CGO薦讀：

• 《首席增長官 – 增長黑客 Growth Hacker》
• 《小紅書 – 增長黑客 Growth Hacker》
• 《視頻號 – 增長黑客 Growth Hacker》

更多精彩，關(guān)注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實現(xiàn)低成本甚至零成本帶來的有效增長…