如何用增加的思惟作提效？

簡介：本文將討論一種還沒有被實踐過的方法論，即可否將「增加黑客」理論做用到研發過程的改進上，從而實現更可靠的定向效能優化？

埋點做爲記錄用戶行爲的常規手段，伴隨着前端技術的發展早已歷經春秋，不過直到「 增加黑客 」系列理論出現，才真正讓埋點分析變得內涵豐富且有章可循。
​
與產品領域的「增加」相似，「提效」一直是研發領域裏長盛不衰的主旋律。在軟件研發過程當中，伴隨着項目開展，一樣會以事件的形式記錄下許多與代碼庫、流水線、任務相關的行爲數據。這些數據的來源雖與頁面埋點不盡相同，其實質用途卻有許多可類比之處。然而當產品經理們紛紛開始經過埋點的實時數據爭分奪秒調整市場營銷策略時，研發團隊的 TL 和 PM 們依然只能使用統計方法+彙總指標爲主導的過後分析手段，在每一個版本和迭代完成後對團隊效能進行回顧和評估，並樂此不疲地談論如何將迭代週期從一個月縮短到兩週，從而得到「更快的反饋」。
​
本文將討論一種還沒有被實踐過的方法論，即可否將「增加黑客」理論做用到研發過程的改進上，從而實現更可靠的定向效能優化？
​

1、研發團隊的北極星指標

​
在進行增加目標制定以前，團隊每每須要先肯定一項可以反映團隊成功狀況且易觀測的「北極星指標」，譬如銷售額、簽單率、活躍用戶數等等。對於研發團隊來講，關鍵的指標主要是需求完成時長、功能缺陷率、用戶滿意度，諸如此類。以「需求完成時長」爲例，這是一個相對客觀且直接反映開發團隊響應用戶需求速度的指標，即一個需求從提出到最終交付可用，所須要經歷的平均時間長度。
​
接下來咱們定義一個相對理想的需求交付過程，並參考產品流量分析的「轉化漏斗」結構表示出來：
​

相應的，將項目中的全部需求都添加進來，能夠繪製出相似這樣的「需求交付路徑圖」（示例，實際階段劃分應該更豐富）：
​

雖然略顯粗糙，但經過這種展示方式咱們確實可以追回很多在往常只統計結果數據的圖表裏丟失了的信息。譬如一樣是兩個花 10 天完成的需求，一個開發用了 7 天，另外一個開發只用了 1 天，其他時間花在了等待測試上，它們的差別在交付路徑圖上就能被清晰的區分出來。
​
這樣作的另幾項好處包括：
​

• 即便一個須要還未最終交付，而是被阻滯在了某個環節、或者出現了返工，也可以在第一時間以異常流量的形式顯著的展示在路徑圖上，從而及時引發 TL 和 PM 的關注。

• 不但能直觀的看出整體的各階段交付進展狀況，也能從單個需求角度查看流經的每一個節點，並找到其餘狀況相似的需求，便於分析它們的共性特徵。
• 用於過後分析時，可作交付結果的反向追溯，譬如查閱未按時交付的需求流經此前各節點的比例。

基於以上參照，咱們能夠得出以研發需求價值轉化的「效能黑客」模型（對應增加黑客的 AARRR 模型）：
​

有了北極星指標和可視化的路徑，接下來的關鍵在於用數據指導效能改進。
​

2、時間軸上的 AB 測試

​
並不是全部客戶都值得投入大量力氣來維繫，增加團隊老是優先專一於高價值客戶的留存。在進行效能改進時也應當首先識別差別，而後因材施教。
​
正如增加團隊經常使用的「 RFM 模型」客戶分類方法，針對研發需求，一樣能夠經過與效能相關的正交維度來分類出可採用不一樣應對措施的需求集合，譬如「 RIW 模型」：
​

• A（Activity）需求的近期活躍度（相關事件頻率）
• I（Importance）需求的重要程度（優先級、距離計劃完成的剩餘時間）
• W（Workload）需求關聯的已投入開發工做量（譬如代碼修改行數）

三個維度能將全部樣本分爲 8 組，這個粒度很是適合圈定重點，同時又避免信息太多過分發散。而選擇以上三組屬性，不只是由於它們具有較高區分度，還由於這幾項指標的觀測值都較容易得到且可以高頻更新，從而在研發過程當中及時發現異常樣本並進行糾偏。
​
軟件研發是一項腦力勞動爲主的活動，影響研發效能的因素包括且不限於開發者的我的能力、團隊氛圍、公司文化、項目進度壓力、成員間的默契度、外部溝通成本、相關流程工具等等，其中絕大部分都是沒法簡單用數值化衡量的主觀成分。雖然以往說起研發提效時，咱們會出於技術可控的角度，着重談論平臺能力、研發流程、工具支持等「療程短，見效快」的方法，但真實世界的研發提效手段要豐富得多。既能夠採用技術工程手段，如提高構建速度、簡化上線流程、改進發布工具；也能夠採用組織文化手段，譬如優化獎懲策略、樹立先進標杆、調整人力結構、提高員工福利、增強技能培訓等等。那麼究竟哪一種提效方法才最適合研發團隊呢？
​
對此，增加理論早就給出了答案，不論黑白貓，只要抓住老鼠就是好貓：作個 AB 測試。

與面向產品用戶的 AB 測試不一樣，進行項目研發時，不能直接以單個需求爲粒度進行 AB 測試（不便於項目管理），相比之下，團隊或者迭代都是比較合適的 AB 粒度。具體的 AB 方法你們一點也會不陌生，譬如讓兩個項目團隊採起不一樣的提效策略，對比效果，相似於「試點」和「樣板間」。或者讓同一個團隊在不一樣的迭代裏分別嘗試一些新的提效方法，而後根據效果來決定保留或放棄，這就是在「時間軸上作的 AB 測試」。
​
喏，一個新概念就這麼被創造出來了，不過如今還保持清醒着的讀者很快就會發現，這也不是什麼新鮮的主意，迭代回顧和改進會議不就是作這事情的嘛！其實不盡然。以往迭代回顧時的可分析數據主要是迭代燃盡圖和需求/缺陷累積圖，反映的是總體的趨勢狀況，「總體均值」每每會掩蓋局部問題，這是達不到「 AB 測試」嚴謹性要求的。而前述的「需求轉化路徑」和「 RIW 分佈」狀況剛好可以彌補上迭代過程細節，爲效能改進的方法提供指導依據。
​

3、舶來主義的侷限

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

此四項要素研發事件皆有，於是但凡埋點可用之方案，研發事件皆可套。這是舶來主義。
​
然而增加關注的是固定的一羣用戶，追求拉新留存；提效面對的是突飛猛進的需求，追求按時交付。因爲二者的分析對象和目標不一樣，本質上依然存在差異：
​

• 用戶離開了又會回來，能夠持續追蹤；需求完成就結束了，下次進來的是新需求。這也是需求不適合作爲 AB 測試粒度的緣由。
• 拉新和留存能夠越高越好，不設上限；交付效率不能單方面過分苛求，不然以犧牲質量和疲勞戰術換取「提效」終將得不償失。
• 頁面路徑相對固定，譬如必須先通過下單頁才能進入付款頁；需求路徑則不必定，譬如一個「開發超期」的任務最終依然可能「按時交付」。

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

4、暢想與小結

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

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