我們常講的民不聊生，事實上等於在講政府部門不知民間疾苦。先以一些實例來聊資訊服務業的疾苦。

實例1：某CMMI Level-3公司承接某ㄧ政府專案，在計劃初期PMP即被退了8次，2年後計畫預算被政府減半，但該公司在該專案一樣賺錢，其主要運用策略是(事實上眾多IT專案都是以此模式運作)將專案大部分工作委外且不簽合約，因此該案被減價，公司就將委外的錢全部不給，反正沒簽合約，參與委外分包的公司一點辦法也沒有，但是下ㄧ次仍繼續接該公司的分包合約，因為這些專做委外分包合約的小公司不具備競標資格，有做還有機會拿到部份的錢，只好忍着做。為何會被退8次? 因為該合約未訂定文件撰寫格式與內容說明文件，乙方以為未訂定格式，易於交件，誰知每次送審都有不同人或同ㄧ審查委員有不同的意見。為何承約商會將大部分工作委外（我甚至於見過政府專案的得標廠家，委外項目包括PROPOSAL撰寫、QA、CM、文件撰寫，乙方只做Coding）？答案是合約金額過低，且簽約後變更需求但不修改合約金額。

實例2：政府每年編列預算鼓勵海外青年回國技術訓練，提供訓練的公司及參與的海外大學生政府都給予補助經費，這些未畢業的大學生本身並無專業工作能力，但有國內的CMMI認證通過公司ㄧ樣將此等回國參與短期訓練的大專生，納入專案人力，問題一樣出在合約金額過低，且簽約後變更需求但不修改合約金額，但為何甲方的履約監控未能察覺此等不符合資格的人力應用現象。

實例3：軍方每年都有大批的退伍職業軍官，年紀大部分在45歲至55歲之間，對於美國來講是屬於工作風險最低的階層，每一個退伍軍官都想尋求二次就業機會，國內有些公司會透過學長學弟關係邀請這些退伍軍官面談，同時藉口想要了解專業能力，公司會將專案必須交付的文件交給這些人撰寫，公司稍微修改之後即交給政府，但公司大部分不會再繼續接觸原文件撰寫者，反正每年有眾多退伍軍官，可以分批試用。如果政府有真正履約監控，不應發生此現象。

CMMI對於公司的流程確實是有正面效益，但事實上CMMI是針對美國政府採購架構所訂定的成熟度模式，我們的採購法與美國政府採購規則卻有極大的落差，CMMI Level 2&3 的18個PA幾乎無法全部套上政府合約，各位試想有那一個合約真正在執行Risk management、Configuration Management、Functional Baseline、Measurement、… (真的要照作，就要花不少錢)，但奇怪的是每一家公司都能在Assessment時提出相關資料，合約沒有要求製作WBS或Work Package，也一樣能編的出來。製作文件是要花人力、花時間、花錢的，難道說台灣IT公司都有錢到政府未要求的文件、程序、流程，廠家全部都會自行吸收免費製作（別傻了，醒醒吧)。各位不妨將CMMI的工作事項(Organizational PA除外)與現有政府合約做個矩陣表，看看有那些GAP，這些GAP就是錢坑，否則你就只好照實例1/2/3的方式降低成本。

18個PA每一個都要花不少錢才能達到，如果要達成CMMI的要求，除非政府有心理準備所有IT相關的採購專案必須依據PA來概估成本，否則政府預算不增編，卻要廠家增加工作事項，這就是不知民間疾苦的實例。

研考會在大力推動CMMI-SE/SW/..，是否真正知道國內IT專案執行的方式，這些閉門訂定規則的官員，是否有真正專案執行經驗以及真正駐廠監控經驗，否則整個CMMI推動下來卻不是政府採購部門要的東西，豈不是笑話一場。(除了研考會以及國內CMMI輔導公司外，各位可曾聽過有那一個政府採購部門認為CMMI對於採購品質有幫助的?)，

或許推動CMMI之前，政府部門應先檢討政府合約與美國政府合約的落差，否則推動一個可以滿足美國政府合約的成熟度模式，但政府部門仍不知IT業的疾苦（要做符合CMMI的事就要給錢，要修改需求也要給錢），只能逼國內廠家出走專接美國政府合約，屆時國內國內政府合約將面臨無人願意承接的危機了。(請當作笑話)

其實歸結起來，只有一個問題，那些公司的管理者，從高層至中、低層都是不適任的。因為明明自己的Title上掛的是「經理」(包括協理、副總經理、總經理)、「執行長」，卻沒有知覺整個公司所需要的管理，就是自己的責任，好像「經理」的工作就是在外面跑業務、拿案子，然後責任就了結了。當然有人會說連活都有問題了，還談什麼「制度、系統」？但是不談制度與系統，企業所面臨的，其實就是不斷的惡性循環。而惟有管理者擔負起管理職責，劍及履及，才有機會跳脫這種企業生存的惡性循環。
最近被一些客戶搞得很頭痛，不得不把國外企管學院、企業高層常談的中國孫子兵法再拿出來談。我認為至少孫子兵法的始計篇，這些的企業經營者就得好好的研究一下，尤其裡面的「道、天、法、將、法」更應該好好去鑽研及落實。或者，讀者諸君會以為個人是軍校畢業，所以特重孫子兵法，其實不然，想當初個人在國外大學研究所研習系統工程管理時，我們策略管理的老師，給我們上的課程內容裡就有「孫子兵法」(想來還真是諷刺，一個台灣的軍官在國外學習孫子兵法)，當然我們全班五十多個人，其中台灣學生有10人，都是各軍種派訓，班上其他的人都是該國的企業經理人及工程師。
撇開孫子兵法、CMMI不談，談談被許多人士嗤之以鼻的ISO 9001制度吧，其所圍繞的還是「管理者的職責」。之於管理，都是相通的~~兵隨將轉，強將豈可能有弱兵？管理者自己都做不好了，還能夠要求員工全力以赴，誓死効忠自己嗎？當然所有的事情就是應付了事囉。

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

"CMMI is not engineering discipline, the development capabilities should be based on engineering discipline"，這句話說得太好了。

君不見，每個推CMMI公司的管理當局總是“幾乎是巴不得全體員工參與CMMI本身的教育訓練課程”。可是顯少看到有公司要求所有相關人員，接受各項過程領域所涉及的工程訓練。只見這些公司於開始推動此項工作若干時日後，公司順利取得想要的認證。卻不見該公司員工真正在需求管理、專案管理、型態管理、下包商管理…等領域的能力有所增進，也不見其員工能寫出什麼像樣的技術性文件(如：SyRS、SyAD、SRS、SDD…)。尤有甚者，這些公司的員工在心態上還是認為：寫這些文件是多餘的、没必要的，只有寫程式才是最重要的工作。

可悲啊!！可悲！您看過這些公司累積了多少可用的量測資料？又從中學到了些什麼？沒有啊！沒有！有的只是連填報這些資料的人，都不相信的一堆假資料(垃圾)。可憐啊！可憐！這些公司的員工談到ＣＭＭＩ，可能的話，無一不想逃得遠遠的。

這種『只在乎有個過程，而不在乎有沒有員工可以用“合乎工程紀律”的方式體現這個過程』的推動方式。個人以為這正是台灣業界推動CMMI最大的笑話與最大的問題所在。

醒醒吧！醒醒！誠摯的希望這些公司的管理當局，能把責任釐清，不再要求所有人員參與CMMI本身的課程。讓SEPG去負責與學習CMMI；讓PM去負責與學習專案管理；讓系統分析師、軟體設計師、測試工程師、品保人員、型態管理人員…各自負責與學習其各個角色所應負責與學習的東西吧，真正步上“專業分工”的正路。

以上問題可以參考以下文件可以獲得一些想法：
1. MIL-HDBK-881 Department of Defense Handbook, Work Breakdown Structure.
2. DoD Guide to Integrated Product and Process Development
3. DoD Integrated Product and Process Development Handbook

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

換了一家公司，公司有了CMMI-SW/SE Level 3，主管都相當的志得意滿。上週美國一家公司來參訪，卻讓公司鬧了些許笑話，該美商公司打算參與國內的國防系統標案，國內軍備局要求採用Integrated Product Team進行專案管理，公司在推動CMMI時也曾一併研讀與IPPD相關章節，因此相當有自信能滿足美商的關切事項，但幾個問題問下來卻讓公司鬧了些許笑話：
1)What is the relationship between PIPT and CWBS?
2)Who are the members of PIPT?
3)What is the play role for Acquirer in PIPT?
4)What is the reasonable size of PIPT?
5)How Project Manager define the authority of member of PIPT?
6)How to monitor the Cost、Schedule、and Performance of PIPT?
7)What is the relationship between PIPT and PWBS?

附帶一提的IPT包括有OIPT、WIPT、PIPT，WBS有分CWBS與PWBS，這也是我們鬧的笑話之ㄧ，因為我們只知道IPT與WBS。
煩請國內的CMMI專家提供前述答案，供本公司補考用。

美商的建議是"CMMI is not engineering discipline, the development capabilities should be based on engineering discipline"，也許Level-3公司尚必須補強某些基礎工程。

“成熟的男人與成熟的女人，比較有可能生出健康的寶寶”，反過來說“生出不健康的寶寶，卻有可能是因為：男人、女人、環境或過程有問題”。

高鐡自動售票系統所發生的問題，高鐡與神通當然都脫不了關係。不過，以一個“軟體工程師”的身份，我更關心的是：神通在這個專案中，是否如實地表垷出“通過CMMI Level 3的組織”應有的組織成熟度？換句話說：如果是換成國外(或者任何)一個其它通過CMMI Level 3的組織，來執行這個專案的話(暫時假設没有語言、文化上的問題)，得到的結果會比目前的好嗎？如果，不會比目前更好(或者更糟)，那就表示神通已充分地展現了應有的組織成熟度。反之，如果會得到比較好的結果，那麼就表示神通在某些方面出了差錯。

犯錯其實並不可怕，也不可耻。重要的是吾人，能不能坦然面對錯誤，並從中學習到由書本中學不到的寶貴經驗。不知那個人或單位能促使神通出來(或者神通在適當的時機願意主動出來)，分享他們在這個專案中所學到的東西。此事果真有幸，能夠成真，將是吾人最大的福報之一，神通與那個人(或單位)也將功德無量。

軟體品質協會資深管理師 周茂松 敬上

為避免誤解，我要先聲明，我和神通公司沒商業往來，也沒有利益關係。之所以提出不同的看法，單純是因為在搭乘高鐵的過程中，我認知到高鐵公司的整體管理問題可能比目前所呈現出來的軟體問題更為嚴重，因而想提出不同的觀點，寄望對於這個問題的討論，有機會更深入，也希望對於導入CMMI能否對軟體的品質及專案的績效，能夠有不同方向的討論。

對於TVBS所報導的現象，我同意是存在的，也的確是問題。在思考這個問題的時候，我試著利用CMMI中的一些實做要求，推導高鐵售票系統開發過程的可能限制和問題，希望有機會如果是由我們發展類似高鐵這樣複雜專案時，我們可以不要重蹈覆轍。

在CMMI的Model中，指引許多在進行需求收集和發展時，可以考慮的一些實做方法，包括採用技術展示、專案期中審查、系統雛形、採用問卷進行資料收集等方法，收集、引導及發展顧客需求。以高鐵案的售票系統為例，如果採用CMMI所提供的參考實做方法來收集需求資料，可能會有以下這幾種情況：
1. 顧客（高鐵）完全不知道售票系統的定位，因此在開發這套系統時只要求滿足售票系統的功能性需求，在使用者無明確的操作需求下，系統很可能發展出來後，卻很難使用。
2. 顧客有其他比操作性需求要求更高的需求，例如成本考量、系統安全（付款機制）、發展時程（儘快上線）、技術限制（不管選用歐系或是日系的系統，都會有技術限制），當售票系統進行需求發展和軟體設計時，有關於操作性的需求，便不在優先考量的範圍，系統難以操作也就不足為奇。
3. 在進行售票系統開發時，顧客並沒有要求服務提供者（神通）以顧客（高鐵）以外的最終使用者為需求收集及訪談的對象，單純只是收集來自顧客的需求，因此雖然採取許多CMMI所建議的一些實做方法，由於訪談對象不是最終使用者，造成系統和使用者的需求有差異，也屬正常。
4. 顧客要求神通公司納入一定比例的使用者最為訪談的對象，以作為建立操作性求的依據，神通公司在執行這向活動時，產生專案管理、需求訪談及分析、軟體設計的問題，使得系統完全不符合使用者的要求。

以上所推論的幾種情況，也許是實際發展過程中的現象，也許不是，畢竟只是推論。影響軟體品質的因素有許多構面，軟體開發商的技術及管理能力只是當中的一部分。由於我們都沒有參與這個專案，也只能從外面報導的資訊來探討背後可能的因素。以高鐵案建置過程中，發生的許多問題，包括預算超支、用地取得、時程延遲、通車過程的履勘不過等問題，如果再加上政商間的競爭和合作關係（例如高鐵的部份系統由歐系改為日系），我個人認為一個軟體開發商要在其中扮演好角色，難度本來就很高，如果神通公司沒有導入CMMI，也許情況會更糟。

----------------
台灣應用軟件府份有限公司 葉顯榮

www.tasc.tw

挺有趣的想法。
那請問以下TVBS新聞所報導高鐵營運第一天的新聞，是否屬於軟體的問題?

TVBS新聞：
高鐵預售票今天首度開賣，結果一個上午，狀況頻傳。不是刷卡機不能使用，就是售票系統當機。排隊買票一個人平均半個小時以上，民眾甚至氣得向高鐵發言人抗議，場面相當混亂。
http://forum.news.yam.com/disingle.php?tid=507857

由於高鐵通車引起對於導入CMMI是否能夠改善軟體及系統發展品質的許多討論，大多指向負責軟體開發的神通公司，看法也多偏向負面。我在上週四(3/22)剛好搭乘高鐵到南部，過程中的一些經驗，想要借用這個論壇發表，希望提出一個不同的觀點，讓討論導入CMMI是否有幫助這個議題，可以有進一步討論的空間。

上週四上午08:30我到高鐵的台北車站準備買票到南部，在抵達自動購票機前，有一位小姐已經在買票。我約略等了二十分鐘後，這位小姐還是沒有買完票，最後放棄買票，終於輪到我買票。買票前我知道09:15有一班車，但是當我輸入起迄地點後，指顯示出10:15一班車，沒有其他資訊，由於不確定情況下，我放棄買票，到櫃台查詢清楚後再回來買票。回來時有位先生比我先到，約過個幾分鐘後，他轉過來問我「這台機器收不收現金？」我抬頭看那台自購售票機，上面標示著「信用卡及金融卡」二種購票的付款方式。

以上這些並不完全是軟體設計的問題，售票機在售票過程中沒有提供充分的參考資訊，使購票者無所適從，是軟體設計的問題，但消費者不看高鐵所提供的購票資訊，是消費者的消費習慣所造成的錯誤，和軟體設計無關。

當我購完票之後，持票要進入車站，票是掃過了，但是門卻沒開！我問現場服務人員，他說他也不知道，我只好再問另一位服務人員，他說我的票卡放錯面，所以無法進入。同樣的，既然票卡放錯面，機器不應該可以解讀，又是屬於軟體的設計問題。但是服務人員一問三不知，卻和軟體設計無關。

終於，票卡放對正確的那一面了，但是還是不能進去。我再問服務人員是何原因，他說我的票必須要到09:15之後才能進去，現在只在外面等，可是現場座位有限，也沒有其他的去處，只好在現場等到09:15之後在入場。這是政策的問題，也和軟體設計無關。

我約略在09:50時回到出入口，刷卡順利進入，這個時候卻找不到位置坐。我試著下到月台後車，被服務人員阻止，說要到10:10才能下去月台，現在只能在上面等，這樣我又站著等了20分鐘，才下到月台。在等候這段時間，我端詳著高鐵的現場服務人員，從穿著、舉止到服務的方式，無一表現稱得上專業，我不禁要問高鐵的唯一訴求難道只是「高速」而已，沒有其他？

整個旅程，從我到車站，最終抵達目的地時已經超過四個小時，還好我當天不趕時間，否則鐵定來不及。

從上述的這些情況，我毋寧說「台灣高鐵營運的品質才是最大的問題，軟體設計問題只是這個問題冰山的一角」。種種跡象顯示「這是個拼湊的服務」，以一個軟體產業的從業人員的角度來看，我會說「即使做到CMMI Maturity Level 10」也不能解決這個問題，何況神通公司也不過通過CMMI ML3。我當時心中浮現一個想法「還好神通公司是一個通過CMMI ML3評鑑的公司，如果是其他軟體公司，這個專案很可能不會能夠在此時上線，甚至上線後問題會更多」。

CMMI的需求發展與需求管理二個流程領域可以提供解決軟體設計過程中「收集與引導需求」和「管理需求變更」問題的方向，但不能解決來自於管理階層對於整體營運及管理想法的度確定性和不成熟性。套用CMMI成熟度的概念，台灣高鐵目前的營運及管理還在CMMI ML2的階段，但顧客對於服務品質的期望卻已經在CMMI ML4之上了。一個成熟的軟體開發公司可以採用成熟的軟體發展管理的方法，協助顧客成功的開發及建置軟體應用系統，但無法跨越顧客，發展出超出顧客目前認知及能力的軟體系統。

CMMI不是萬靈丹，將高鐵軟體系統的問題全部規怪罪於神通公司是不切實際的。如果還人說「導入CMMI不能解決軟體開發的績效和品質問題」，我會說「至少CMMI是到目前為止，被印證最能夠引導建立解決軟體發展管理機制模式」，在其他更有效的模式、標準或是方法被證明有用之前，我建議不要將時間花在爭論「導入CMMI能不能解決軟體開發的績效和品質問題？」將時間投入在「如何利用CMMI建立能夠解決軟體開發的績效和品質問題的機制和方法。」

對於許多發表正面或是負面看法的業界先進們，不知道是否在發表看法前，是否乘坐過高鐵？我建議不妨找個時間實體體驗一下，也許會有不同的看法。

----------------
台灣應用軟件府份有限公司 葉顯榮

www.tasc.tw

請問以下這一則新聞是否意指軟體若有問題全部是開規格一方的責任:


高鐵售票機出狀況∼　神通：規格高鐵開　我們只是承包商
更新日期:2007/01/04 12:11 記者:記者陳曉藍卅台北報導

高鐵售票才上路狀況頻頻，對於售票機的問題，負責建置系統之一的神通電腦方面表示，目前只知道3日在板橋站找零出狀況的那台機器，現在所有的工程師都已出動維修，對於神通電腦最近成為媒體焦點，神通方面也相當無奈地說明，所有規格都是高鐵開出，神通只是系統承包商之一而已。

神通電腦企畫處劉慈明表示，目前僅知道板橋站的一台機器找零出問題，維修人員已在現場待命，因為現場媒體、民眾太多，根本沒辦法拆機器檢查，到底是出來什麼狀況，只能緊急把現金功能停掉。

對於媒體指稱，高鐵售票機訂位方式太過緩慢，訂票系統穩定性不佳，頻頻當機，再加上信用卡交易困難，顯示高鐵公司委託神通設計的系統相當「落伍」。

對此，劉慈明說，神通電腦是經營系統整合廠商，也只是高鐵的系統承包廠商之一，所有機器的規格與需求都是高鐵方面開出，神通電腦只是根據高鐵開出的規格來做，指稱神通「落伍」是不公平的，應該詢問開出規格的高鐵才對。