現在問題來了，雖然他花費了心思去設計的流程。并對于需求部門和相關部門組織了培訓�？墒窃谶M行試點的時候，他發現，當他去評審需求分析組的工作時，別人很反感。而且對于有些需求的變革也推諉到銷售人員、客戶等因素。同時，流程中只要有一點不太合理的地方，就抱怨的很厲害。最后試點結束，他自己很累，試點的結果也不好，改善的目標沒有實現。整個過程的改進處于一種微妙的處境。最后，試點的流程并沒有推廣。其他的KPA過程改進也不再進行了，隨著時間的推移，過程改進在企業中也不在有人提起。知道這位開發組的主管錯在哪里嗎? 他選錯了KPA，他選了一個不屬于自己管轄范圍的KPA作為起點。他跑到一個不屬于他的地方開始指手畫腳，他是個不受歡迎的人。注定了，在一開始他就面對著對立和抱怨。這樣的團隊是無法經受一點點挫折和失敗的。若他一開始選擇配置管理，這個至于他管理范圍的KPA，他可以利用手中的權利、資源和威信，組織試點�？赡芮闆r就好的多。 又或者企業的高層給這個開發主管一個虛職，比如過程改進項目組組長，并任命其他組的組長為過程改進項目組成員。情況也會完全不同。
對于過程的改進要有度量。不必一開始就是數字化的，也可以是感性的體會。但要把這些也要收集起來。 一個有力的對比可以堵住反對者的嘴。不要因為度量管理是CMM4級的內容就在實施低級別的CMM時放棄度量。一套流程需要一系列度量的數據來說明它改進了多少。而度量的數據將會為它贏得預算和支持。當然度量作為CMM4級的內容，也是有一定的道理的。收集一套完備、準確的度量是需要大量人力的。但是在一開始，也許我們可以借助一些好的工具達到同樣的效果，而不必花費大量的時間和精力。在我就自己做過一個簡易的BUG管理工具，并和數據庫相連。在項目結束時我可以輕易的了解項目中有多少BUG、BUG分布如何，BUG的原因統計等度量數據。我只是用了幾個SQL語句就掌握了我需要的度量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/