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

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

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

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

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

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

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

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

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

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

以上的幾點好一起用。

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

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