這是鼎叔的第一百一十三篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本專欄和微信公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），文末有連結。
我們繼續聊聊，為什麼看著挺好的度量指標，在實際考核工程師績效時，常常起了負面效果？
相關前文：聊聊傳統質量觀 VS 敏捷質量觀
從本能上，工程師會遵循經濟學的規律。沒有任何一個單一簡單的指標經得起各種推敲，聰明的工程師一定有辦法把他變成 “虛榮指標”——看著很好看，但是沒有起到促進效益的作用。尤其當我們把度量指標和績效掛鉤時，它很容易被人扭曲成讓人誤導的解釋，以便獲得更多的利益。
下面是鼎叔經歷過的因質量度量引發負面效果的幾個例子。
一、考核測試工程師的缺陷定級準確性
某大型公司，會嚴格考核工程師提交缺陷的級別準確性，背景是不同的缺陷級別的處理優先順序不同，有限的開發人力只能在釋出日之前保證處理一部分高階別缺陷。因此 QA 會對執行測試的初級工程師進行定級標準培訓，並對其結果加以考核。如何判斷定級是否準確呢？以開發在修復缺陷時判斷為主。
這個場景存在的問題：
雖然定級有指導模型，但是不同權重因素的交織（影響使用者範圍、頻率、營銷里程碑，重複發生情況、領導關注，品牌和安全等等），使得總有部分缺陷的嚴重程度是無法達成共識的，從測試的意願（希望缺陷被修復）會採納更高的定級規則。而從疲於修復缺陷的開發角度，利用各種不可能被事先約定的理由來降低缺陷級別就成了更佳選擇，尤其是有些缺陷不容易重現，開發就更有動力阻止缺陷的升級。
此外，如果定級被認為不準，會影響績效，那麼測試人員在看到一個疑似缺陷或難以復現的缺陷，他會不會選擇不提交資料庫呢？當然是可能的，因為很難有確鑿證據證明這是個明白無誤的缺陷。更有甚者，開發會單方面解釋這是 “使用者的誤解”，產品就是這麼設計的，解釋一下就好了。定級準確率度量就會進一步阻止測試人員據理力爭和澄清到底的意願。
二、度量各模組導致的事故數量和級別，並進行處罰
如果我們把一年來所有的線上事故進行盤點，按照引入故障的根因模組進行排序，會發現越是關鍵的中樞模組，排序越靠前。也就是說，如果按照事故引入數量和級別來處罰，那麼越是公司的核心架構師，被處罰得越狠。
《人月神話》這本書提到，一個軟體複雜度是由它的核心概念所構建的，它很難透過系列自動化手段大幅縮短開發週期。同樣的道理，一個複雜系統軟體，容易出問題的地方，往往是概念複雜度更高的模組，它和員工敬不敬業，認不認真沒有必然關係。
因為組織結構決定軟體風險，核心的中樞模組，往往會挑選最厲害的工程師來設計和維護，長此以往，只有他最精通這個超複雜模組的內部和關聯模組的互動邏輯，也只有他能快速解決問題（當然這種狀態對組織來說並不健康）。對於複雜業務邏輯鏈條和大量模組呼叫的產品，出故障機率最高的也是這裡。因此，以故障數量和級別來處罰這個資深員工，顯然是不合理的。
三、測試用例的自動化率
這也是技術部門最常見的考核指標，度量所有用例中實現了自動化的比率，確認考核結果的方式就是看自動化平臺的指標呈現。
作為初期的自動化建設牽引，這個指標是有一定正向價值的，但是隨著團隊越來越成熟，這個指標的價值就不一定正向了。
本公眾號一直在強調，自動化不是靈丹妙藥，不是越多越好，而是看自動化的目的是什麼，執行和維護的成本有多高。
現有的用例中，如果很多是面向使用者驗收的場景，可能隨著產品變更而變化很大，是不是都要做成自動化並長期維護（矯正）呢？另外，越涉及完整互動鏈條和視覺驗證的業務，自動化成本越貴。何況很多老用例的設計都已經過時了，價值很低但是數量龐大，納入自動化目標的話得不償失。
另一方面，工程師有多種方法對自動化平臺的指標進行突擊，比如強行 hardcode 透過，或者快考核時再錄製修改指令碼，這些自動化並不能在研發過程中起到持續保障作用。
四、透過用例發現的缺陷數量（或用例缺陷密度）
從強化用例設計的有效性來說，這個指標表面上有積極作用的。但是關注用例的缺陷密度，有可能阻止測試人員動態地探索需求的邊界，透過用例數量限制了思路發揮，得不償失。
有些公司使用這個指標，更多的是為了節省測試人力，希望降低用例數量後，能以更少的人力發現數量儘量多的缺陷，但是這個指標的想法是一廂情願，因為用例和缺陷之間沒有等比例的關聯度。從邏輯而言，歷史重災區（破舊功能模組）遺留的缺陷更多，但這個指標是否導致測試人員聚集於此，而忽視了 “非高危模組” 的風險呢？
同理，度量開發人員的 “程式碼量”，以及 “程式碼缺陷密度”，也有類似的負面效應，對程式碼量進行 “注水” 太容易了。開發的人均交付價值大小建議用交付的故事價值點數除以投入週期來決定。
綜上所述，依賴度量指標考核工程師績效經常很不靠譜，指標僅作為某個客觀事實，供管理者參考。
那什麼樣的資料更適合用來作為績效參考呢？基於敏捷理念，我覺得這些反饋更有價值：特性交付的整體效果，質量評價，特性團隊的評價，直屬經理與之共事的評價，專業能力建設等等。績效管理要考慮的內容很多，本篇就不太多展開了。
進一步聊聊- 度量的誤區
我們即使有機會為真正擁抱敏捷的研發團隊進行質量度量，而且被度量的人員也沒有作弊行為，那設計出來的度量指標就一定滿足預期效果麼？顯然不是的，度量指標設計並不容易，經常會踩入一系列誤區。
誤區一，認為度量沒有成本。
實際上，度量是有成本的，而且成本可能相當高。包括：
設計度量指標和評審指標的成本。別忘了，度量涉及專案越廣，參與評審互動的人就越多，成本也就越高。
準確人工填寫或者自動化實現採集指標的成本。
被度量的團隊規模可能很大，相關的培訓宣導、檢查、分析、彙報的成本可能會很高。
正因為被捲入的人很多，涉及到各團隊的職責考察，如果度量指標容易誤解，還會帶來一系列的解釋和爭論成本。
誤區二，度量是 QA 部門的事，其他角色配合提供資料就好。
基於敏捷原則，質量度量不是專屬 QA 的職責，而是專案全員的職責。
曾經有測試團隊希望招聘一個專職的初級 QA，接手大量缺陷的具體分析，輸出改進計劃，這樣測試人員就可以專心做測試任務了。本質上，這是違背質量內建要義的。產生該缺陷的開發人員以及發現該缺陷的測試同學，是最應該從缺陷剖析中受益的，感受也最深，而不是接受外部新手的事後分析觀點。其他度量指標場景也是類似道理。
專案成員如果堅持認為度量動作和自己無關，必然導致質量改進的措施難以落地。
誤區三，度量通常會關聯處罰。
上篇聊聊傳統質量觀 VS 敏捷質量觀也提到，度量應該就事論事，提醒當事人深入分析，有則改之，不應該直接得出對人的批評結論。如果一說度量就聯想到處罰，會帶來大家消極對待度量，並掩飾不良資料的後果。
誤區四，既要傳統的質量度量體系，也要實施敏捷度量。
傳統的嚴格管控型度量體系，會產生越來越多的考核指標，但是很多指標並不能鼓勵敏捷提效。有些團隊因為被傳統度量考核的負擔壓制久了，失去了挖掘新的減負 “指示器” 的勇氣。
既然我們決定輕裝上陣，那應當暫時放下習以為常的指標，重新思考哪些指標是真正能促進產品儘早的、小批次的交付給使用者的。度量不是工作的目標，而是指引工作如何改進的指南。
推廣敏捷度量方案的關注點
即使指標體系本身沒有什麼問題，在行業中已經有成熟應用，我們在新團隊實踐中仍然要多加小心，以免踩坑，比如下面這些在鵝廠踩過的坑：
一，Leader 要自己主導度量分析和改進，要清楚知道指標不佳的原因，要思考長效管理改進的辦法。
不要僅僅把指標問題透傳給下屬，縱容下屬簡單粗暴地 “卷考核指標”，這是不可持續的虛假繁榮，可能會讓希望單純埋頭工作的人才流失。
二，每個業務研發部門都有自己的業務特性和團隊特性，不要急著把一大批指標和改進要求推到所有研發部門，而是針對差異點和現狀進行分析，選擇合理的過渡適應方案。
比如，金融業務和電商業務有不少差異，重服務端團隊和重客戶端團隊又有不少差異，有的團隊有繁重的 UAT 簽字流程，有的團隊可以自主釋出版本。一切從團隊的實際苦惱出發。
三，不要增加一線員工的手工填寫度量資訊的認知負擔，這需要大量的細節思考。每個關聯指標，是完全的系統無感知獲取，還是依賴人工填寫欄位的二次處理；如果是後者，填寫的選項該怎麼設計？這就需要金字塔拆分的技巧了。
鼎叔的經驗是：每個人工選擇的下拉欄位，選擇值不要超過十個，最好是 3-6 個，這些選擇項既覆蓋完整（不遺漏主要型別），又正交（不會重疊）。
如果一級欄位填寫，得到的分類還是太粗，可以設計為二級填寫。
有一些選項值可能太長尾 - 即種類零碎且實際佔比很低，那我們可能要用 “其他” 來歸類，或暫時放棄它們，我們可以從過往統計資料中看到哪些選項屬於長尾。
太多長尾值，對於公司的度量分析體系設計沒有明顯的好處，一線團隊可以將來自行分析。
四，給一線 leader 及團隊做度量指標講解，說說度量指標背後的思考，欄位的定義和作用解讀，填寫時的應注意事項。
更重要的是，探討質效指標如何助力業務研發團隊的年度目標達成？這裡埋藏著公共效能團隊和業務團隊的共建機會。
五，指標展示的透明度，對高層彙報時公正完整，辯證主義視角，不要報喜不報憂，面向團隊自主改進而非績效排名。