簡介：本文將討論一種尚未被實踐過的方法論，即能否將“增長黑客”理論作用到研發過程的改進上，從而實現更可靠的定向效能優化？

埋點作為記錄用戶行為的常規手段，伴隨著前端技術的發展早已歷經春秋，不過直到“ 增長黑客 ”系列理論出現，才真正讓埋點分析變得內涵豐富且有章可循。
?
與產品領域的“增長”類似，“提效”一直是研發領域里長盛不衰的主旋律。在軟件研發過程中，伴隨著項目開展，同樣會以事件的形式記錄下許多與代碼庫、流水線、任務相關的行為數據。這些數據的來源雖與頁面埋點不盡相同，其實質用途卻有許多可類比之處。然而當產品經理們紛紛開始通過埋點的實時數據爭分奪秒調整市場營銷策略時，研發團隊的 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 測試粒度的原因。
• 拉新和留存可以越高越好，不設上限；交付效率不能單方面過度苛求，否則以犧牲質量和疲勞戰術換取“提效”終將得不償失。
• 頁面路徑相對固定，譬如必須先經過下單頁才能進入付款頁；需求路徑則不一定，譬如一個“開發超期”的任務最終依然可能“按時交付”。

此外，埋點記錄的頁面點擊總是實時準確的，而需求的狀態依賴人工更新，實際操作未必及時，采集的事件數據因此經常存在時間偏差，這是研發數據分析的一項老大難問題。更充分的自動化是一種解決思路，譬如在阿里云·云效的新版協作產品中，支持通過規則讓研發行為與任務更新關聯（比如代碼提交觸發任務開始、流水線發布觸發任務完成等），此舉將十分有助于增加效能分析的準確度。
?
最終，即便是模式化的借鑒，是否有效還需要實踐來證明。
?

四、暢想與小結

?
增長和提效，兩個看似風馬牛不相及的主題，由于一個腦洞，被聯系到了一起。
?
用產品思路運營技術團隊，用埋點數據還原研發過程，用轉化路徑洞察關鍵瓶頸。效能黑客，讓項目進度更客觀，讓研發過程更透明。

原文鏈接：https://developer.aliyun.com/article/784807?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的如何用增长的思维做提效？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。