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

埋點(diǎn)作為記錄用戶行為的常規(guī)手段，伴隨著前端技術(shù)的發(fā)展早已歷經(jīng)春秋，不過直到“ 增長黑客 ”系列理論出現(xiàn)，才真正讓埋點(diǎn)分析變得內(nèi)涵豐富且有章可循。
?
與產(chǎn)品領(lǐng)域的“增長”類似，“提效”一直是研發(fā)領(lǐng)域里長盛不衰的主旋律。在軟件研發(fā)過程中，伴隨著項(xiàng)目開展，同樣會(huì)以事件的形式記錄下許多與代碼庫、流水線、任務(wù)相關(guān)的行為數(shù)據(jù)。這些數(shù)據(jù)的來源雖與頁面埋點(diǎn)不盡相同，其實(shí)質(zhì)用途卻有許多可類比之處。然而當(dāng)產(chǎn)品經(jīng)理們紛紛開始通過埋點(diǎn)的實(shí)時(shí)數(shù)據(jù)爭分奪秒調(diào)整市場營銷策略時(shí)，研發(fā)團(tuán)隊(duì)的 TL 和 PM 們依然只能使用統(tǒng)計(jì)方法+匯總指標(biāo)為主導(dǎo)的事后分析手段，在每個(gè)版本和迭代完成后對(duì)團(tuán)隊(duì)效能進(jìn)行回顧和評(píng)估，并樂此不疲地談?wù)撊绾螌⒌芷趶囊粋€(gè)月縮短到兩周，從而獲得“更快的反饋”。
?
本文將討論一種尚未被實(shí)踐過的方法論，即能否將“增長黑客”理論作用到研發(fā)過程的改進(jìn)上，從而實(shí)現(xiàn)更可靠的定向效能優(yōu)化？
?

一、研發(fā)團(tuán)隊(duì)的北極星指標(biāo)

?
在進(jìn)行增長目標(biāo)制定之前，團(tuán)隊(duì)往往需要先確定一項(xiàng)能夠反映團(tuán)隊(duì)成功情況且易觀測的“北極星指標(biāo)”，譬如銷售額、簽單率、活躍用戶數(shù)等等。對(duì)于研發(fā)團(tuán)隊(duì)來說，關(guān)鍵的指標(biāo)主要是需求完成時(shí)長、功能缺陷率、用戶滿意度，諸如此類。以“需求完成時(shí)長”為例，這是一個(gè)相對(duì)客觀且直接反映開發(fā)團(tuán)隊(duì)響應(yīng)用戶需求速度的指標(biāo)，即一個(gè)需求從提出到最終交付可用，所需要經(jīng)歷的平均時(shí)間長度。
?
接下來我們定義一個(gè)相對(duì)理想的需求交付過程，并參考產(chǎn)品流量分析的“轉(zhuǎn)化漏斗”結(jié)構(gòu)表示出來：
?

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

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

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

• 不但能直觀的看出總體的各階段交付進(jìn)展情況，也能從單個(gè)需求角度查看流經(jīng)的每個(gè)節(jié)點(diǎn)，并找到其他情況類似的需求，便于分析它們的共性特征。
• 用于事后分析時(shí)，可做交付結(jié)果的反向追溯，譬如查閱未按時(shí)交付的需求流經(jīng)此前各節(jié)點(diǎn)的比例。

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

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

二、時(shí)間軸上的 AB 測試

?
并非所有客戶都值得投入大量力氣來維系，增長團(tuán)隊(duì)總是優(yōu)先專注于高價(jià)值客戶的留存。在進(jìn)行效能改進(jìn)時(shí)也應(yīng)當(dāng)首先識(shí)別差異，然后因材施教。
?
正如增長團(tuán)隊(duì)常用的“ RFM 模型”客戶分類方法，針對(duì)研發(fā)需求，同樣可以通過與效能相關(guān)的正交維度來分類出可采用不同應(yīng)對(duì)措施的需求集合，譬如“ RIW 模型”：
?

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

三個(gè)維度能將所有樣本分為 8 組，這個(gè)粒度非常適合圈定重點(diǎn)，同時(shí)又避免信息太多過度發(fā)散。而選擇以上三組屬性，不僅是因?yàn)樗鼈兙邆漭^高區(qū)分度，還因?yàn)檫@幾項(xiàng)指標(biāo)的觀測值都較容易獲得且能夠高頻更新，從而在研發(fā)過程中及時(shí)發(fā)現(xiàn)異常樣本并進(jìn)行糾偏。
?
軟件研發(fā)是一項(xiàng)腦力勞動(dòng)為主的活動(dòng)，影響研發(fā)效能的因素包括且不限于開發(fā)者的個(gè)人能力、團(tuán)隊(duì)氛圍、公司文化、項(xiàng)目進(jìn)度壓力、成員間的默契度、外部溝通成本、相關(guān)流程工具等等，其中絕大部分都是無法簡單用數(shù)值化衡量的主觀成分。雖然以往提及研發(fā)提效時(shí)，我們會(huì)出于技術(shù)可控的角度，著重談?wù)撈脚_(tái)能力、研發(fā)流程、工具支持等“療程短，見效快”的方法，但真實(shí)世界的研發(fā)提效手段要豐富得多。既可以采用技術(shù)工程手段，如提升構(gòu)建速度、簡化上線流程、改進(jìn)發(fā)布工具；也可以采用組織文化手段，譬如優(yōu)化獎(jiǎng)懲策略、樹立先進(jìn)標(biāo)桿、調(diào)整人力結(jié)構(gòu)、提升員工福利、加強(qiáng)技能培訓(xùn)等等。那么究竟哪種提效方法才最適合研發(fā)團(tuán)隊(duì)呢？
?
對(duì)此，增長理論早就給出了答案，不論黑白貓，只要抓住老鼠就是好貓：做個(gè) AB 測試。

與面向產(chǎn)品用戶的 AB 測試不同，進(jìn)行項(xiàng)目研發(fā)時(shí)，不能直接以單個(gè)需求為粒度進(jìn)行 AB 測試（不便于項(xiàng)目管理），相比之下，團(tuán)隊(duì)或者迭代都是比較合適的 AB 粒度。具體的 AB 方法大家一點(diǎn)也會(huì)不陌生，譬如讓兩個(gè)項(xiàng)目團(tuán)隊(duì)采取不同的提效策略，對(duì)比效果，類似于“試點(diǎn)”和“樣板間”。或者讓同一個(gè)團(tuán)隊(duì)在不同的迭代里分別嘗試一些新的提效方法，然后根據(jù)效果來決定保留或放棄，這就是在“時(shí)間軸上做的 AB 測試”。
?
喏，一個(gè)新概念就這么被創(chuàng)造出來了，不過現(xiàn)在還保持清醒著的讀者很快就會(huì)發(fā)現(xiàn)，這也不是什么新鮮的主意，迭代回顧和改進(jìn)會(huì)議不就是做這事情的嘛！其實(shí)不盡然。以往迭代回顧時(shí)的可分析數(shù)據(jù)主要是迭代燃盡圖和需求/缺陷累積圖，反映的是整體的趨勢情況，“整體均值”往往會(huì)掩蓋局部問題，這是達(dá)不到“ AB 測試”嚴(yán)謹(jǐn)性要求的。而前述的“需求轉(zhuǎn)化路徑”和“ RIW 分布”情況恰好能夠彌補(bǔ)上迭代過程細(xì)節(jié)，為效能改進(jìn)的方法提供指導(dǎo)依據(jù)。
?

三、舶來主義的局限

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

此四項(xiàng)要素研發(fā)事件皆有，因而但凡埋點(diǎn)可用之方案，研發(fā)事件皆可套。這是舶來主義。
?
然而增長關(guān)注的是固定的一群用戶，追求拉新留存；提效面對(duì)的是日新月異的需求，追求按時(shí)交付。由于兩者的分析對(duì)象和目標(biāo)不同，本質(zhì)上依然存在差別：
?

• 用戶離開了又會(huì)回來，可以持續(xù)追蹤；需求完成就結(jié)束了，下次進(jìn)來的是新需求。這也是需求不適合做為 AB 測試粒度的原因。
• 拉新和留存可以越高越好，不設(shè)上限；交付效率不能單方面過度苛求，否則以犧牲質(zhì)量和疲勞戰(zhàn)術(shù)換取“提效”終將得不償失。
• 頁面路徑相對(duì)固定，譬如必須先經(jīng)過下單頁才能進(jìn)入付款頁；需求路徑則不一定，譬如一個(gè)“開發(fā)超期”的任務(wù)最終依然可能“按時(shí)交付”。

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

四、暢想與小結(jié)

?
增長和提效，兩個(gè)看似風(fēng)馬牛不相及的主題，由于一個(gè)腦洞，被聯(lián)系到了一起。
?
用產(chǎn)品思路運(yùn)營技術(shù)團(tuán)隊(duì)，用埋點(diǎn)數(shù)據(jù)還原研發(fā)過程，用轉(zhuǎn)化路徑洞察關(guān)鍵瓶頸。效能黑客，讓項(xiàng)目進(jìn)度更客觀，讓研發(fā)過程更透明。

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

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。