V公司和競爭對手相比，在技術上并不占有優勢，于是V公司采用了“快速響應”的策略。無論是面對瞬息的市場，還是多變的用戶需求。V公司總能夠搶先于競爭對手推出產品，為此受到了市場的肯定。但是V公司在實施CMM的時候，卻錯誤地選擇了“瀑布式”的開發模型，加上相對復雜的實施流程，如果研發體系嚴格按照要求去做，那么對市場的響應速度必然大大降低，企業的核心競爭力受到威脅。但是如果H公司堅定“快速響應”的策略，現有CMM的實施就無法有效進行。V 企業走入兩難的境地。
V企業實施CMM并沒有錯，錯的是他們在實施CMM的時候并沒有考慮到企業的核心競爭力和總體戰略，采用了錯誤的生命周期模型和相對復雜的實施流程，最后導致了這樣的結果。
對公司的戰略影響是一個方面，另外一個方面是，CMM的實施涉及到機構的重組，如果我們不能在組織架構，薪酬待遇，績效考核等方面輔助以適當的政策的話，CMM的實施不可能順利進行。
案例2:
W公司為了推行CMM，組建了獨立的QA部門。盡管在W公司的內部宣傳材料上對QA的作用進行了大肆的宣傳，認為其對于CMM的推行和項目管理都具有重要作用，但是實際上QA人員的資歷都相對較淺，對開發過程，技術和工具都缺乏必要的了解。只能夠照搬一些條文來要求開發人員，開發人員對此并不認賬，認為 QA人員是沒事找事。另外，QA這個崗位在薪酬和升遷方面毫不吸引人。
為了避免QA部門成為新手和項目組淘汰人員的集中地，QA部門經理設法推行項目經理鍛煉制度，讓項目經理到QA部門鍛煉一段時間，然后繼續擔任項目經理或者升遷。但是因為此項制度沒有得到有效的支持，項目經理在QA部門工作一段時間以后竟然沒有開發部門愿意接收，就更談不上升遷了。QA部門在W公司的威望江河日下。
QA人員對于質量保證和CMM的實施至關重要，如果我們認可QA人員對于公司的價值，那就必須在人才和待遇上向QA部門傾斜。
案例3:
S公司在推行CMM 2級的時候遇到了極大的阻力，項目經理對估計和計劃過程根本不感興趣。其原因在于S公司有“倒排計劃”的習慣做法。
項目經理對項目的進度安排沒有決定權，當項目經理接受任務的時候，項目的發布日期早已確定，而且項目經理做出的人力資源請求一般也不會得到滿足，項目經理被迫在一個資源短缺的環境下開展工作。既然Deadline已經確定，增加人手又不可能，項目經理怎么會對估計和計劃有興趣呢?
與此相對應，S公司的內部宣傳材料在不斷地表彰在資源短缺的困難情形下做出成績的經理和開發人員，對“無原則服從命令”行為的贊許，已經成為了公司文化根深蒂固的一部分，并且得到管理層的默許和鼓勵。
S公司的文化和CMM的要求是抵觸的。CMM要求項目經理對任務的合理性進行分析，要求在理性的基礎上做出判斷，而不是盲目地服從。如果S公司不能夠改變他們的文化，CMM就不能夠得到有效實施。
案例4:
A公司是一個小型公司，但卻采用了一個步驟繁瑣的CMM實施方案，而且沒有采用任何自動化的過程工具，大部分由紙面文件傳遞來進行。比如在測試中如果發現了一個問題，必須由測試人員找到文件模版，填寫好缺陷的種類和描述，打印出來，交給相關人員簽字，開發人員的修改結果就只好填寫在紙面上，最后還要找項目經理簽字。相關人員浪費在文件傳遞上的時間可能比進行開發和測試的時間還要長。
以CMM為模型制訂管理框架，其本質是為了規范管理，減少錯誤的發生。而執行這些管理規程，就其本身而言，并不是我們的目的，而僅僅是一種手段。對這些規程的執行也不創造任何價值。在條件許可的情況下，我們要盡可能地簡化手續，提高效率。并適當地引入自動化工具。像A公司的情況，用一個缺陷追蹤工具就可以大幅度地提高效率。
案例5:
H公司和Z公司都在研發相同類型的C產品。H公司在推廣CMM，采用了相對嚴格的過程規范，并且把相對重要的部分外包給了印度的CMM5級公司。這些手段Z公司都沒有采用，但是Z公司卻搶在了前面。
Z公司的“秘密武器”是一種形式化語言—SDL，Z公司采用SDL作為設計工具，這樣C產品的相當一部分代碼可以由SDL工具自動生成，而且在設計階段就可以進行仿真運行，這樣就大大地提高了效率并減少了缺陷。H公司雖然采用了相對嚴格的過程規范，但是因為全部代碼為手工編制，所以，無論是效率還是質量， H公司都落后了。
H公司顯然忽視了先進技術可能為生產率帶來的進步，通過了CMM高級別的評估，只能說明被評估的組織機構在過程控制上做得更加細致，但是并不能夠保證你的開發過程是高效的。某些沉迷于CMM的組織機構忘記了先進的軟件工程技術的重要性。
案例6:
H公司的B項目是一個龐大的項目組，技術相當復雜。名詞術語很多，而且對于同一件事物的表達方式也不盡相同。項目組非常有必要制定一個規范的術語表，既統一了說法，也方便項目組的新人查閱。但是事情的發展是很有戲劇性的。
項目組在起初并沒有重視術語表的編制，因為人少，產生的文檔也不多，所以這件事情無人重視。但是到了項目進展了1/3左右，術語的混亂已經相當嚴重的時候。B項目組的一個工程師X自發地開發了一個小程序，用于查閱術語的名稱和縮寫。項目經理對X工程師的做法提出了表揚，并委任X開發和維護這個標準術語表。
項目經理和相關部門的始終沒有意識到：(1)開發和維護這樣的標準術語表是項目經理和配置管理人員的職責，不是某一個軟件工程師的任務。(2)類似的問題在別的項目組一定出現過，以后的項目組一定也會遇到，必須在開發規范上堵住這個漏洞，讓別的項目不會重蹈覆轍。
所謂的“管理無大事”，過程管理的真諦就在于這些看似細節的小事�；镜倪^程管理原則和規范只是“骨架”，而“血肉”是要靠這些看似細枝末節的小事來豐滿的。積沙成塔，集腋成裘，點滴持續地改進，其效果最終是巨大的。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
