台灣軟體產業二三十年來，多數廠商在政府單位人員缺乏軟體工程觀念、成本觀念的蹂躪下，一直處於慘澹經營的狀況下，能夠賺錢的寥寥無幾。在多數的資訊服務委外案子裡，一開始買方就沒搞清楚自己的需求，然後東要求西要求，在很多情況下已經超出了合約的範圍，但是廠商為了能夠結案，多半是忍氣吞聲。在更多的情況之下，買方還是趾高氣昂說，這是「買方市場，愛做不做！」吃定廠商。也許在目前或者真的是如此，但是在不久的未來，可能這個狀況會改變，因為廠商的競爭能力正在加強當中。

目前有許多的廠商正導入CMMI，而且已經有一些廠商已經通過第三級評鑑，並且更進一步朝向更高成熟度等級前進。或者有政府單位認為，他們的軟體品質在爾後有機會改善了，但是如果政府部門或者是民間企業的買方，在自己提需求及合約管理能力如果沒有同步地提升，這種期望可能真的會落空的，因為一旦國內的廠商通過了第三或者更高級的評鑑後，他們的眼光就不會再放在國內的市場了，而是更為廣闊的國際市場。到那個時候，政府部門的軟體品質會更差，因為挑到的廠商都是一些二三流的角色，想要以通過CMMI評鑑當作門檻嗎？如果政府部門的腦袋沒有好好調整，這種門檻是行不通的，有那個具有國際競爭力的廠商會笨到找一個沒有Sense的客戶，來勒住自己的脖子呢？

我想再過幾年以後，國內的資訊服務委外市場就會變成賣方市場了，因為廠商有了國際競爭力的時候，可就有籌碼可以挑客戶做生意！政府部門的資訊委外業務承辦人及政府部門的使用者，要好好加油了....

個人認為買方(尤其是財會部門)需要建立"品質有價"的觀念，不能又要馬兒好，卻又不給馬吃草，為什麼歐美、日本、印度的軟體價格高? 因為其中包含了供應商投入品質管理的成本，因此我們要求國內軟體供應商提升品質時，也應該同樣付出合理的品質管理成本(包括技術文件、管理人力、品保測試...等)才對。

買方在提出需求的時候必須考慮到自己要的是什麼？所要求的是什麼？這些需求的產出、確認、管理，一定也有合理的人力必須支出，也可以找出合理的價位，如果只是讓供應方吃虧，勢必犧牲品質，最後兩敗俱傷。

買方要是了解到什麼是應該做的事，並且編列必要的預算，供應方當然非常樂意配合，也會要求內部員工必須有適當的能力，提供一定的品質來把案子給完成。

實在是非常認同!!!

這些客戶上級單位對品質的「價值」，以及對於「定義需求」流程不尊重，其實是殺害品質的最大殺手之一。

不過，廠商如何在這樣艱困的環境，能夠把品質一樣做出來，可能就是我們廠商維持競爭力的做最大要件了！我們當然可以說是客戶的問題，客戶不願意花錢買品質，但是如果大家面臨客戶不重視品質的前提都一樣的話，除非我們出去找認同品質的客戶，不然我們只好在這樣的環境裡，提升我們自己的能力，把自己的應對方式做出來，好好的來服務這樣的客戶了。

舉例來說，客戶對於需求的變更，如果都是無法控制的，如果都不認同變更是需要一定流程才能作出來的，我們內部的因應方式就必須能夠有更快的回應，更快的把結果作出來，不然我們只好陷入永遠無法滿足客戶的需求，而陷入無法結案的深淵了。

----------------
Thanks

現在政府政策是積極推動軟體業者導入CMMI，協助業者加強軟體能力成熟度，然而事實上，台灣長期以來最大的問題是在買方不夠成熟。因此，如果一個通過CMMI的軟體公司去承包不成熟買方的軟體委外專案，恐怕也是雞同鴨講，後果難料。

在此請教各位先進，買方也有需要導入CMMI嗎? 或者，至少需要有哪些知識與訓練，才能有利於資訊軟體委外專案創造供需雙贏呢?

另外，雖然目前號稱已有許多家軟體公司通過CMMI評鑑，但幾乎都只是內部某個部門或某個Team通過評鑑，有整個公司通過評鑑的嗎?

如果未來政府招標要求投標公司需通過CMMI評鑑，那麼僅內部某個部門或某個Team通過評鑑的公司也可以投標嗎? 還是只有那個部門才可以投標呢?

敬請賜教 !

CMMI代表著軟體具有一定的品質，但並不是保證最佳品質，企業為了保證風險在一定範圍內及專案成本的控制，而採用具CMMI認證的供應商不需多言，但政府必須採用此認證的供應商就不行了，做好軟體的品質不是只有CMMI，以此做為門檻有失公平之虞吧。

CMMI的導入代表供應商的成本提升，因為導入費用及認證費用都極為可觀，若是以CMMI就是排除了資本小的公司，所以是一"類綁標"的行為，反而應該是鼓勵招標時將驗收的方法做為招標書的一部分，由專家評鑑其方法是否完整即可信賴較為合理。

軟體的最後把關是在驗收不是導入，導入的觀念要好做事方法要對，但軟體最終把關還是在驗收，以往台灣軟體都是在導入期特別長，驗收卻是草草結束，所以這問題不是在CMMI而是在對軟體的觀念，這就是為什麼通過CMMI評鑑的公司還是可以做出一大堆問題軟體，因為驗收沒做好。

台灣做事都是一窩瘋，CMMI來了，好像全部的軟體公司都需要CMMI，連買方都需要導入，這個錢還真好賺！其實台灣應該推的是驗收的標準方法和正確的軟體觀念，這些沒做好都是白費。

深有同感, 軟體開發流程有許多種, CMMI 並不是唯一的選擇, 其實 Agile Development 也不錯, 如果開發團隊與客戶對於 Agile Development 有同樣的共識, Agile Development 對於軟體的驗收與客戶滿意度也會很有幫助, 而且 Agile 概念很簡單,但是重點是軟體開發團隊與客戶要能掌握 Agile 的精神.

CMMI 對於小型的軟體公司, 個人覺的從成本與導入效益並不能成正比, 國內許多軟體公司或軟體團隊規模並不是很大, 導 CMMI 似乎有點殺雞用牛刀的感覺, 相信這也是許多軟體公司對 CMMI 裹足不前的原因.