作者 | 金戟
來源 | 阿裡技術公衆号
埋點作為記錄使用者行為的正常手段，伴随着前端技術的發展早已曆經春秋，不過直到“增長黑客”系列理論出現，才真正讓埋點分析變得内涵豐富且有章可循。
與産品領域的“增長”類似，“提效”一直是研發領域裡長盛不衰的主旋律。在軟體研發過程中，伴随着項目開展，同樣會以事件的形式記錄下許多與代碼庫、流水線、任務相關的行為資料。這些資料的來源雖與頁面埋點不盡相同，其實質用途卻有許多可類比之處。然而當産品經理們紛紛開始通過埋點的實時資料争分奪秒調整市場營銷政策時，研發團隊的TL和PM們依然隻能使用統計方法+彙總名額為主導的事後分析手段，在每個版本和疊代完成後對團隊效能進行回顧和評估，并樂此不疲地談論如何将疊代周期從一個月縮短到兩周，進而獲得“更快的回報”。
本文将讨論一種尚未被實踐過的方法論，即能否将“增長黑客”理論作用到研發過程的改進上，進而實作更可靠的定向效能優化？
一 研發團隊的北極星名額
在進行增長目标制定之前，團隊往往需要先确定一項能夠反映團隊成功情況且易觀測的“北極星名額”，譬如銷售額、簽單率、活躍使用者數等等。對于研發團隊來說，關鍵的名額主要是需求完成時長、功能缺陷率、使用者滿意度，諸如此類。以“需求完成時長”為例，這是一個相對客觀且直接反映開發團隊響應使用者需求速度的名額，即一個需求從提出到最終傳遞可用，所需要經曆的平均時間長度。
接下來我們定義一個相對理想的需求傳遞過程，并參考産品流量分析的“轉化漏鬥”結構表示出來：
相應的，将項目中的所有需求都添加進來，可以繪制出類似這樣的“需求傳遞路徑圖”（示例，實際階段劃分應該更豐富）：
雖然略顯粗糙，但通過這種展現方式我們确實能夠追回不少在往常隻統計結果資料的圖表裡丢失了的資訊。譬如同樣是兩個花10天完成的需求，一個開發用了7天，另一個開發隻用了1天，其餘時間花在了等待測試上，它們的差異在傳遞路徑圖上就能被清晰的區分出來。
這樣做的另幾項好處包括：
- 即使一個需要還未最終傳遞，而是被阻滞在了某個環節、或者出現了返工，也能夠在第一時間以異常流量的形式顯著的展現在路徑圖上，進而及時引起TL和PM的關注。
- 不但能直覺的看出總體的各階段傳遞進展情況，也能從單個需求角度檢視流經的每個節點，并找到其他情況類似的需求，便于分析它們的共性特征。
- 用于事後分析時，可做傳遞結果的反向追溯，譬如查閱未按時傳遞的需求流經此前各節點的比例。
基于以上參照，我們可以得出以研發需求價值轉化的“效能黑客”模型（對應增長黑客的AARRR模型）：
有了北極星名額和可視化的路徑，接下來的關鍵在于用資料指導效能改進。
二 時間軸上的AB測試
并非所有客戶都值得投入大量力氣來維系，增長團隊總是優先專注于高價值客戶的留存。在進行效能改進時也應當首先識别差異，然後因材施教。
正如增長團隊常用的“RFM模型”客戶分類方法，針對研發需求，同樣可以通過與效能相關的正交次元來分類出可采用不同應對措施的需求集合，譬如“RIW模型”：
- A（Activity）需求的近期活躍度（相關事件頻率）
- I（Importance）需求的重要程度（優先級、距離計劃完成的剩餘時間）
- W（Workload）需求關聯的已投入開發工作量（譬如代碼修改行數）
三個次元能将所有樣本分為8組，這個粒度非常适合圈定重點，同時又避免資訊太多過度發散。而選擇以上三組屬性，不僅是因為它們具備較高區分度，還因為這幾項名額的觀測值都較容易獲得且能夠高頻更新，進而在研發過程中及時發現異常樣本并進行糾偏。
軟體研發是一項腦力勞動為主的活動，影響研發效能的因素包括且不限于開發者的個人能力、團隊氛圍、公司文化、項目進度壓力、成員間的默契度、外部溝通成本、相關流程工具等等，其中絕大部分都是無法簡單用數值化衡量的主觀成分。雖然以往提及研發提效時，我們會出于技術可控的角度，着重談論平台能力、研發流程、工具支援等“療程短，見效快”的方法，但真實世界的研發提效手段要豐富得多。既可以采用技術工程手段，如提升建構速度、簡化上線流程、改進釋出工具；也可以采用組織文化手段，譬如優化獎懲政策、樹立先進标杆、調整人力結構、提升員工福利、加強技能教育訓練等等。那麼究竟哪種提效方法才最适合研發團隊呢？
對此，增長理論早就給出了答案，不論黑白貓，隻要抓住老鼠就是好貓：做個AB測試。
與面向産品使用者的AB測試不同，進行項目研發時，不能直接以單個需求為粒度進行AB測試（不便于項目管理），相比之下，團隊或者疊代都是比較合适的AB粒度。具體的AB方法大家一點也會不陌生，譬如讓兩個項目團隊采取不同的提效政策，對比效果，類似于“試點”和“樣闆間”。或者讓同一個團隊在不同的疊代裡分别嘗試一些新的提效方法，然後根據效果來決定保留或放棄，這就是在“時間軸上做的AB測試”。
喏，一個新概念就這麼被創造出來了，不過現在還保持清醒着的讀者很快就會發現，這也不是什麼新鮮的主意，疊代回顧和改進會議不就是做這事情的嘛！其實不盡然。以往疊代回顧時的可分析資料主要是疊代燃盡圖和需求/缺陷累積圖，反映的是整體的趨勢情況，“整體均值”往往會掩蓋局部問題，這是達不到“AB測試”嚴謹性要求的。而前述的“需求轉化路徑”和“RIW分布”情況恰好能夠彌補上疊代過程細節，為效能改進的方法提供指導依據。
三 舶來主義的局限
在許多方面，通過埋點分析增長政策與通過研發事件分析提效政策之間确有共通之處，譬如埋點的四大要素：
此四項要素研發事件皆有，因而但凡埋點可用之方案，研發事件皆可套。這是舶來主義。
然而增長關注的是固定的一群使用者，追求拉新留存；提效面對的是日新月異的需求，追求按時傳遞。由于兩者的分析對象和目标不同，本質上依然存在差别：
- 使用者離開了又會回來，可以持續追蹤；需求完成就結束了，下次進來的是新需求。這也是需求不适合做為AB測試粒度的原因。
- 拉新和留存可以越高越好，不設上限；傳遞效率不能單方面過度苛求，否則以犧牲品質和疲勞戰術換取“提效”終将得不償失。
- 頁面路徑相對固定，譬如必須先經過下單頁才能進入付款頁；需求路徑則不一定，譬如一個“開發超期”的任務最終依然可能“按時傳遞”。
此外，埋點記錄的頁面點選總是實時準确的，而需求的狀态依賴人工更新，實際操作未必及時，采集的事件資料是以經常存在時間偏差，這是研發資料分析的一項老大難問題。更充分的自動化是一種解決思路，譬如在阿裡雲·雲效的新版協作産品中，支援通過規則讓研發行為與任務更新關聯（比如代碼送出觸發任務開始、流水線釋出觸發任務完成等），此舉将十分有助于增加效能分析的準确度。
最終，即便是模式化的借鑒，是否有效還需要實踐來證明。
四 暢想與小結
增長和提效，兩個看似風馬牛不相及的主題，由于一個腦洞，被聯系到了一起。
用産品思路營運技術團隊，用埋點資料還原研發過程，用轉化路徑洞察關鍵瓶頸。效能黑客，讓項目進度更客觀，讓研發過程更透明。
人工智能技術圖譜
阿裡雲天池傾力打造AI技術學習圖譜，含AI算法開發學習路徑和AI應用開發學習路徑，共400小時，12個知識點，50個實踐案例，并配套有免費算力、珍稀資料集以及答疑等資源和服務，助力學習者在實踐中掌握AI知識。
點選這裡，開始學習吧~