【資訊傳真】延續九十三年十月號的話題，於十一月號繼續刊載了「誰讓CMMI變成膏藥？--台灣軟體工業已沒有虛耗的本錢了」ㄧ文，對於該文作者本身的出發點，筆者深感認同，但其部分的切入點與觀點，筆者想藉這個機會想提出自己的一點看法。　

基本上CMMI並不是軟體開發的工具或生命週期過程模型，它不是產品發展過程，也不是過程的描述，而是過程改善的架構，這是核心要旨，讀者如果有疑問，可以發電子郵件請教SEI中CMMI專案的專案經理Mike Phillips，就可以得到相同的答案。但是仍有些推動CMMI的專家顧問常誤導大家認為「CMMI是軟體發展的過程標準」，甚至於，將之與相關的過程標準文件做錯誤的「比較」，這都是讓CMMI變成膏藥的原因之一。當然幾種產品發展生命週期過程標準與CMMI的對映( Mapping，請注意，不是「比較」，而是「對映」)，都可以在網站上找到，而SEI對於這類的Mapping都非常謹慎地說明Mapping的角度，以及讀者在使用這類模型對映時應有的態度及可能的風險。　

有些人一直以為CMMI只適用在大型組織、政府採購及國防工程上，對於國內資訊產業都是中、小型公司環境是不相匹配的，甚至也有許多人把CMMI跟軟體代工劃上等號，認為想做軟體代工的廠商才需要導入CMMI。基本上，這些觀點都與CMMI的本意大相逕庭。那麼，要實作CMMI，需要多大的專案或多大的組織呢？讓我們回到CMMI的技術報告吧，看看技術報告怎麼說。根據CMMI-SE/SW/IPPD/SS V1.1 (CMU/SEI-2002-TR-012)中P. 76至77，有關於裁適的部分：

Model Tailoring for Smaller Projects

The CMMI models were written for use by all types of organizations; however, for small organizations a CMMI model must be interpreted. In the case of small, three- to six-month projects, a high-level plan is typically available that has been developed for a group of projects. This high-level plan defines the organization, resources, training, management participation, and quality assurance reporting descriptions for all projects. [FM120.HDA104.HDB104.T101]

(CMMI模型是以能夠讓各種類型式組織都可以使用的方式寫作的，而，對於小型組織而言CMMI模型是需要經過轉換的。對於小型，三到六個月的專案，通常有一份為一群專案所寫的高階計畫就可以了….)

Conversely, in the project plan, the detailed planning of the project, such as the schedule, tasks, and resources, are defined. Often the project plan also contains plans for other supporting functions, such as quality assurance and configuration management. A four-person project might expect to develop a project plan that is only a few pages long. [FM120.HDA104.HDB104.T102]

(對於四個人的小型專案，所訂的專案計畫可能僅數頁而已)

In small projects, meetings take place more frequently, take less time, and cover more details. The schedule may contain daily activities, and may be monitored in weekly meetings. The schedule may change weekly and be controlled. [FM120.HDA104.HDB104.T104]

在小型專案中，會議會採取高頻率但是時間短，且涵蓋更多細節的方式實施。

由此觀之，CMMI Framework是可以適用在，小規模專案團隊或專案的，只是在小規模專案團隊或專案中運用，以實現CMMI Framework所要求的常規時，管理者應對CMMI Framework有深入的理解，具備能夠裁適出適用在小型專案所需專案過程的能力，否則，盲目導入、採用CMMI，是無法為組織帶來效益的，尤其是會耗費許多時間成本的工作，例如，寫文件、開會、稽核、審查等，是需要視狀況而調整的，因此組織的管理者要有一定的Insight，知道哪些工作在裁適後要做到何種程度，以使工作能夠更加Cost-effective。

不論是發展哪一類型的軟體，就算軟體需求是發展者天馬行空想出來的也好，為了需求的前後一致，可以維護，可以確定都被展開、並且實現在產品中，還是需要有一套需求管理的機制、軟體工程的方法，這對於任何想產出品質符合要求的軟體產品的軟體公司是不能省略的，另外，如果沒有規劃的機制去展出這些天馬行空的需求(創意)，又如何能做出開發成本與時程的估算、了解技術的瓶頸所在、有哪些風險，什麼時間該做收尾的動作，讓產品可以按計畫上市？當然，也需要一套有效的控管機制，以隨時了解產品發展的進度、可能的問題、以及能否趕上計劃上市時間。

導入CMMI能否解決所有的問題？當然不能，但其問題不在於政府部門要採取什麼的手段，或者顧問採用什麼方式行銷自己的做法，因為，在現實中，總是上有政策而下有對策，無論政府部門如何要求，就算是要求廠商要通過CMMI ML3以上的評鑑才能參與政府的大型標案也是如此。然而，採取這種方式來揠苗助長，只能為一些專門迎合只為通過評鑑而導入CMMI的公司之需求的CMMI掮客帶來商機而已，對於國家總體資訊產業競爭力是沒有幫助的。筆者一直以來都說同樣的話，但還是要再次強調的是：「CMMI是一套組織管理過程改善的方法」，其能否成功，並為組織帶來好處，其實端看組織內部高階管理者的心態，以及對於組織過程改善的決心與支持程度而定，他是否願意提供資源及承諾，以及能不能在極度的壓力下(這類壓力包括組織變革的抗拒、導入初期影響到正常業務遂行時，可能造成的時程延誤、成本增加，影響到營收等等)，還能夠著眼於組織的永續發展，堅持到將制度建立起來為止。另外，在導入之後仍能定期地審查管理制度的推展狀況，並有效地評量績效，方能維持組織高度的軟體品質戰力。

當然，國內軟體品質顧問服務業者中，以引導組織正確導入CMMI，使客戶轉化為以過程改善為常態的學習型組織為己任的公司的亦所在多有，他們非常執著於確認組織導入CMMI的目的，應是養成持續改善追求卓越的文化，而不在於通過某一等級的評鑑而已，我想這類公司與組織不應該被歸納為「賣CMMI膏藥的江湖術士」吧，當然也就沒有讓CMMI變成膏藥的問題了。

但話又說回來，是誰讓國內的軟體工業淪落的？其實這是個整體性的問題，要提振我國的軟體工業，政府該制訂相關作法是必然的，但是政府部門行事，是會設法規避一些疑慮的，這是因為要接受民意機關、監察單位監督與稽核的關係，例如：官商勾結、圖利廠商，都是超大型的帽子，致使購辦單位要以價格來評選廠商，甚至於，有些購案辦理的單位還會以「壓低價格，控留多少標餘款」來當作績效目標，一來可免除圖利廠商之嫌，二來也為單位中，其他想做又沒有即時預算的購案擠出錢來，何樂而不為。在這種狀況下當然會使得軟體工業淪落，因為標案第一波的價格戰，廠商已經被挖了好幾塊肉出來，在簽約之後，還要讓業主運用各種手段再挖出一些血肉來( 送東送西，或原來合約沒有的，拼命不斷地要求 )，而時程訂定又不合理，於是基於成本考量、時程的要求，或是相忍為求後續的合作機會，廠商在幾經評估，認為影響不大，或者可以承受的風險部分，就省略不做，當然就使得產出的品質變差了。而在不做的同時，其實也在流失一些 Practice，因為，久而久之，好的常規就無法傳承，既有的制度如同廢物一般( 神聖的廢物！我在軍中的一位同袍是這麼形容的 )束諸高閣，任由塵封。就算是通過CMMI評鑑的公司，處在這種環境之下，相信很快也是步上相同的後塵，一路淪落。因此，比較好的方式，應該是檢討購案辦理的制度，政府與民意機關應共同研訂每個政府部門資訊服務委外專案，廠商的合理利潤為何，例如，全案金額的10%或更高，另外也要要求政府部門做好購案的規劃，他們可以參考美方的做法，在政府及軍方部門的購案上，其需求單位或採購單位應完成至少三層的計畫WBS，編列合理的預算及工作時程，否則即便是採取所謂「固定價格最有利標」也是一樣，收支不成比例的購案，做到最後還是無法達到品質的要求的，甚至於做一個案子賠一個案子。對於通過CMMI ML3評鑑的公司，先前導入CMMI的成本尚無法回收，更別提能在吞下一個個賠本的案子之後，仍有餘力永續經營，永續改善了。再者政府與軍方部門的採購單位，亦應同時具備專案規劃與管理的能力，否則就該將這個部分的工作，委辦給公正第三者實施專案的監督審驗，如此不但可以提升廠商的軟體過程能力，也做好了專案監督審驗的工作，同時也扶持了軟體專案的審驗產業。相信這會是比較好的解決方法。

CMMI Framework不應該被誤解，它是不折不扣的組織(軟體)過程改善的管理工具，這個Framework的應用處所，並不限於軟體組織，也不會因為產製的是數位內容、遊戲、客製化軟體或COTS產品而脫離它的範疇，因為這個Framework中所含的是一些工程及工程管理上的Best Practices，適度且有效地採用，對於產品品質有加乘的作用，對於組織也可收到追求卓越及永續成長的效果。軟體組織應該要有的正確認識乃是，CMMI 的評鑑是一種對於軟體組織在過程改善上的付出的肯定，也是對組織已建立起軟體過程改善能力更上層樓之基礎的肯定。

最後，筆者認為，政府部門在此應該要有所覺醒了，與其去要求廠商須通過CMMI ML3的評鑑方能參與政府標案，不如修訂相關的政策，以創造良好的競爭環境(比誰的品質好，而不是比誰的價格低)，讓業者願意建立起良好的工程常規與制度，並且不斷持續改善、追求卓越( Optimizing )，讓CMMI Framework在組織中自然而然地生根、茁壯。

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