譯者 | 布加迪
審校 | 重樓
技術(shù)已融入了現(xiàn)代工作場所的方方面面。運(yùn)營成本、安全、通信、員工滿意度和客戶群都離不開技術(shù)的影子。精明的CIO知道高績效的IT組織和高績效的業(yè)務(wù)之間存在直接關(guān)聯(lián)。
作為技術(shù)領(lǐng)導(dǎo)者，您需要能夠衡量團(tuán)隊(duì)的進(jìn)展有多快、他們是否朝著正確的方向前進(jìn)。如果不衡量，就無從改善。
一、從之前衡量方法的缺陷中汲取教訓(xùn)
試圖衡量技術(shù)團(tuán)隊(duì)的交付情況很棘手。團(tuán)隊(duì)是個體的集合。以IT組織為例，這些個體在執(zhí)行不同的復(fù)雜任務(wù)。多年來，軟件開發(fā)團(tuán)隊(duì)的經(jīng)理們嘗試了許多方法來衡量工作效率，其中大多數(shù)方法存在這兩個基本缺陷：
1. 注重產(chǎn)出而不是結(jié)果。
2. 強(qiáng)調(diào)個人而不是團(tuán)隊(duì)。
這些有缺陷的方法產(chǎn)生了幾個反模式，它們不僅未能提供有意義的工作效率衡量指標(biāo)，還導(dǎo)致團(tuán)隊(duì)士氣低落。
代碼行數(shù)
也許最知名也是最討厭的衡量開發(fā)人員工作效率的做法是計(jì)算代碼行數(shù)。開發(fā)人員編寫的代碼行數(shù)與開發(fā)人員向組織交付的總價值之間幾乎沒有什么關(guān)聯(lián)。
事實(shí)上，就編寫的代碼行數(shù)獎勵開發(fā)人員會導(dǎo)致代碼臃腫，并最終導(dǎo)致更高的維護(hù)成本。
速度
鑒于敏捷方法在軟件開發(fā)界很流行，一些敏捷教練可能會推薦使用速度作為衡量團(tuán)隊(duì)工作效率的一種方法。團(tuán)隊(duì)速度而不是單個貢獻(xiàn)者速度是規(guī)劃工作負(fù)載的一個有用的度量指標(biāo)。
然而作為衡量工作效率的指標(biāo)，速度不盡如人意。將速度等同于工作效率只會導(dǎo)致開發(fā)人員夸大估計(jì)，從而不僅錯誤表述了團(tuán)隊(duì)的效果，還可能使該度量指標(biāo)在容量規(guī)劃中的有用性蕩然無存。
利用率
在許多咨詢機(jī)構(gòu)，開發(fā)人員的利用率（即他們花在代碼上的時間）被用作工作效率的代名詞。這存在雙重缺陷，因?yàn)槲覀兌贾琅Σ⒉豢偸且馕吨Y(jié)果，因?yàn)檫@種度量方法激勵項(xiàng)目經(jīng)理保持開發(fā)人員處于100%的利用率。
在數(shù)學(xué)中，隊(duì)列理論告訴我們，當(dāng)利用率達(dá)到100%時，交付時間接近無窮大。這是由于利用率為100%的資源沒有能力來創(chuàng)新、改進(jìn)或改變。
二、采用數(shù)據(jù)驅(qū)動的方法來衡量軟件交付
2018年，Nicole Forsgren、Jez Humble和Gene Kim發(fā)表了《Accelerate》一書，其中包括對來自2000多個不同組織的23000多份回復(fù)所作的聚類分析。他們在數(shù)據(jù)中發(fā)現(xiàn)了四個共同的特征，這些特征有助于將軟件開發(fā)團(tuán)隊(duì)劃分為高績效、中績效或低績效：
- 變更的交付時間：從提交代碼到生產(chǎn)環(huán)境中運(yùn)行需要多長時間？
- 部署頻次：您的團(tuán)隊(duì)向?qū)崟r客戶群交付軟件更新的頻次是多少？
- 平均恢復(fù)時間：生產(chǎn)環(huán)境中檢測到故障后，您的團(tuán)隊(duì)需要多長時間才能恢復(fù)服務(wù)？
- 變更失敗率：對生產(chǎn)環(huán)境的變更隨后需要補(bǔ)救的百分比是多少？
三、考慮影響團(tuán)隊(duì)表現(xiàn)的其他因素
除了嚴(yán)格基于代碼的度量指標(biāo)外，還有幾個文化因素有助于評估軟件團(tuán)隊(duì)的表現(xiàn)。
- 團(tuán)隊(duì)成員積極尋求信息。
- 不會因?yàn)閭鬟f壞消息而受到懲罰。
- 責(zé)任共同承擔(dān)。
- 跨職能部門的協(xié)作得到獎勵。
- 失敗被視為改進(jìn)的機(jī)會。
- 新想法總是受到歡迎。
四、留出時間來評估績效數(shù)據(jù)
一旦您知道了哪些指標(biāo)可以表明團(tuán)隊(duì)的績效，作為CIO您必須留出時間和資源來構(gòu)建一個儀表板來衡量。所需的數(shù)據(jù)很可能不會來自單單一個地方，因此您需要從多個數(shù)據(jù)源捕獲和轉(zhuǎn)換數(shù)據(jù)，然后使用Tableau或PowerBI之類的自定義可視化工具來呈現(xiàn)。
最好從簡單的入手，逐漸擴(kuò)展到能獲得最大價值的地方。您通常可以從版本控制系統(tǒng)和代碼管道上的API獲得所需的大部分定量數(shù)據(jù)。至于更多的定性度量，可以考慮使用季度調(diào)查。
五、根據(jù)績效數(shù)據(jù)實(shí)施變更
到頭來，如果組織沒有持續(xù)地審查數(shù)據(jù)并使用數(shù)據(jù)來修正業(yè)務(wù)方向，那么收集數(shù)據(jù)和度量指標(biāo)（即便只是一小部分）也純屬浪費(fèi)精力。
作為一家組織，應(yīng)當(dāng)留出時間來定期審查度量指標(biāo)，收集寶貴信息，并基于數(shù)據(jù)實(shí)施變更，這是成為一家高績效IT企業(yè)的最快途徑。
原文標(biāo)題：5 tips for measuring developer productivity，作者：William J. Francis
