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

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

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

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