我是IT業的新兵，受副總之命參與推動CMMI，但我連需求與設計有何差別都無法釐清，就要幫公司作流程改善，這就是第一個笑話。不過後來知道副總的指導方針是CMMI歸CMMI與公司的專案無關，CMMI只是公司的專案之一，這就是第二個笑話。

情急下我只好找朋友幫忙（他們通過了CMMI Level-3），他告訴我以下的真實故事（這就是第三、四、五、六個笑話）。

他們公司有承包高鐵的軟體，需求規格訂定有軟體可靠度需求（軟體可靠度需求我就不懂了，我的朋友參與這個案子，他也不懂但直接就寫程式了），計劃執行了一年半左右且已經進入了Coding階段，有一天顧問告訴PM再不趕快補救軟體可靠度的問題，以後問題會更嚴重，聽說PM當時也不知道在需求文件當中竟然有軟體可靠度的項目（PM當時也不懂何謂軟體可靠度，這就是第三個笑話），但稍微回過神之後接口回答 “高鐵有營運的壓力，所以該案子做的再怎麼爛，高鐵公司非用不可”，後續該公司主管也了解在需求文件中有未執行的所謂的軟體可靠度項目，而且後來也搞清楚工程複雜性超出他們的能力，就下指示 “政府訂定出業者做不到的需求，所以這是政府的問題而不是業者的問題” （這就是第四個笑話），這家公司拿這個案子當做CMMI的評鑑資料，印度來的主任評鑑員也看不出竟然有未執行的買方需求的問題（這就是第五個笑話），就給了Level-3。現在政府確實有營運的壓力，所以高鐵局、高鐵公司、勞氏驗船協會（IV&V）全部都簽收（這就是第六個笑話）這項不符需求的產品，真不知他們是怎麼做需求追溯表Requirement Traceability的（這是我參與CMMI後學到的表單，但聽說只要有追溯表單就好了，LA不管你內容是否正確）。

我現在也離開了公司，準備找新的工作，但決不再找號稱要推動CMMI的公司。

Joker 兄和我看到的現象差不多, 台灣導CMMI好像在準備考試, 只要過關拿到認證即可, 我不曉得這是CMMI本身有問題? 還是幫忙推導CMMI顧問的問題? 還是評鑑CMMI顧問的問題?

我想Jeffery講的問題全部都有。
為響應Joker所提及的現象，且以目前情況來看整個CMMI的第一、第二與第三者都已不可靠，不妨由社會大眾踴躍公佈所看到的現象或笑話，或許還可以達到些許的監督效果。

為響應alexyin的提議，我也來講一個CMMI的笑話

有一家ERP公司承接某政府財團法人單位的94年ERP建置案，應於95年6月30日結案，由於乙方作完需求訪談也不撰寫需求文件，到了今年2月開始進入Beta Test時，軟體與甲方預期差很多（但因為乙方不寫需求文件，所以乙方不認甲方曾提出需求的帳），乙方堅持不改，其理由是甲方應該知道乙方承接該案的價錢過低所以不可能完成甲方全部需求，且責怪甲方的流程與組織架構未配合乙方所使用的ERP COTS軟體（乙方僅寫界接程式或中介軟體(Middleware）)，由於6/30日未驗收就要罰款，所以乙方在6/29日確定甲方不肯驗收，只好修改軟體，且要甲方在6/30日中午前完成測試。該笑話是乙方在當時已導入CMMI Level-3近一年，上述之修改似乎是不須提Change request、不舉行CCB、不執行Regression Test即交付新版軟體給甲方，且將客戶測試當成軟體整合測試，交軟體也不須一併提供測試報告，堅持甲方如果測不出問題代表乙方軟體沒問題。

拜讀各位先進的「笑話」或高見後，似乎可以歸納為二類：

1.「期望太高，失望也大」－ 其實 CMMI 本身無罪，罪在導入者的心態不對，未認真落實執行，只是拿 CMMI 當「文憑」唬人。平心而論，這種現象也非僅台灣才有，印度與中國大陸也是很多的，就好像每年考上台大的人很多，但台大畢業生也不見得每個都很優秀，畢竟「文憑」只能參考，是否「名實相符」還是要實測才穩當。據說美國國防部的許多大型軟體購案，除了要求承包商 CMMI 評鑑資格外，還是會事前組成稽核小組去實訪廠商進行深入評估的 !

2.「魚目混珠，誤會一場」－ 3323052 所舉的案例，有可能是屬於上一類，但以我個人的經歷，也很有可能是：該公司其實只是拿某個「實驗部門」去通過 CMMI 評鑑，其他「作戰部門」根本沒碰過 CMMI ，但是該公司卻對外宣揚「本公司已通過 CMMI Level X 評鑑」，而資策會、軟協、甚至工業局為了宣揚其輔導績效，也都爭一眼閉一眼，大家只有到美國 SEI 的官方網站才能看到事實的真像 ( 連 SPIN Taiwan 的網站也不公佈 )，放任「魚目混珠」的結果，反而造成大家對 CMMI 的質疑，真是 CMMI 何辜啊 !

有關 Terry 所提的“據說美國國防部的許多大型軟體購案，除了要求承包商 CMMI 評鑑資格外，還是會事前組成稽核小組去實訪廠商進行深入評估的”，以下是個人所知資訊：
1. 依據美國採購法PART 10 MARKET RESEARCH 一節，甲方可進行乙方之 On-site Evaluation，以了解乙方之能量，一般是在發RFP之前進行；
2. 美國國防部曾於 1999 年之 DOD 5000.2R 規範承約商資格為 :
甲、完全符合SEI SW-CMM Level-3，或等同（Equivalent）之評鑑模式，
乙、對於未滿足上述條件者可提出風險規避計畫(Risk Mitigation Plan for Deficiencies)，
丙、等同之評鑑模式須經核可。
但此等規定已於2006年刪除。
美國國防部的 Evaluation Model Best Practices 清單有 CMMI、ISO-9001、EIA-731、SDCE、J-STD-016、ISO/IEC-12207、BOOTSTRAP、Lean Aerospace、Six Sigma…，非僅限於 CMM 或 CMMI。

看完各位對於CMMI的所謂笑話，顯然業界是需要更多的工程與管理再教育的。因為這些所謂的笑話，當你更了解這個模型的目的，以及從企業目標的角度去思考的時候，這些根本「不是笑話」，而是「悲哀」。 而悲哀的是，在一些錯誤的期許下，國內的資訊產業競爭力每況愈下。

不知道各位看倌是否了解為什麼ISO 9000:1994要進化到ISO 9000:2000年版？這其中的一個因素就是成本的問題，因此，在新的一個版本早已就不再盲目追求「零缺點的品質」，而是滿足要求。

CMMI ML3，在產品品質上追求的也是「滿足要求」，在組織流程上是要持續改善，透過流程的持續改善，提升產品品質降低成本與風險。但是我們要注意到的一件事是，每一件事都是要成本的。當大家在看這篇短文裡的所謂「笑話」時，大家是否想過，我們的客戶在外包資訊系統開發與維運服務案時，是不是已經估算到所有可能的成本，並且提列出來？事實上是沒有的，廠商在看到客戶RFP的時候，最多只看到一個預算金額及工作條款(SOW)(包括需求，甚至於工作條款都是不清楚的)，這樣子的RFP其實根本不合格，而且嚴格來說，這樣的RFP，包商應該可以就把這些當作專案的範圍，而沒有提列清楚的，都不算是RFP裡的需求，除非是一些明顯可以確認屬於衍生需求者，而且客戶如果要求得更多，應該是要有超然獨立的單位來認定，確認是屬於衍生需求，否則都應該是被視為在範圍之外的需求。另外，RFP當中也應該有一個相對於SOW項目的預算分配，這個預算分配除了給最終產品的預算金額之外，還應該包括所有專案管理(管理性文件及各項報告)及支援性工作(建構管理、品質保證、驗證與確認、測試、稽核、審查等等)的預算，而廠商要根據這些項目，提出廠商自己基於過往專案經驗，在這些項目上，以符合專案品質要求為前提的預算分配。這樣的說法，看似對於政府部門不公平，但是實際狀況是，對於客戶方如果沒有這樣子的要求，政府部門的最高管理階層並不會重視這些事項，而永遠只是看著一個數字在做管理，不會設法訓練出合格的人員，以從事資訊服務外包專案規劃與管理的工作，而把這些專案的規劃、執行、管制的工作，託付給非資訊服務獲取規劃與管理的專業人員來執行。

個人參加了數次由工業局主辦，資策會與中華軟協協辦的獲取管理的研究成果報告，根據統計分析結果，政府部門總認為自己的採購作業是有一定的流程的，而且所做所為都符合那個流程的要求，但是，實際的狀況是，就算形式上滿足了採購流程與相關法規的要求，但是實質上產品的內涵是沒有辦法滿足專案執行的要求的，但是大家也許會質疑，政府部門在辦理採購前，不是會經過層層關卡的內審作業嗎？相關的主官、管，會計部門、資訊部門的人不是都會參與審核及簽署的嗎？但問題是，會計人員管的只是那個預算數字及預計的預算執行時程有沒有問題，階段裡有沒有產出可以當驗收標的，在預算編列上合不合規定；招標訂約單位的工作，則是以其他案子的金額為標準，透過砍案子的金額來顯示自己的績效；資訊人員只管資訊技術的問題；那專案管理的問題誰管？工程管理的問題誰管？事實是根本沒有人可以管。不是有資訊人員嗎？個人相當懷疑(至少我所遇過的政府資訊人員承辦人員，對於專案管理、工程管理就沒有很完整的觀念，並具備良好的知識與技能)。事實上，通常不會有政府部門的人員，在專案外包簽約前去關心，並且完整地思考可能問題的解決方案(風險管理)，而是在專案開始之後，才被動地嘗試解決問題，但一切都為時已晚，同時也由於政府部門人員能力不足，沒有辦法事先看清楚這些問題，並做好預先的規劃，因此造成需求不斷變更、專案延遲、甚至於案子驗收不了，最後會由誰來承擔責任與後果？承辦人要承擔嗎？當然不會，因為承辦人有問題，就表示主官、管有問題(沒有盡到監督與管制之責)，所以最好的方式，不是粉飾太平(對stakeholders 撒個天大的謊話，說一切符合要求，甚至宣傳為主官的政績)，就是迫使廠商去全盤接受所有的問題(這還是有風險的，因為不知道廠商會如何反撲)。當然，迫使廠商接受所有的問題是相當的不公平的，因為「公務人員的薪水來自於政府總預算，總預算來自於稅收，稅收來自於廠商所創造的價值」，而擔任公務人員者，透過政府部門拿到了薪資(廠商經由稅收，提供給政府部門公務人員)，卻沒有做到 身為國家一份子之廠商 透過立法部門立法，期望該等公務人員應該盡好的本務，在造成問題後，卻仍要廠商賠錢去承受所有的政府部門在缺乏規劃與管理能力下所造成的惡果。這樣的惡性循環下，所產生的問題會是：廠商無法繼續經營下去，因此，政府稅收短缺，無法承擔更多的公務人員人事成本以及後續的退休給與，財政日益困難，於是人力不斷精減，但是，事情並沒有因此而減少，相對於人力的精減，每位公務人員所承擔的事情越來越多，責任越來越大，進而行政品質越來越低落，問題越來越多，公務人員越來越怕自己會出問題而領不到退休金，因此只好一味往廠商身上去推諉。

我們再拉回「笑話」的議題吧，「CMMI笑話」的問題，個人認為並不在於CMMI本身，也不認為有些要求沒有做到就是一種笑話，但那是一個悲哀。悲哀來自於政府部門人員的人力與能力不斷流失，以及相關人員的心態問題。個人認為，在政府部門也應該建立起一些文化，例如，對於問題溯及既往，不論該案完成的時間多久遠，在檢討出問題的原因後，要對有問題的人員追回因該案得到的獎勵或者陞遷，並且負起必要的法律責任，而不要因為時過境遷，以當時已經「安全下莊」，問題不是發生在該員任內，而輕易放過，如此，才不會讓主事者(原承辦人及其當時的決策主官、管)有僥倖的心態，只追求一時自利的表面績效。

另外有些看似笑話，但是從事情的過程與時序來看，其並不值得評論，因為有些事項從CMMI的架構下是可以裁適與豁免的。在談到CMMI時，應該要了解CMMI評鑑，要看的到底是什麼？CMMI要看的是制度的建立與執行。以可靠度需求這件事來說， CMMI評鑑不會去看單項需求有沒被實作出來，而是看相關的需求管理、需求發展、風險管理、品質保證、建構管理、專案監控與管制、DAR執行的狀況，進而找出組織能力提升與流程改善的方向。對於上述的「笑話」，其實所代表的是我們資訊業界的整體工程與管理能力的薄弱，屬於我們學校教育，應該加強的部分。這樣的哀悲，個人曾經也在大學或學院執教鞭者身上看到，明明資訊技術與工程為其主要的領域，卻對於這些工作上的知識與技術一無所知，當然就更不會教給從業人員了。

就個人的理解CMMI所提供的是一個品質管理(包括組織體質、組織基礎建設及組織流程)與改善的框架。像品質因子、工程管理、專案管理的知識與技術等，這些是不在CMMI框架裡的，CMMI框架只是提示要運用這些知識技術於工作上，這與每一個從業人員的本職學能有關，是要由組織基於自己能力經營與發展的考量，在人力資源上建立與培養這些知識技能的。

再找工作的時候不再找有CMMI評鑑的公司？這樣的說法，會不會太自暴自棄了？事實上，通過CMMI ML3評鑑的公司，如果願意遵循的話，會比完全沒有制度的公司要好很多，當然這也是需要我們最大的市場—政府部門，好好把能力提升起來，並對其他行業的資訊服務採購起帶頭作用。要不然，沒日沒夜的工作，永遠是資訊軟體業的夢靨。

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

這種現象為何會發生在CMMI SW/SE Level-3 的公司?

新聞 1.「抱歉、不知道」　高鐵大當機！手足無措

從1月5日到1月14日高鐵試營運一連10天，車票半價，今天起開放民眾預購，一早就有大批民眾前往高鐵車站買票，不過卻是狀況頻傳，電腦系統連連出錯，引起民眾不滿。

新聞 2. 首日賣票：亂！慢！塞！旅客怨 高鐵道歉

高鐵售票上午正式開跑，不到六點就有大批民眾湧進高鐵沿線車站，希望搶購到具有收藏價值的紀念車票，可惜高鐵委託「XX 公司」設計的票務系統不爭氣，讓旅客大排常龍，北部三個車站都傳出無法使用信用卡的現象，高鐵台北站專員丁莉華說上午六點三十分，發現不能使用信用卡，勸導民眾改用現金。
http://tw.news.yahoo.com/article/url/d/a/070102/1/8uwd.html

答案不是已經回應了嗎？那是一個集體造成的問題，而非單純一家公司的問題。

社會充斥太多病理學家論述，獨缺針砭之作。
紛亂的世代，需要的是正確的方向與力挽狂瀾的氣魄。

CMMI框架本身並沒有問題，因為它是一個最佳常規的集合，而導入CMMI的公司沒有辦法把事情做好，固然是事實，主要是因為執行的人有問題，但不應該就去推翻這個框架的價值。

今天，個人以為該談的不應是再去找出更多的坑坑疤疤，因為這些都是老生常談了，反而應該是貢獻一己之力，思考一下如何興利與防弊，否則只是讓整個市場更為混亂，採購單位動則得咎，更加趨於保守，寧可相信自己，也不願意去相信良善的制度，或者引用良好的制度在管理上，如此，什麼ISO/IEC 12207, CNS 14837, ISO/IEC 15288, CNS 15508都將只是參考，本協會也沒有任何存在之價值了。

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

謝謝alexyin以實例幫我點出問題，我也參與過高鐵售票系統開發，只能講公司的實際做法就是CMMI歸CMMI，專案歸專案。

也謝謝jeffery所說的“ 台灣導CMMI好像在準備考試, 只要過關拿到認證即可, 我不曉得這是CMMI本身有問題? 還是幫忙推導CMMI顧問的問題? 還是評鑑CMMI顧問的問題?”

希望這個高鐵案例能讓工業局對於CMMI做個檢討。

以我參與CMMI的經驗，可以確定的是輔導公司的顧問或LA本身並未有涵蓋Level-2/3 的全部工作實務，大部分連Design Review或Change Request都未有過實務經驗，就敢上台輔導，公司等於是花錢買考古題的解答，拿錢幫顧問公司建能量，至於類似CCB如何舉行，沒人管，反正只要有文件紀錄即可(一天完成也無所謂)，這才是最大笑話。