收到一位網(wǎng)友的E-mail，詢問如下的問題：

不少資料里面都提到"開發(fā)的度量結果不應成為獎懲的根本依據(jù)". 但我們實際的項目組在操作時，免不了會根據(jù)度量結果來評價一個開發(fā)人員的績效，例如SRS文檔的缺陷率有無達到質(zhì)量目標?等等. 也有的人支持根據(jù)有效的度量數(shù)據(jù)來考核開發(fā)人員的工作績效. 不知道你是怎么看這個問題的?

遂總結了一下自己的理解：
"開發(fā)的度量結果不應作為獎懲的根本依據(jù)"的根本原因在于"質(zhì)量天生具有的不確定性"。因此，沒有人可以肯定開發(fā)過程中達到了質(zhì)量目標（如SRS缺陷發(fā)現(xiàn)缺陷率）軟件的質(zhì)量會好。

如果僅以過程中的質(zhì)量目標達成情況來衡量開發(fā)人員的績效是片面的，會抹殺一部分責任心很強員工的積極性，比如一位員工，不管是SRS、HLD、CODE、UT等等在檢視或測試的過程中發(fā)現(xiàn)的缺陷都是少的，誰能說他的質(zhì)量不好或者績效不好，很有可能他是團隊中質(zhì)量好的一位。

過程中的度量，如SRS缺陷發(fā)現(xiàn)率的作用主要是用來牽引項目組在進度和質(zhì)量保證活動投入工作量（如檢視／單元測試等）中進行均衡，防止項目組盲目的追逐進度。如果某個模塊的質(zhì)量目標沒有達標，需要分析相應的檢視或測試活動的工作量投入情況，看看是否由于工作量投入不足引起的，對于工作量投入不足造成的情況，必須打回。

衡量項目成員績效還有很多其他的方法，其基本的原則應該是鼓勵員工對于質(zhì)量的責任心，如：

1、收集每位成員參與檢視活動發(fā)現(xiàn)的缺陷情況，進行相應的排名，鼓勵積極參與檢視活動

2、評比文檔或代碼檢視缺陷發(fā)現(xiàn)率少的模塊或個人（質(zhì)量好的那個），評比不建議直接看數(shù)據(jù)，因為對于一個尚未成熟的團隊大家在反饋檢視意見時有時存在比較隨意的情況，可以采用直接讓大家評比的方式。這樣做可以鼓勵大家在提交檢視時進行充分的自檢，而不是完成一個半成品甩給別人去幫忙查找錯誤。

3、或者更為簡潔或更有效的做法（我自己的做法）是要求項目經(jīng)理親自查看每篇文檔，自己評判，如果一個項目經(jīng)理沒有看過大家的文檔僅僅依靠質(zhì)量目標的達成情況來衡量大家的成績，是一種對團隊對質(zhì)量極不負責任的做法。不過要說服這樣的項目經(jīng)理剛開始有些困難，不妨一邊不停的在他耳邊說（好是有其他的的項目經(jīng)理作例子），一邊自己看項目組的文檔，拿出實際情況給他看，這樣做還有一個好處，是QA比PM更清楚項目組文檔或代碼的質(zhì)量狀況，在和更高級的領導一起交流時QA會比PM更顯得有理有據(jù)，久而久之這位對團隊質(zhì)量狀況以及成員都不了解的項目經(jīng)理自己都會慚愧的。 QA以旁觀者的身份和項目經(jīng)理一樣，有挖掘項目成員的義務。

4、將終結果（遺留缺陷密度）也納入進來，以結果為導向，任何人都沒有什么好說的。即使短期內(nèi)過程質(zhì)量目標沒達標的項目成員會受些委屈，但終他會得到肯定。

以上的幾點好一起用。

質(zhì)量好壞的終責任在于項目組本身，不是QA。

QA的目標始終有些悲哀，我理解的目標是：讓QA從項目組消亡。消亡不是被項目組趕走，而是樹立項目組自己的質(zhì)量意識以及相應的方法，在項目組達到不需要QA也可以自行良好的運作的時候，QA可以撤退了。所以，在一個好的項目組中作QA，遠不如在一個較差的項目組作QA，所學到的東西多。當整個開發(fā)組織的所有項目都不需要QA也可以良好運作的時候，我們QA可以考慮轉(zhuǎn)行了，呵呵，不過好像還比較遙遠！