以下是本會程理事長在中國時報95年5月11日「時論廣場」發表的文章，歡迎大家一起討論，發表您的看法：
=====================================
@ 從軟體業上市櫃公司慘況，思考台灣軟體產業的出路 @

[ 中華民國資訊軟體品質協會理事長 程家麒 ]


日前看到一則證券市場訊息，證券櫃檯買賣中心公告十餘家上櫃公司停止買賣或變更為全額交割股，而其中許多竟都是軟體公司，不禁令人感慨萬千。

想當年在經濟部的大力推動與協助之下，許多軟體公司趕在「本夢比」的熱潮中陸續上櫃、上市，股價一時之間達到三位數者今安在 ? 如今放眼證券市場上，不論電子產業或傳統產業都漲翻天，卻唯獨軟體公司股價多仍在十元以下飲泣，甚至一半以上淪為「雞蛋水餃股」（股價比雞蛋水餃便宜），何其淒慘，也難怪軟體業者們私下常常以「軟體慘業」自嘲。

記得我在卸任經濟部工業局軟體工業生產力提升計畫主持人的三年以前，曾積極鼓吹政府推動「新十大資訊建設」，希望藉由大型資訊系統的建置與品質要求，培養國內軟體工程人才與實務經驗，以利拓展國際市場，後來政府果真推出了「e-台灣計畫」付諸實施，經濟部也效法印度和中國大陸，積極推動「CMMI 品質提升輔導計畫」做為配合，然而花費了大筆預算實施迄今，為何軟體產業仍未見起色呢 ?

其實台灣軟體公司不是沒有成功的例子，除了在日本上市的趨勢科技公司以外，國內還是有訊連科技和思源科技兩家上市軟體公司，股價長期維持在高檔，頗受國內外投資者的青睞，深入觀察其共同的特點是：三家公司都是以國際市場發展為主，而且各自擁有其專業應用領域的利基競爭優勢。

由此可見，國內軟體產業長期積弱不振，難以和印度軟體產業及台灣硬體產業相媲美的主要原因，乃在於缺乏國際化的企業人才，因此要振興軟體產業，僅靠「e-台灣計畫」內需市場和「CMMI品質提升輔導計畫」補助是不夠的。因內需市場終究有限，而通過CMMI評鑑的台灣軟體公司，若跟更多通過CMMI評鑑的大陸軟體公司去拼價格，也難爭取到軟體設計的生意。

最近有兩位從事CMMI品質輔導的顧問業者，因對輔導國內軟體公司感到失望，不約而同地決定改從事軟體專案開發的工作，以本身嫻熟的CMMI品質流程管理專長為競爭條件，爭取國內外優質客戶的軟體訂單，先做好系統分析和需求規格的訂定，再委託中國大陸專業的軟體公司進行設計，完成測試後再交回台灣進行審查及驗證確認，然後交付產品給客戶。

這不正是印度軟體產業國際分工及台灣硬體產業兩岸分工的獲利模式嗎 ? 這個模式雖然人人都會想，然而要做好卻不容易，過去也有許多公司曾經嚐試，卻多失敗在需求管理和專案管理的知識能力不足，以致往往做出來的東西卻不是客戶要的。

因此，我認為台灣軟體業要突破困局，國際化是唯一的出路，應加速解決國際化企管與行銷人才不足的問題，政府應輔導國內軟體產業朝向高階的「知識產業」發展，軟體需求分析與管理、驗證與確認、及專案管理人才的訓練與養成，更是當務之急 !

『台灣軟體業要突破困局，國際化是唯一的出路，應加速解決國際化企管與行銷人才不足的問題。』我非常同意理事長的見解與結論。不過，我認為台灣軟體業不足的不只是“國際化企管與行銷的人才”，台灣軟體產業欠缺的太多了。

個人以為台灣軟體產業中擁有最多的是程式設計師，不過很可惜的是：這些程式設計師也只是一些“只能單打獨鬥的程式工匠”，甚至連“工匠”這兩個字都稱不上。因為合格的工匠必定會使用“規”和“矩”。可是在台灣要找到一個會用規矩寫程式的人還真不容易。 也許您會問：“寫程式要什麼規矩呢？”或者 “什麼是軟體產業的規矩？”

話說從頭，“規”有兩個脚，其中的一支脚是用來定圓心的，兩支脚合起來可以定半徑。有了圓心與半徑就能畫一個圓。個人以為在軟體產業中，[需求管理]就是“規”的第一支脚，它的另一支脚就是[專案管理]。

軟體專案有了[需求管理]與[專案管理]，就有了中心點(需求)與半徑(資源)，就能畫出一個“圓”(產品)。不過只有“規”還不能控制圓的大小，必須加上“矩”，才能有令人稱心如意的圓。 個人以為軟體產業中的“矩”就是[驗證與確認]，它可以決定兩點之間的直線，再加上[軟體度量]用來決定兩點之間的“距離”與兩條直線之間的“角度”，這樣才構成了完整的“矩”。不論軟體產品是由一個人或一群人來開發，缺了“規”和“矩”都不能做出令客戶滿意的產品。

如果軟體是由一群人來共同開發的話，只有“規矩”還是不夠，必須再加上三樣東西。第一項是這群人要有“共同的語言和語彙”來溝通技術上與管理上的意見與想法，團隊才不會雞同鴨講、各彈各的調，進而大家群策群力的往一個方向走去。可用的技術語言有：UML、正規語言…等。管理上的語言就是WBS、標準與工作程序…等。這些想法與意見也必須書面化，因為唯有書面化的文件才能被驗證與確認。此外團隊也要有一個“計時器”，來產生專案的脈動，同步大家的工作，它就是[型態管理]。最後，還要有一個“曆法”，來呈現軟體產品自然的生命成熟度，它就是專案使用的[軟體生命週期模型]。

一個軟體開發組織，個人以為必須具備上述的五樣東西：規、矩、語言、計時器與曆法，才有可能開發出合乎客戶需要的軟體。當達到這個基本要求後，再加上理事長所說的『國際化企管與行銷人才』，才有可能到國際市場上與人爭長短。否則，只有一個“慘”字可以形容。

個人淺見，僅供參考。

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

我非常同意程理事長與周管理師的見解，台灣軟體業除了要『行銷國際化』外，還必須要『製造工業化』及『管理工程化』，因此必須加強[軟體元件技術]及[軟體工程管理]等人才的培訓。

我們的學校相關教育課程也應該要趕緊改革了，過去偏重軟體技術的教育，產出了台灣現在的『軟體手工藝業』與『軟體零售業』，現在應該趕快效法製造業與營建業的教育，加速培養『製程/工程管理人才』，誠如前文所言，台灣軟體業最不缺的就是程式設計師(工匠)，而且也很容意被大陸廉價質優的程式設計師所取代。若以營建業為比喻，台灣軟體業最需要培育的應是建築師與專案管理師，而不是一堆堆的廉價工人。

以上見解,我個人認為只要是資訊產業的人都非常贊同,這是資訊人員應該要自我提升的作法,而我也相信目前很多資訊公司也都正在往這個目標在前進.

但當我們資訊公司一直在提升培養專案管理的人才時,而軟體使用者並沒有提升自身應該有的軟體素養,一味的只是要低價的軟體,只要能符合軟體使用者的需求即可,造成資訊廠商的削價競爭,最後使得資訊廠商沒有利潤,做完此專案即關門.軟體使用者也沒有得到日後很好的服務,而兩敗俱傷.這是我所看到目前資訊環境的窘困.

因此我認為,是否資訊公司在自我提升培養專案管理與軟體行銷人才之際,同時也應有同樣的方法來教育及提升軟體使用者應該有的軟體使用觀念及素養,這是我個人的淺見.

台灣中大型軟體公司必須先轉型。

如果只做專案沒有錢途、也養不起太多技術人員。
中大型軟體公司轉型建議 (軟體經營篇)
http://blog.udn.com/johnlins/1272864

中大型軟體公司轉型建議：

☆ 由專案轉變為模組化工具

☆ 建立領域別、行業別的專業形象

☆ 由模組工具轉為專業軟體產品

☆ 增加代工業務

大型軟體商現在把目光轉向新興市場的商用軟體公司
http://city.udn.com/57878/2556260?tpno=0&cate_no=0

國內軟體公司何去何從？
http://city.udn.com/57878/2405835?tpno=0&cate_no=0

台灣軟體業已經排名全世界第七且優於英國與德國，所以台灣軟體業應該沒有出路的問題，我們的產品應該可以直登英國與德國市場，台灣軟體業總算出頭天了，以後可看到產品上標示“Software parts made by Taiwan”。

據說SEI現在的政策除了要加強成熟度四、五級的稽查之外(導入時間很短的公司一定會被稽核到，所以要打混不容易囉)，最近聽說對於二、三級也要加強稽核的活動。不知道台灣的二、三級會不會在SEI的法眼之下全部現出原形呢？通過二級再走三級，過三級後再往上進步或者再參加複評以至少維持其現有成熟度的公司，不知道兩、三年後，還能夠維持這個水準呢？台灣是不是仍舊可以維持或超越排名呢？我想應該是不會吧。因為在台灣，CMMI的熱潮已經要過了吧。經濟部工業局拿納稅人的錢，慷全民之慨，扶持了這些公司(軟體產業及顧問業公司)，如果這些公司沒有進一步動作，經濟部工業局似乎該採取一些行動才對！讓我們一起來做好監督政府的工作吧！

台灣的成熟度在世界的排名看似不錯，但是是不是真的有那個實力？我從來不相信的，要造假太容易了，只要邏輯能力時間的能力還行，先把劇本寫好，按劇本把所有的東西該有的產出還有度量的數據資料有計畫地安排一下，是可以做到天衣無縫的，再加上工具的應用，那簡直是如虎添翼。所以在台灣裡採用自動化工具所做出來的度量與分析，以及各種管理工具做出來的CMMI要求的產出，我從來就不相信呢，儘管有人會說他們的工具有控管機制，可是全部都是自己的人在管理，直接連到資料庫裡，愛怎麼改就怎麼改，不是嗎？

CMMI推行了近5年，僅有輔導公司與通過CMMI的公司宣稱具有極佳的執行成效，但從未看過政府之採購部門和政府使用單位公佈推行CMMI前後有關成本、效益、專案發展時程等改善之比較資料。

我所認識的政府採購人員，他們私下的心得是Level 5、Level 3、Level 2與Level 1公司的產品在品質上並無太大的差別，Level 2-5的承約公司仍是人事流動頻繁、弄不清楚買方需求、版本控管形同虛設、QA不具實質效義且無權責進行品質監控形同虛設、不了解Verification與Validation的特性、文件追溯性極差、不清楚PMP、SEMP、TEMP、QAP、VVP文件的架構、不了解CI與CSCI的定義，甚至於有個案例是合約要求依據MIL-STD-498發展，但專案負責人連MIL-STD-498都未看過、且文件都是委外撰寫、...，幾乎與CMMI完全背離。

何不饒了國內的IT業?因為我們這些CMMI Level 1的現有產品一樣可以滿足政府採購部門的需求。

軟體公司要再升級, 磨練出專案管理的實務能力, 得要程式設計師和經理人懂得團隊如何運作, 專案怎麼管, 看什麼指標, 這樣才行. 這要讀溫伯格(Gerald M. Weinberg)所寫的《溫伯格的軟體管理學：系統化思考（第1卷)》, 它會說明如何作系統化思考, 什麼因素會影響什麼因素, 怎麼看, 這樣才能管好專案,也不會burnout.

該書的特色是，對於會影響專案成敗的諸多變數（如規模、複雜度、風險、顧客的要求、人力、時間、壓力……）進行動態分析；有許多例子可證明，若能在「控制點」上做好管理的工作，就可防止危機發生，或是不讓危機繼續惡化下去。

　　書裡討論到的主題包括：品質、軟體文化、品質模式、管理模式、反饋效應、壓力與工作績效間的關係、規模對應於複雜度的動態學、功能失常的偵測與反應、缺陷解決之道的動態學、以及顧客的角色等等。

程式達人要培養出管理能力, 溫伯格的書是最有用的.

Tristano59兄所指的書，把軟體管理的想法從PDCA, BPM, ISO/IEC 15504, CMMI換種方式來講。自有其教育意義。

但是在台灣，現在的情況並非工程師或者軟體開發人員自己願意造成的，甚至於我遇到的許多軟體從業人員，不論是台灣或是中國，多數的軟體工程師都願意多學，願意轉型。但是核心的問題出在哪裡？

說穿了，問題來自客戶、來自公司的老闆、經營者與管理者，在壓力下的一些亂了方寸的作法。但是從長遠來判斷，這種情況應該會是惡化的，至少在政府部門所呈現的是這個樣子，更少且非專業於軟體管理的公務人員從事資訊業務委外業務、更少的預算投入、更短的專案時間、更多來自於民間、審計政風單位的察查......，都讓政府部門人員如履薄冰，寧可多向廠商摳一些、不明青紅皂白的嚴厲，就算被告也不會是官商勾結，業務的瑕疵，主管也會幫忙大事化小、小事化無。

個人以為，這個問題，應該是先從政府部門人員的績效考核做起，訂出相關的績效考核標準，不再只是考績甲、乙、丙這種單純的分法，同時主管的主觀評定也要更少，讓一些定性與定量的指標去綜合描述出公務人員真正的績效表現，而且不能讓績效獎金的發放主導了最終的考績評定，讓從事資訊業務委外的經辦人，在本職學能上更精進，在專案的執行上更合乎管理的常規與實務，那麼，這樣的問題或許就能獲得舒緩與改善了。

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

個人非常同意泰龍兄的看法，
『…核心的問題出在哪裡？說穿了，問題來自客戶、來自公司的老闆、經營者與管理者，在壓力下的一些亂了方寸的作法。…』

簡單的說就是：
1. 客戶不要求軟體品質；
2. 軟體開發組織的經營者不願意主動追求品質。

之所以“客戶不要求軟體品質”，其原因簡單地說不外乎：不知如何要求與不願意要求。泰龍兄所描述的公務人員的情況，非常明顯就屬於這兩種，不再贅述。而它的解決之道，因牽涉層面甚廣（包括法律政治）不容易解決。但是，客戶並不是只有政府單位，其它類別的客戶(如：私人公司、金融機構…等)不要求軟體品質的原因與解決之道值得大家一同地探究。

另外，個人以為“軟體開發組織的經營者不願意主動追求品質”才是更嚴重的問題。因為，這會造成：當客戶要求軟體品質時，軟體開發組織也没有能力提供有品質的軟體。所以，個人以為當前最重要的就是要解決這個問題。而其解決之道可以比照：品質大師戴明當初在日本推動品管工作時的作法：針對各大企業的經營者與高階主管演講，以改變他們對品質的觀念著手。

因此，建議國內推動CMMI的專家學者先進賢達們，不要再只針對程式達人開課訓練。而應針對軟體開發組織的經營者與高階主管進行，以激起他們主動追求品質的意願。否則，就只有等待奇蹟(天生的軟體開發團隊的領導者)出現。上蒼啊！請祐吾民。

周茂松

對於 albertchou 的灼見真是令人佩服。要好好閱讀了。

中小型軟體公司的老闆的多半是有技術、沒有管理理則或受過好的工程經驗與作法調教的人員，但又不願意被人家使喚，在中、大型企業裡覺得自己被虧待，所以要自立門戶。

一些企業裡面，尤其是中、大型的企業，進入的多半會是從公家機關出來(其理由多半是為了拓展與政府部門的業務，畢竟政府部門還是個很大而且重要的客戶，所以離職退休之後，會被刻意地拉攏)，曾經扮演過管理階層或至少是經辦人，從公家機關裡又把那樣的做事方法在企業裡再演一遍，舊情綿綿呀....

個人是較悲觀的，因為利字當前，更何況「殺頭生意有人做•賠錢生意沒人做」(別挑骨頭說「現在的軟體業賠錢的多，還是很多人做」，因為多數生意人的想法是先低價搶到客戶，以後與客戶混熟了可以再賺回來，只是沒想到之後已無力再做該客戶的下一個案子，或者受到的委曲太多，不想再做，所以這是另外一段事，但基於人性，前者的說法是沒錯的，除非是功德會想義務幫忙)。

想想，建築也好、汽車製造也好、或者食品生產......，有哪些是生意人的品質意識真的抬頭的？由到處可見黑心商品的狀況可知，如果不是標準與法律的配合，尤其是法律規定成效最為卓著，然而，就算是法律規定好了，仍然有人要鑽漏洞。

在沒有軟體工程與品質相關法令的規範之下，只能靠政府部門本著良心做好相關軟體品質的要求了，政府部門要做好這件事其實不難，審計單位做好相關的稽核，是可以有效提升這方面成效的，像美國政府GAO(U.S. Government Accountability Office)，就扮演了這樣的角色，對於國防部門的資訊技術相關投資案執行成效的監督，而促成了CMM/CMMI的發展與成熟。

之所以這樣的事情只能從政府部門而來，主要政府部門從事的資訊業務，一定要有契約的約束的，可以使用契約讓廠商做事，如果所有政府部門都能夠按照工程常規要求每一件工作，那麼想執行政府部門資訊業務服務案的廠商就必須依約、依工程常規、管理常規行事，而該廠商做的政府部門的案子愈多，那麼愈能夠將這些常規在其公司裡深化與養成，而其員工在某一個層次後會在業界裡流動，也就是可以產生擴散的作用，從量變而質變，這種質變會從底層向上感染的，這個時候，對於企業來說，即使老闆不講求品質這件事，但是真正在做事的人員都養成了好的工作文化與習慣，仍然能夠將組織帶向正面的道路。如果在沒有法令的規範下，對於管理者要經由教育來改變，使之自發性的去追求品質，會事倍功半，或全然沒有效果的。就像工業局推動的CMMI(現在熱潮已退)，有那麼多的公司去聽了觀念層次的東西，辦了那麼多教育訓練，觀念改變了沒有？老實說，結果是言者諄諄聽者藐藐，還是沒有辦法真正解決問題。因為最終企業還是要面對客戶的要求，面對履約問題，而面對的客戶與履約督導的單位，並不見得懂得那些品質的概念與工程及管理常規，不會理會你怎麼去完成專案、產出產品的。而在工業局花了那麼多錢之後，又有多少CMMI二級的公司追求CMMI三級，又有多少CMMI三級的公司會去追求高成熟度？顯而易見的，其實大家都知道，這些品質大師唸的是什麼經，但就是過不了「錢」這關。最近個人買的所謂「股王」出的PDA，刷了從其客服網站下載的WM6.1更新版本，還是針對該產品的版本，結果下載之後問題也很多(可以到網路上搜尋一下，國內外都有同樣的問題回報)，有人問其客服：什麼時候新的版本可以出來修正已發現的錯誤呢？客服的回答是：「工程師要看有多少人回報這些問題」，從這個問答當中就可以知道，大家都知道要滿足客戶的需求，但問題是，一個公司的經營者願意花多少錢去滿足客戶多少的需求呢？這個時候，是否客戶該發揮其影響力呢？如果一萬個客戶有問題，只有十個客戶反映了，工程師可能不會花時間修改，但是如果這一萬個客戶都反映，那麼，可能不但得修改，還要列為第一優先，不是嗎？真正要讓產品做好，不能光靠廠商的管理者的自覺與自動，而是需要客戶發揮力量共同來要求才有可能的，客戶拿到爛產品的時候，不能消極地自認倒楣，提醒自己：「下次不買該廠商的就好」，而是要積極主動地講出你的不滿意，要求廠商把事情做好，這樣才有可能真的促使產業提升吧。當然，能夠制訂相關法律就更好了，資安有「電腦處理個人資料保護法」，軟體業是不是也應該要有「軟體品質保障法」，以保障軟體產品的製程與品質呢？對於軟體品質的保障，會推及對使用者的權益、乃至於對使用者或相關利害關係人生命財產安全的保護。

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