CMMI是一個組織管理角度的模型，對象是工程組織，但該模型的重點其實不在於產出產品的品質，而是組織對於工程活動的管理能力。雖然，最早在建立的SW-CMM的時代裡，已經確認了產品的品質取決於產生該產品之過程的品質，但是，事實上，從以前到現在，沒有人打過包票，用SW-CMM一定可以做出「高品質」的產品，因為，所謂的「高品質」並沒有辦法由SW-CMM/CMMI裡的那些過程決定，那些過程充其量只是設法讓最終產品的品質，趨近於(最多就是符合)Stakeholder的需要與需求而已(有趣的是，如果產生之產品的品質，高於Stakeholder的需要與需求，其所代表的反而是專案失控、或者有人沒有盡到其職責。所謂沒有盡到職責，是對於專案預算的樽節、對需求的適切掌握、對專案的溝通或工作掌控而言)，當然，品質低於Stakeholder的需要與需求，那更不用說，是絕對的失控。所以，我們不能迷失在CMMI神話裡。

　　CMMI裡面要求的重點，實則不在於文件，而在於數據與資料，與管理有關的數據、資料與資訊。如果有人一直說文件很重要，那僅表示其對於CMMI的了解仍不夠深入。即便是談到文件，吾人應知道，文件實則由數據、資料與資訊所構成，而文件更可以根據Stakeholder的要求，組織數據、資料與資訊而產生，所以文件基本上並非CMMI中的重點，所以CMMI並不會要求整個模型運作起來的時候應該要有什麼文件。真正的重點在於數據、資料與資訊，CMMI希望組織用到數據、資料與資訊去進行組織管理、工程過程管理與工程產物的管理。CMMI所重視的，是過程所產生的數據、資料與資訊，從而可以看到過程執行的情況、產品的品質、並且預推未來最終產品的品質，然後，在適的時機採取必要的措施實施修正過程、修正產品。[所以CMMI中，最重要的工作其實在於量測與分析]

　　提供Templates給客戶，對於顧問而言，是一個痛苦，因為客戶沒有經驗，但有時間的壓力，對於CMMI的核心思想瞭解亦不夠透徹，因此，客戶的人員會希望顧問提供Templates，讓他們加速學習(也許實質上沒有，但他們認為有)，如果不提供，嘿嘿，他們就會向老闆報告：「他不是個稱職的顧問」或「這家顧問公司好像沒有什麼經驗，連一些範本都沒有」。當然有些顧問公司就是會提供一堆Templates，這些Templates可能顧問自己都還不太理解是怎麼回事，甚至於顧問本身對於CMMI核心精神還沒有掌控，就只是靠著提供Templates，解釋Templates打天下。

　　攤開CMMI，在1.2版裡有22個PA，這些PA只是在提示組織管理者(CEO、CIO、各部門經理)與專案組織的管理者(專案計畫主持人、專案經理)，組織的管理有哪些面向，有哪些重點。對於管理者而言，要透過這些與工作有關的過程領域，找到管理的重點(經由設計數據、資料與資訊的來源與蒐集的方法，實作這些數據、資料與資訊的蒐集工作)。所以，對於任何一個顧問而言，他不見得需要有全般的經驗，寫過每一種文件的經驗，但重要的是，他/她必須了解什麼是管理、要怎麼做管理、要如何設計過程、如何量測過程、如何解讀過程的實況、以及相應於所遭遇的問題，如何提出解決方法。

　　以上的說法，國內的一些顧問與CMMI LA及CMMI 講師可能不太認同，但是，從現在SEI中CMMI專案的走向來看，對High Maturity的評鑑要求已完全證實了這樣的觀點，而量測與分析又落於ML2中，所以不論從任何一個角度去看都是如此。只是組織的管理者應認清CMMI中，工程部分的PA到底想說的是什麼，它們絕對不是單純的生產軟體的過程而已，而是透過過程的說明，告知所有的管理者，工程的過程中發生什麼事情，該做什麼，會產生什麼，因此，身為管理者要懂得思考，如何透過量測與分析去洞察組織的流程與產品實況，並且預推未來的結論，從而採取進一步的作為。

　　所以，CMMI並不是一套工程方法，而是一套管理方法，這是吾人在面對此一模型時應注意到的事項。

----------------
引文:

看過泰龍兄的文章後，個人有些感想略述如後：

使用CMMI-DEV的組織，
1. 如果，對『過程品質與產品品質之間的關係』不甚瞭解，或者不相信『改善過程品質，就長期而言，可以改善產品品質』這一概念。那麼，其引用此一模型可能是有問題的。

2. 如果，不瞭解造成產品品質不良的根本問題是：牽涉於產品全壽期(從概念的形成，經由開發、交付、維護到汰除)中所有Stakeholder溝通不良的問題。那麼，也就不會瞭解CMMI中的數據、資料、資訊與文件的類別與用處，那又遑論使用及裁適它們。

3. 如果，對以上的問題没有正確的理解，那麼就怎會知道，如何在專案中依客戶的需要(意即產品及其屬性)裁適各種Templates，如何依組織(個別專案或整體組織)的能力成熟度、組織的複雜度(意即專案分工方式)以及已裁適過的Templates裁適各個過程。

4. 如果，不知道如何將Templates轉換成專案中的WBS，或者如何將WBS投入採用的過程訂出『專案時程網圖』。那麼，所有的Templates與過程都是無用的。

5. 如果，沒有將選用的Templates與過程於專案中落實。那麼，怎能說“該組織有使用CMMI-DEV？”或者說“CMMI-DEV對他們有何意義？”

6. 又，如果不知道如何在當下的專案中累積經驗，又如何於未來持續改善？不持續改善，那麼使用CMMI-DEV的目的又何在？

願與大家分享這一點點的感想，更願大家早日 走在正確的路上！

周茂松 敬上