度量信息需求
很多人錯誤地認為：度量項的多寡取決于CMMI的級別，比如4級就應該比2級多很多。其實不然，度量項的多少取決于我們有多少問題是向數據要答案的。先來看看我們有幾類問題，或者說度量信息需求。下面有一個簡單的結構：
項目外部問題
客戶滿意度問題
企業運營問題
項目內部問題
計劃問題(前期)
監控問題(中、后期)
反思問題(結束后)
多數企業高層愿意把項目當作一個黑盒，也就是不愿意詢問內部的事，但對外部影響還是非常關心的。比如高層會關心下面前2個問題，而不關心后2個問題：(一個不完整的例子)
客戶對這個項目的質量滿意嗎?(客戶滿意度)
這個項目賺錢嗎?(企業運營)
項目的不同缺陷各有多少(缺陷分類計數)?
項目成員每天在干什么(活動分類統計)?
很可惜，多數項目從來不度量前兩個問題，所以高層不能從度量中得到這兩個問題的答案，也就不會深入參與度量利益鏈條。
而項目經理，他們被迫地參與了度量過程，也提供了后兩個問題的數值，但卻不知道為什么要問這兩個問題。另外缺少高層的過問，這兩個數值最后如石沉大海，只有若干月后聽說在CMMI評估中被列為強項。
所以很多企業的度量體系運行在一種不健康的狀態：Sponsor不關心，主要執行人也不關心。注意他們只是對度量不關心而已，沒有人會對上述結構中的5類問題不關心。高層和項目經理經常開會討論這些問題，雖然很難達成一致認識。
保護“壞人”
上面提到的在度量中無法得到利益與在度量中失去利益相比，還算好的。后者將催生“壞人”。
好的度量結構和定義使企業團結如一人，共同對外。關鍵只有一點：面向客戶滿意度進行度量。
與其定義內部的缺陷數據，不如定義外部的，比如：在交付后半年內，每千行代碼的缺陷率(甚至非常主觀的：投訴次數)�？蛻羰遣豢煽刂频囊蛩�，永遠不會“變壞”來造假數據。而且他們是項目的支付者，如果一個項目的質量好到讓客戶滿意，也就足夠了。
當遇到質量差的項目時，互相推諉是沒用的，無論責任是測試組測試不充分，還是開發組的產品質量天生太差，結果都是相同的：大家績效考核得分都低。所以大家惟有一起坐下來分析一下：到底為什么質量差?雖然要達到暢所欲言的地步可能還差點，但是大家已經傾向于發現和報告真相，以改善績效。
另一個問題：只面向客戶滿意度度量嗎?其他的度量項是為什么提出來的?
幫助“笨人”“懶人”
質量差的原因很多，比如：
測試不充分(覆蓋不足、工作量不足、測試重點不對……)
產品本身很差(編碼缺陷很多、設計缺陷很多、需求缺陷很多……)
工期太緊，沒時間測試、做設計、做需求……
新人太多，又沒人指導
靠拍腦袋可以定位一些問題原因，但這些推論過程很可能不為人所接受，更可能被人駁倒。雖然大家都在一條船上受苦，但站出來承認讓船擱淺的人是自己，無疑還是很難的一件事。如果大家都是“笨人”“懶人”，只能坐等而無所做為。
這時候你需要一些數據來做判斷和決策。太多的問題，太多的數據，中間的對應關系可能是相當復雜的。忙亂中的項目組很可能根本沒有喘息的機會來研究，是EPG大展身手的時候了。
還好現在已經有相當多的書籍、專題與此相關，很多咨詢機構也提供度量體系建設的服務。相信“笨人”“懶人”們聽說你是來幫助他們提高績效的，應該不會無動于衷。所以我們不是一個人在戰斗。
文章來源于領測軟件測試網 http://www.kjueaiud.com/