點(diǎn)擊參加51CTO網(wǎng)站內(nèi)容調(diào)查問卷

譯者 | 布加迪

審校 | 重樓

技術(shù)已融入了現(xiàn)代工作場(chǎng)所的方方面面。運(yùn)營成本、安全、通信、員工滿意度和客戶群都離不開技術(shù)的影子。精明的CIO知道高績(jī)效的IT組織和高績(jī)效的業(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ì)是個(gè)體的集合。以IT組織為例，這些個(gè)體在執(zhí)行不同的復(fù)雜任務(wù)。多年來，軟件開發(fā)團(tuán)隊(duì)的經(jīng)理們嘗試了許多方法來衡量工作效率，其中大多數(shù)方法存在這兩個(gè)基本缺陷：

1. 注重產(chǎn)出而不是結(jié)果。

2. 強(qiáng)調(diào)個(gè)人而不是團(tuán)隊(duì)。

這些有缺陷的方法產(chǎn)生了幾個(gè)反模式，它們不僅未能提供有意義的工作效率衡量指標(biāo)，還導(dǎo)致團(tuán)隊(duì)士氣低落。

代碼行數(shù)

也許最知名也是最討厭的衡量開發(fā)人員工作效率的做法是計(jì)算代碼行數(shù)。開發(fā)人員編寫的代碼行數(shù)與開發(fā)人員向組織交付的總價(jià)值之間幾乎沒有什么關(guān)聯(lián)。

事實(shí)上，就編寫的代碼行數(shù)獎(jiǎng)勵(lì)開發(fā)人員會(huì)導(dǎo)致代碼臃腫，并最終導(dǎo)致更高的維護(hù)成本。

速度

鑒于敏捷方法在軟件開發(fā)界很流行，一些敏捷教練可能會(huì)推薦使用速度作為衡量團(tuán)隊(duì)工作效率的一種方法。團(tuán)隊(duì)速度而不是單個(gè)貢獻(xiàn)者速度是規(guī)劃工作負(fù)載的一個(gè)有用的度量指標(biāo)。

然而作為衡量工作效率的指標(biāo)，速度不盡如人意。將速度等同于工作效率只會(huì)導(dǎo)致開發(fā)人員夸大估計(jì)，從而不僅錯(cuò)誤表述了團(tuán)隊(duì)的效果，還可能使該度量指標(biāo)在容量規(guī)劃中的有用性蕩然無存。

利用率

在許多咨詢機(jī)構(gòu)，開發(fā)人員的利用率（即他們花在代碼上的時(shí)間）被用作工作效率的代名詞。這存在雙重缺陷，因?yàn)槲覀兌贾琅Σ⒉豢偸且馕吨Y(jié)果，因?yàn)檫@種度量方法激勵(lì)項(xiàng)目經(jīng)理保持開發(fā)人員處于100%的利用率。

在數(shù)學(xué)中，隊(duì)列理論告訴我們，當(dāng)利用率達(dá)到100%時(shí)，交付時(shí)間接近無窮大。這是由于利用率為100%的資源沒有能力來創(chuàng)新、改進(jìn)或改變。

二、采用數(shù)據(jù)驅(qū)動(dòng)的方法來衡量軟件交付

2018年，Nicole Forsgren、Jez Humble和Gene Kim發(fā)表了《Accelerate》一書，其中包括對(duì)來自2000多個(gè)不同組織的23000多份回復(fù)所作的聚類分析。他們?cè)跀?shù)據(jù)中發(fā)現(xiàn)了四個(gè)共同的特征，這些特征有助于將軟件開發(fā)團(tuán)隊(duì)劃分為高績(jī)效、中績(jī)效或低績(jī)效：

• 變更的交付時(shí)間：從提交代碼到生產(chǎn)環(huán)境中運(yùn)行需要多長(zhǎng)時(shí)間？
• 部署頻次：您的團(tuán)隊(duì)向?qū)崟r(shí)客戶群交付軟件更新的頻次是多少？
• 平均恢復(fù)時(shí)間：生產(chǎn)環(huán)境中檢測(cè)到故障后，您的團(tuán)隊(duì)需要多長(zhǎng)時(shí)間才能恢復(fù)服務(wù)？
• 變更失敗率：對(duì)生產(chǎn)環(huán)境的變更隨后需要補(bǔ)救的百分比是多少？

三、考慮影響團(tuán)隊(duì)表現(xiàn)的其他因素

除了嚴(yán)格基于代碼的度量指標(biāo)外，還有幾個(gè)文化因素有助于評(píng)估軟件團(tuán)隊(duì)的表現(xiàn)。

• 團(tuán)隊(duì)成員積極尋求信息。
• 不會(huì)因?yàn)閭鬟f壞消息而受到懲罰。
• 責(zé)任共同承擔(dān)。
• 跨職能部門的協(xié)作得到獎(jiǎng)勵(lì)。
• 失敗被視為改進(jìn)的機(jī)會(huì)。
• 新想法總是受到歡迎。

四、留出時(shí)間來評(píng)估績(jī)效數(shù)據(jù)

一旦您知道了哪些指標(biāo)可以表明團(tuán)隊(duì)的績(jī)效，作為CIO您必須留出時(shí)間和資源來構(gòu)建一個(gè)儀表板來衡量。所需的數(shù)據(jù)很可能不會(huì)來自單單一個(gè)地方，因此您需要從多個(gè)數(shù)據(jù)源捕獲和轉(zhuǎn)換數(shù)據(jù)，然后使用Tableau或PowerBI之類的自定義可視化工具來呈現(xiàn)。

最好從簡(jiǎn)單的入手，逐漸擴(kuò)展到能獲得最大價(jià)值的地方。您通常可以從版本控制系統(tǒng)和代碼管道上的API獲得所需的大部分定量數(shù)據(jù)。至于更多的定性度量，可以考慮使用季度調(diào)查。

五、根據(jù)績(jī)效數(shù)據(jù)實(shí)施變更

到頭來，如果組織沒有持續(xù)地審查數(shù)據(jù)并使用數(shù)據(jù)來修正業(yè)務(wù)方向，那么收集數(shù)據(jù)和度量指標(biāo)（即便只是一小部分）也純屬浪費(fèi)精力。

作為一家組織，應(yīng)當(dāng)留出時(shí)間來定期審查度量指標(biāo)，收集寶貴信息，并基于數(shù)據(jù)實(shí)施變更，這是成為一家高績(jī)效IT企業(yè)的最快途徑。

原文標(biāo)題：5 tips for measuring developer productivity，作者：William J. Francis