作者 | rafiq gemmail
譯者 |平川。
策展 | tina
Gergely Orosz（《The Pragmatic Engineer Newsletter》的作者）和ABI Noda（DX的首席執行官和DevEx框架的建立者之一）在Pragmatic Engineer上發表了一篇題為“Development Productivity Measure： A Real-World Case Study”的文章。 InfoQ 報道了 NODA 對 17 家知名科技巨頭使用的工程指標的調查結果。 NODA發現，頂級團隊並沒有大規模採用DORA或SPACE等框架，而是混合使用特定於組織的定性和定量指標。 NODA 和 Orosz 根據指標實施團隊尋求的結果進行逆向工作，為定義此類指標提供建議。
野田寫道，他“採訪了 17 家衡量開發人員生產力的知名科技公司的團隊”。 在這篇文章中，Noda和Orosz重點介紹了四種型別的組織：擁有10萬名員工的谷歌，擁有1萬名員工的LinkedIn，員工人數少於10,000人的Peloton，以及員工人數少於1,000人的Notion和Postman。 使用的指標範圍從典型的 PR 和 CI 指標到 Google 系統選擇的指標。
NODA觀察到，在實踐中，“DORA和SPACE指標是有選擇地使用的”，而不是完全使用。 他寫道，雖然調查顯示“每家公司都有自己量身定製的方法”，但他認為“任何規模的組織都可以採用谷歌的整體理念和方法。 Noda寫道，谷歌的方法要求根據三種型別的指標來選擇指標：速度、易用性和質量。 他寫道，這三個維度之間存在著一種“緊張的關係”，“有助於揭示潛在的權衡”。
野田寫道，谷歌使用“定性和定量措施來計算指標”，因為它提供了“最全面的圖片”。 野田列舉了谷歌使用的一系列資訊獲取方法，從滿意度調查到“使用日誌指標”。 他寫道：
無論是衡量工具、流程還是團隊，Google 的開發智慧型團隊都認為單一指標無法衡量生產力。 相反，他們從速度、易用性和質量方面看待生產力。類似地，Noda和Orosz描述了LinkedIn如何將季度開發人員滿意度調查與定量指標相結合。 在文章中，Noda提到了LinkedIn開發者洞察團隊使用的一系列指標。 這些指標旨在減少“對關鍵發展活動的抵制”。 團隊使用的指標包括 CI 穩定性指標、部署成功率、P50 和 P90 生成時間、評審響應時間以及提交通過 CI 管道的時間。 Noda 描述了團隊如何通過定性見解來支援這種定量衡量標準，並給出了乙個將構建時間與“開發人員對構建的滿意度”進行比較的示例。 LinkedIn還使用“Winsorated Mean”對客觀數字指標進行降噪。
溫莎平均值意味著找到第 99 個百分位數，然後將所有資料點切到第 99 個百分位數以上，而不是剔除它們。 如果第 99 個百分位數是 100 秒，而您的資料點是 110 秒，則劃掉 110 並寫入 100，現在您計算的平均值是乙個更有用的數字。野田寫道，Peloton代表了乙個擁有3,000至4,000名員工的組織，它已經從最初的“通過開發經驗調查獲得定性見解”發展到納入定量指標。 例如，提前期和部署頻率被用作速度的客觀指標。 他寫道，Peloton 的指標還包括定性參與分數、服務恢復時間和**質量（通過“250 行以下的 PR、線路覆蓋率和變更失敗率”的百分比來衡量）。
在談到像 Notion 和 Postman 這樣規模較小的“擴充套件”組織時，Noda 寫道，這些組織通常專注於衡量“可移動指標”。 他解釋說，這是乙個易受攻擊的指標，指標實施團隊可以“通過他們的工作對指標產生積極或消極的影響來四處走動”。 這方面的乙個例子是“易於交付”。 Noda寫道，這個指標反映了“認知負荷和反饋迴圈”，可以根據“開發人員覺得完成工作的難易程度”進行調整。 另乙個常見的可移動指標是“開發人員因障礙和阻力而損失的時間百分比”。 NODA 描述了該指標如何反映其價值：
這個指標可以兌換成錢：這是最大的好處！ 這使得企業領導者很容易理解時間損失。 例如，如果乙個擁有 1000 萬美元工程工資成本的組織通過一項計畫將損失的時間從 20% 減少到 10%，這將節省 100 萬美元。鑑於此類工程指標的上下文性質，NODA 建議組織在以下步驟中定義指標：
在使命宣言中定義你的目標，解釋“你為什麼有乙個開發生產力團隊？ ”
從目標開始，根據速度、易用性和質量定義頂級指標。
定義與“特定專案或目標關鍵結果”相關的“運營層面指標”，例如，特定開發生產力提高服務的採用率。
NODA舉例指出，所選擇的指標應考慮速度、易用性和質量等維度。 例如，如果目標是讓開發人員更容易“交付高質量的軟體”，那麼指標應該包括“感知交付速度”、“交付的難易程度”和“事件頻率”，他說。
Orosz 和 Noda 的這篇文章遵循“回應麥肯錫：衡量開發人員生產力？ 之後又發表了一篇文章。 在上一篇文章中，Orosz 與 Kent Beck 合作挑戰了麥肯錫的文章“是的，你可以衡量軟體開發人員的生產力”。 麥肯錫的文章提出了我們所說的“以機會為中心”的指標，“以確定如何改進產品的交付方式以及如何提高價值”。 本文討論了基於 dora 和 space 的開發人員生產力衡量標準，包括鼓勵領導者優化單個開發人員效率的建議，以及“非編碼活動（例如，設計會議）”的示例。 本文提出的指標包括跟蹤“個人貢獻”和衡量“人才能力得分”。
貝克警告說，衡量個人生產力而不是交付結果的風險，並分享了他自己的經驗，看到這些指標變成“激勵改進的金錢和地位指標”。 他說，雖然這可能導致“行為改變”，但它也可能受到遊戲化的影響，變成“以創造性方式改進這些指標”的激勵措施。 Beck和Orosz鼓勵領導者專注於衡量“影響”而不是“工作量”。 特別是，貝克建議，這些指標應該只用於被測量事物的持續改進反饋迴圈，而不是其他任何事情。 他還警告說，濫用指標來衡量個人可能會導致安全問題：
弄清楚你為什麼要問這個問題，以及你和被測量者之間的權力關係。 當那些有權力的人衡量那些沒有權力的人時，結果是扭曲的......分析它收集的任何級別的資料，以避免不正當的激勵。 我可以分析我自己的資料，我的團隊也可以分析他們自己的彙總資料。 NODA 還警告說，如果 CTO、VPE 或工程總監級別的人員需要提供開發人員績效指標，最好確保報告處於適當的水平。 NODA 建議選擇表示業務影響、系統效能和工程組織級開發效率的指標，例如專案級指標使用者 NPS 和損失的一周時間。 NODA建議高層領導：
在這種情況下，我建議最好重新定義問題。 你的領導團隊不想要完美的生產力指標，而是一種強調你是他們工程投資的好管家的方法。在回應麥肯錫的報告時，Orosz和Beck警告說，“人們會優化所衡量的東西。 他們引用了古德哈特定律，該定律指出“當乙個措施成為目標時，它就不再是乙個好的措施。 ”
原文鏈結：