在基于CMM實施軟件過程改善時，有些根本的思想認識問題解決不了，往往會使實施的周期比較長，效果不好，甚至導致過程改善的失敗或中止。軟件企業的高層領導、企業的過程改善主管、銷售人員、項目經理及一般的開發人員都需要對這些問題統一認識，在此基礎上才能消除各方面的阻力，把握好過程改善的方向，控制好過程改善的進度。筆者在總結了3年的實施CMM的經驗教訓后，歸納了如下幾個思想認識問題，供擬準備進行過程改善或正在進行過程改善的軟件企業同行參考： CMM不是萬能的，只有CMM是不行的，還要技術(開發方法、工具)人員二個要素一起改善
在軟件工程發展的歷史進程中，人們為了解決軟件危機，嘗試了采用諸如形式化描述語言、結構化開發方法、CASE工具、構件化開發方法等等各種解決方案，但是效果并不那么顯著，CMU SEI提出了軟件過程能力成熟度模型（CMM）基于過程的角度來解決軟件危機。那么是否實施了CMM，軟件企業的開發能力就一定能提高，一定能帶來經濟效益呢？答案是否定的。如果企業里要帶來經濟效益必須要結合軟件過程、工具、開發方法、人員等多種因素一起提高，才能保證帶來經濟效益，因為人員、技術和過程是支撐軟件開發平臺的三條腿，少了那一條都不行。大家也都知道木桶原理，一個木桶可存櫧水的最大容量是由最短的那根木頭決定的。在企業的開發能力中過程、技術(含工具、方法)、人員都是主要的因子，都需要全面提高，只關注一個方面，而忽略了其他方面，都是有害的。
在開始實施CMM時，最容易犯的一個錯誤就是"唯管理論"或孤立地只抓過程改善，忽略了開發技術與人員的提高，過分強調管理的作用，實施了半年或一年后，發現企業的生產能力并沒有得到明顯的改善，這時反對的聲音就會成為主流，過程改善就難以繼續進行了。有的企業采用面向對象的開發方法進行軟件開發，但是企業內并沒有對面向對象技術真正了解的專家，雖然也采用RUP過程、也采用ROSE等開發工具，但是僅僅是形似，沒有做到真正的OO方法，沒有得到OO方法的精髓，這種問題僅僅依靠過程改善是無法解決的。還有的企業開發人員的積極性很差，工作熱情很低，企業的激勵機制沒有起到很好的作用，這種問題也是依靠CMM無法解決的。
管理就是預防，管理的作用是隱性的，不都是立竿見影的，大家要有耐心
在實施CMM時，企業的管理層在開始時往往會對過程改善期望值太高，希望短時間內效果顯著，上面我們談到了，效果顯著與否不是由一個方面的要素決定的，需要多個因素共同改善。而管理的最大作用是預防，防患于未然。
任何的管理的改善都是符合J曲線的，即在改善的初期企業的運行效率可能會下降，甚至可能會出現一些混亂的局面，不過渡過了這段時間就會看到效果。所以在改善的初期大家要有這個思想準備，要有耐心。
堅持活學活用，以我為主
機械照搬CMM的條文是在實施CMM時常犯的錯誤。在國內的軟件企業中，都是從作坊式的軟件組織逐步發展過來的，也沒有經過軟件工程化階段，甚至也沒有什么標準、規范。真正超過10年軟件工程經驗的人員更是比較少的，加上大家不愿從事管理，因而有的企業所組建SEPG的人員中可能在工程經驗方面是有欠缺的，又沒有真正的有實踐經驗的專家進行指導，所以對CMM的理解就不可能一下就很深刻，不敢裁剪CMM，容易機械照搬CMM條文，其實這恰恰違背了CMM的精神，CMM是軟件工程經驗的集大成，是從實踐中總結出來，用以指導實踐的，CMM本身也在更新版本，不斷完善。每個企業都有自己的特點，就象微軟的MSF，那是微軟自己內部的管理過程標準，是微軟的產品開發經驗總結，有些內容是CMM中沒有的，完全可以借鑒過來使用，所以只要可以提高企業自己的軟件管理水平，就應該大膽地來嘗試。
在推行CMM時，所以遇到的阻力，很大程度上是由于照搬CMM的條文，不切合項目組的實際，沒有具體情況具體分析。實際上，一線的管理人員、開發人員最了解實際。誰了解實際，誰有發言權。所以在制定CMM規程標準時，尤其是在制定大家要執行的操作規程、模板和記錄表樣時，一定要得到執行者的認同，否則就容易造成執行和溝通的障礙，你硬要推，表面上看來似乎大伙也照規程做了，其實是表面文章，對改善沒有實際幫助，以導致SPI工作受阻。
要改良式不要革命式
以革命的方式來實施CMM，期望通過一場運動來解決過程能力的問題，一種可能是不懂CMM，不曉得管理的改進是循序漸進的，一種可能是明知故犯，期望在短期內通過CMM評估，單純追求市場上的轟動效應。有的企業在短時間內雖通過了CMM幾級評估，我想恐怕由于沒有實效而得不到大家的認同而難以將這種"水平"持續下去。一個企業引入CMM之后會從本質上影響企業的文化，改變大家的思想與做事方法。有人曾形象得將過程改進比喻為減肥，你是可以依靠減肥藥在短時間內減輕體重，但如果不從根本上改善飲食、生活、運動的習慣，那么體重將會在短時間內恢復到原來，我認為這個比喻是十分形象的。
革命的方式與改良的方式我都曾經嘗試過，效果差異很大。所以我總結一條就是讓大家在"小步快跑"中接受變革，這樣風險最小，效果最好。
CMM與企業的創新文化是不矛盾的
軟件企業的有些管理人員，也包括一些開發人員往往抱怨或認為嚴格的管理會束縛他們的創新，他們認為在CMM中提倡的一種按部就班，什么活動都要做計劃、按規程標準來做，對企業的創新文化會起負面作用。在我遇到的開發人員中，越是技術鉆研越深的人持這種觀點的越多。我想形成這種觀點主要有二個原因：一是企業在推行CMM時，過分機械，沒有從實際出發，不能與實踐緊密結合，挫傷了開發人員的積極性。比如說在分析與設計階段，需要開發人員能夠發揮創意的成分更大一些，如果你要求他們一定就要按統一的文檔標準來寫文檔，甚至字號大小、縮進格式一點也不能差，這的確很難做到，可能你需要在項目組配備文檔支持人員，有他們來做這些完善工作，降低分析與設計人員的這些工作量。二是這類人員缺少真正的軟件工程經驗，做的大項目太少，經歷的失敗太少。關于這一點是不要爭論的，CMM是軟件工程經驗與教訓的集大成，我們無需再去重復那些失敗。
軟件企業必須形成創新的文化，事實CMM本身也一種軟件工程管理的創新，而技術創新是必須進行管理才能使其有效地轉化為生產力，轉化為企業的實際效益，達到效益最大化，這是最根本的。
要勇于實踐，也要允許犯錯誤
CMM就是軟件工程經驗與教訓的總結。在實施CMM的過程中，肯定會走些彎路，甚至于要犯錯誤，由此許多人會議論紛紛，一直會反映到高層經理處，這時不要猶豫，要敢于嘗試，更不能因為有困難就打退堂鼓，現在大家都是"摸著石頭過河"，不下水，是沒有辦法過河的，臨淵慕魚不如退而結網。要少說不，少說難，勇于實踐，有錯就改。對于軟件企業的領導尤其要注意這一點，不要因為在過程中的一些實踐失敗，就對項目經理、SEPG等人員有偏見，要提倡這種文化。
管理過程改進是組織內所有人的事情，而并非僅僅是SEPG的事情
按照CMM專家的建議，在一個組織內專職從事軟件過程改善的人數應為組織總人數的2-3%，根據這一建議，我們企業內一開始就配備專職的軟件工程過程組（SEPG），這些員工專職負責企業的軟件過程改善工作，另外我們根據需要組織一些技術任務組（TWG），他們會兼職的參與特定過程規程、標準的制定、試點和修改完善工作。在這種情況，可能會出現如下的問題：
SEPG成了最忙的人，TWG的任務往往會由于那些兼職的人員以工作忙為理由一拖再拖，最后還是由SEPG的成員替代TWG做工作；
企業的非開發人員對管理過程改進的效果一下沒有明確地感受到，甚至看到由于加了些新的活動可能使項目拖期可能會更嚴重，于是他們可能就會將這些抱怨反饋到企業的高層經理，在推行過程中經常會聽到：我這個項目時間太緊，當前不適合使用CMM；
高層經理迫于市場的壓力，甚至可能會提出不合實際的項目工期等等。
推行CMM不僅僅是管理人員的事情，每個人都要積極參與。要改變原來的一些做法：即SEPG是在使勁的推進CMM的工作，而不是大家自覺自愿的來實施CMM。從SEPG的角度來看，要做好培訓的工作，首先要解決的大家的思想認識問題，這還是比較難的，有些人的思想還是比較頑固的。
以上是我對前幾年推行CMM的過程遇到的思想認識問題的總結，不一定準確，希望各位同行指正。當然管理首先要解決的是思想認識上的問題，不但在主觀上要解決，在客觀上也要有措施，光說不練是不行的，光練不說也是要否定的。我曾經遇到過類似的問題，有的開發人員或者項目經理在口頭上是可以接受變革的，會配合工作的，但是在具體操作，很可能又會遇到事實上的否定，這時作為CMM的推廣人員要盡快提出實施的具體措施，盡快落實。任何變革都要涉及到企業內的權利的再分配，不要忽視企業政治，這是客觀存在的，所以一定要預防那些光說不練者。
文章來源于領測軟件測試網 http://www.kjueaiud.com/