作者 | 金戟
來源 | 阿裏技術公眾號
埋點作為記錄使用者行為的常規手段，伴隨著前端技術的發展早已歷經春秋，不過直到「增長黑客」系列理論出現，才真正讓埋點分析變得內涵豐富且有章可循。
與產品領域的「增長」類似，「提效」一直是研發領域裏長盛不衰的主旋律。在軟體研發過程中，伴隨著計畫開展，同樣會以事件的形式記錄下許多與程式碼庫、流水線、任務相關的行為數據。這些數據的來源雖與頁面埋點不盡相同，其實質用途卻有許多可類比之處。然而當產品經理們紛紛開始透過埋點的即時數據爭分奪秒調整市場行銷策略時，研發團隊的TL和PM們依然只能使用統計方法+匯總指標為主導的事後分析手段，在每個版本和叠代完成後對團隊效能進行回顧和評估，並樂此不疲地談論如何將叠代周期從一個月縮短到兩周，從而獲得「更快的反饋」。
本文將討論一種尚未被實踐過的方法論，即能否將「增長黑客」理論作用到研發過程的改進上，從而實作更可靠的定向效能最佳化？
一 研發團隊的北極星指標
在進行增長目標制定之前，團隊往往需要先確定一項能夠反映團隊成功情況且易觀測的「北極星指標」，譬如銷售額、簽單率、活躍使用者數等等。對於研發團隊來說，關鍵的指標主要是需求完成時長、功能缺陷率、使用者滿意度，諸如此類。以「需求完成時長」為例，這是一個相對客觀且直接反映開發團隊響應使用者需求速度的指標，即一個需求從提出到最終交付可用，所需要經歷的平均時間長度。
接下來我們定義一個相對理想的需求交付過程，並參考產品流量分析的「轉化漏鬥」結構表示出來：
相應的，將計畫中的所有需求都添加進來，可以繪制出類似這樣的「需求交付路徑圖」（範例，實際階段劃分應該更豐富）：
雖然略顯粗糙，但透過這種展現方式我們確實能夠追回不少在往常只統計結果數據的圖表裏遺失了的資訊。譬如同樣是兩個花10天完成的需求，一個開發用了7天，另一個開發只用了1天，其余時間花在了等待測試上，它們的差異在交付路徑圖上就能被清晰的區分出來。
這樣做的另幾項好處包括：
基於以上參照，我們可以得出以研發需求價值轉化的「效能黑客」模型（對應增長黑客的AARRR模型）：
有了北極星指標和視覺化的路徑，接下來的關鍵在於用數據指導效能改進。
二 時間軸上的AB測試
並非所有客戶都值得投入大量力氣來維系，增長團隊總是優先專註於高價值客戶的留存。在進行效能改進時也應當首先辨識差異，然後因材施教。
正如增長團隊常用的「RFM模型」客戶分類方法，針對研發需求，同樣可以透過與效能相關的正交維度來分類出可采用不同應對措施的需求集合，譬如「RIW模型」：
三個維度能將所有樣本分為8組，這個粒度非常適合圈定重點，同時又避免資訊太多過度發散。而選擇以上三組內容，不僅是因為它們具備較高區分度，還因為這幾項指標的觀測值都較容易獲得且能夠高頻更新，從而在研發過程中及時發現異常樣本並進行糾偏。
軟體研發是一項腦力勞動為主的活動，影響研發效能的因素包括且不限於開發者的個人能力、團隊氛圍、公司文化、計畫進度壓力、成員間的默契度、外部溝通成本、相關流程工具等等，其中絕大部份都是無法簡單用數值化衡量的主觀成分。雖然以往提及研發提效時，我們會出於技術可控的角度，著重談論平台能力、研發流程、工具支持等「療程短，見效快」的方法，但真實世界的研發提效手段要豐富得多。既可以采用技術工程手段，如提升構建速度、簡化上線流程、改進釋出工具；也可以采用組織文化手段，譬如最佳化獎懲策略、樹立先進標桿、調整人力結構、提升員工福利、加強技能培訓等等。那麽究竟哪種提效方法才最適合研發團隊呢？
對此，增長理論早就給出了答案，不論黑白貓，只要抓住老鼠就是好貓：做個AB測試。
與面向產品使用者的AB測試不同，進行計畫研發時，不能直接以單個需求為粒度進行AB測試（不便於計畫管理），相比之下，團隊或者叠代都是比較合適的AB粒度。具體的AB方法大家一點也會不陌生，譬如讓兩個計畫團隊采取不同的提效策略，對比效果，類似於「試點」和「樣板間」。或者讓同一個團隊在不同的叠代裏分別嘗試一些新的提效方法，然後根據效果來決定保留或放棄，這就是在「時間軸上做的AB測試」。
喏，一個新概念就這麽被創造出來了，不過現在還保持清醒著的讀者很快就會發現，這也不是什麽新鮮的主意，叠代回顧和改進會議不就是做這事情的嘛！其實不盡然。以往叠代回顧時的可分析數據主要是叠代燃盡圖和需求/缺陷累積圖，反映的是整體的趨勢情況，「整體均值」往往會掩蓋局部問題，這是達不到「AB測試」嚴謹性要求的。而前述的「需求轉化路徑」和「RIW分布」情況恰好能夠彌補上叠代過程細節，為效能改進的方法提供指導依據。
三 舶來主義的局限
在許多方面，透過埋點分析增長策略與透過研發事件分析提效策略之間確有共通之處，譬如埋點的四大要素：
此四項要素研發事件皆有，因而但凡埋點可用之方案，研發事件皆可套。這是舶來主義。
然而增長關註的是固定的一群使用者，追求拉新留存；提效面對的是日新月異的需求，追求按時交付。由於兩者的分析物件和目標不同，本質上依然存在差別：
此外，埋點記錄的頁面點選總是即時準確的，而需求的狀態依賴人工更新，實際操作未必及時，采集的事件數據因此經常存在時間偏差，這是研發數據分析的一項老大難問題。更充分的自動化是一種解決思路，譬如在阿裏雲·雲效的新版協作產品中，支持透過規則讓研發行為與任務更新關聯（比如程式碼送出觸發任務開始、流水線釋出觸發任務完成等），此舉將十分有助於增加效能分析的準確度。
最終，即便是模式化的借鑒，是否有效還需要實踐來證明。
四 暢想與小結
增長和提效，兩個看似風馬牛不相及的主題，由於一個腦洞，被聯系到了一起。
用產品思路營運技術團隊，用埋點數據還原研發過程，用轉化路徑洞察關鍵瓶頸。效能黑客，讓計畫進度更客觀，讓研發過程更透明。
人工智慧技術圖譜
阿裏雲天池傾力打造AI技術學習圖譜，含AI演算法開發學習路徑和AI套用開發學習路徑，共400小時，12個知識點，50個實踐案例，並配套有免費算力、珍稀數據集以及答疑等資源和服務，助力學習者在實踐中掌握AI知識。
點選這裏，開始學習吧~
版權聲明： 本文內容由阿裏雲實名註冊使用者自發貢獻，版權歸原作者所有，阿裏雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視【阿裏雲開發者社群使用者服務協定】和【阿裏雲開發者社群智慧財產權保護指引】。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。
