點擊參加51CTO網站內容調查問卷

譯者 | 布加迪

審校 | 重樓

技術已融入了現代工作場所的方方面面。運營成本、安全、通信、員工滿意度和客戶群都離不開技術的影子。精明的CIO知道高績效的IT組織和高績效的業務之間存在直接關聯。

作為技術領導者，您需要能夠衡量團隊的進展有多快、他們是否朝著正確的方向前進。如果不衡量，就無從改善。

一、從之前衡量方法的缺陷中汲取教訓

試圖衡量技術團隊的交付情況很棘手。團隊是個體的集合。以IT組織為例，這些個體在執行不同的復雜任務。多年來，軟件開發團隊的經理們嘗試了許多方法來衡量工作效率，其中大多數方法存在這兩個基本缺陷：

1. 注重產出而不是結果。

2. 強調個人而不是團隊。

這些有缺陷的方法產生了幾個反模式，它們不僅未能提供有意義的工作效率衡量指標，還導致團隊士氣低落。

代碼行數

也許最知名也是最討厭的衡量開發人員工作效率的做法是計算代碼行數。開發人員編寫的代碼行數與開發人員向組織交付的總價值之間幾乎沒有什么關聯。

事實上，就編寫的代碼行數獎勵開發人員會導致代碼臃腫，并最終導致更高的維護成本。

速度

鑒于敏捷方法在軟件開發界很流行，一些敏捷教練可能會推薦使用速度作為衡量團隊工作效率的一種方法。團隊速度而不是單個貢獻者速度是規劃工作負載的一個有用的度量指標。

然而作為衡量工作效率的指標，速度不盡如人意。將速度等同于工作效率只會導致開發人員夸大估計，從而不僅錯誤表述了團隊的效果，還可能使該度量指標在容量規劃中的有用性蕩然無存。

利用率

在許多咨詢機構，開發人員的利用率（即他們花在代碼上的時間）被用作工作效率的代名詞。這存在雙重缺陷，因為我們都知道努力并不總是意味著結果，因為這種度量方法激勵項目經理保持開發人員處于100%的利用率。

在數學中，隊列理論告訴我們，當利用率達到100%時，交付時間接近無窮大。這是由于利用率為100%的資源沒有能力來創新、改進或改變。

二、采用數據驅動的方法來衡量軟件交付

2018年，Nicole Forsgren、Jez Humble和Gene Kim發表了《Accelerate》一書，其中包括對來自2000多個不同組織的23000多份回復所作的聚類分析。他們在數據中發現了四個共同的特征，這些特征有助于將軟件開發團隊劃分為高績效、中績效或低績效：

• 變更的交付時間：從提交代碼到生產環境中運行需要多長時間？
• 部署頻次：您的團隊向實時客戶群交付軟件更新的頻次是多少？
• 平均恢復時間：生產環境中檢測到故障后，您的團隊需要多長時間才能恢復服務？
• 變更失敗率：對生產環境的變更隨后需要補救的百分比是多少？

三、考慮影響團隊表現的其他因素

除了嚴格基于代碼的度量指標外，還有幾個文化因素有助于評估軟件團隊的表現。

• 團隊成員積極尋求信息。
• 不會因為傳遞壞消息而受到懲罰。
• 責任共同承擔。
• 跨職能部門的協作得到獎勵。
• 失敗被視為改進的機會。
• 新想法總是受到歡迎。

四、留出時間來評估績效數據

一旦您知道了哪些指標可以表明團隊的績效，作為CIO您必須留出時間和資源來構建一個儀表板來衡量。所需的數據很可能不會來自單單一個地方，因此您需要從多個數據源捕獲和轉換數據，然后使用Tableau或PowerBI之類的自定義可視化工具來呈現。

最好從簡單的入手，逐漸擴展到能獲得最大價值的地方。您通常可以從版本控制系統和代碼管道上的API獲得所需的大部分定量數據。至于更多的定性度量，可以考慮使用季度調查。

五、根據績效數據實施變更

到頭來，如果組織沒有持續地審查數據并使用數據來修正業務方向，那么收集數據和度量指標（即便只是一小部分）也純屬浪費精力。

作為一家組織，應當留出時間來定期審查度量指標，收集寶貴信息，并基于數據實施變更，這是成為一家高績效IT企業的最快途徑。

原文標題：5 tips for measuring developer productivity，作者：William J. Francis