收到一位網友的e-mail，詢問如下的問題：
」不少資料裡面都提到"開發的度量結果不應成為獎懲的根本依據". 但我們實際的專案組在操作時,免不了會根據度量結果來評價乙個開發人員的績效,例如srs文件的缺陷率有無達到質量目標?等等. 也有的人支援根據有效的度量資料來考核開發人員的工作績效. 不知道你是怎麼看這個問題的?「
遂總結了一下自己的理解：
"開發的度量結果不應作為獎懲的根本依據"的根本原因在於
"質量天生具有的不確定性"
。因此，沒有人可以肯定開發過程中達到了質量目標（如srs缺陷發現缺陷率）軟體的質量就會好。
如果僅以過程中的質量目標達成情況來衡量開發人員的績效是片面的
，會抹殺一部分責任心很強員工的積極性，比如一位員工
，不管是srs、hld、code、ut等等在檢視或測試的過程中
發現的缺陷都是最少的，誰能說他的質量不好或者績效不好
，很有可能他是團隊中質量最好的一位。
過程中的度量，如srs缺陷發現率的作用主要是用來牽引專案組在進度和質量保證活動投入工作量（如檢視／單元測試等）中進行均衡，防止專案組盲目的追逐進度。
如果某個模組的質量目標沒有達標，需要分析相應的檢視或測試活動的
工作量投入情況，看看是否由於工作量投入不足引起的
，對於工作量投入不足造成的情況，必須打回。
衡量專案成員績效還有很多其他的方法，其基本的原則應該是鼓勵員工
對於質量的責任心，如：
1、收集每位成員參與檢視活動發現的缺陷情況，進行相應的排名
，鼓勵積極參與檢視活動
2、評比文件或**檢視缺陷發現率最少的模組或個人（質量最好的那個）
，評比不建議直接看資料，因為對於乙個尚未成熟的團隊大家在反饋檢
視意見時有時存在比較隨意的情況，可以採用直接讓大家評比的方式
。這樣做可以鼓勵大家在提交檢視時進行充分的自檢
，而不是完成乙個半成品就甩給別人去幫忙查詢錯誤。
3、或者更為簡潔或更有效的做法（我自己的做法）是要求專案經理親
自檢視每篇文件，自己評判，如果乙個專案經理沒有看過大家的文件僅
僅依靠質量目標的達成情況來衡量大家的成績，是一種對團隊對質量極
不負責任的做法。不過要說服這樣的專案經理剛開始有些困難
，不妨一邊不停的在他耳邊說（最好是有其他的優秀的專案經理作例子
），一邊自己看專案組的文件，拿出實際情況給他看
，這樣做還有乙個好處，就是qa比pm更清楚專案組文件或**的質
量狀況，在和更高階的領導一起交流時qa會比pm更顯得有理有據
，久而久之這位對團隊質量狀況以及成員都不了解的專案經理自己都會
慚愧的。 qa以旁觀者的身份和專案經理一樣，有挖掘優秀專案成員的義務。
4、將最終結果（遺留缺陷密度）也納入進來，以結果為導向
，任何人都沒有什麼好說的。即使短期內過程質量目標沒達標的專案成員會受些委屈
，但最終他會得到肯定。
以上的幾點最好一起用。
***壞的最終責任在於專案組本身，不是qa。
qa的目標始終有些悲哀，我理解的終極目標是：讓qa從專案組消亡
。消亡不是被專案組趕走，而是樹立專案組自己的質量意識以及相應的
方法，在專案組達到不需要qa也可以自行良好的運作的時候
，qa就可以撤退了。所以，在乙個好的專案組中作qa
，遠不如在乙個較差的專案組作qa，所學到的東西多
。當整個開發組織的所有專案都不需要qa也可以良好運作的時候
，我們qa就可以考慮轉行了，呵呵，不過好像還比較遙遠！
研發過程中的質量度量
測試工程師，本質上就是產品的質量檢查員。我們把開發做好的產品拿過來進行檢測，從而發現問題，進而解決問題。作為測試，我們應該是比產品更懂技術，比開發更懂產品。測試人員，對於產品的業務邏輯，可能會比產品同學還要更為明白。這樣來說，測試對於產品質量的把控尤為重要。在測試中，從底層的白盒測試，再到ui層的黑...
專案開發過程中的幾個階段
1.evt engineering verification test 產品開發初期的設計驗證比如功能性測試等，通常這個階段的產品存在的問題還比較多。2.dvt design verification test 這通常是硬體生產中不可缺少的乙個檢測環節。3.dmt design maturity t...
專案開發過程中遇到的問題
問題分類 1 邏輯問題 結構 處理流程的設計有問題，尤其在多執行緒操作同乙個物件時 2 介面定義和使用問題 例如介面結構或返回情況改了，未及時編譯或更改其他模組的呼叫 3 對接問題 對講問題不是你的問題，就是我的問題，需要聯查 4 理解問題 對功能 邏輯流程或函式定義和使用的理解不清晰 5 異常處理...