( 轉載自 97/6/20 中國時報 [ 時論廣場 ] )

三千個軟體工程師哪裡找？

• 2008-06-20
•【中國時報】
•【程家麒】

日前鴻海集團決定啟動高雄投資計畫，並將進駐高雄軟體園區，未來五年內預計創造三千個軟體工程師就業機會，外界多將其視為響應新政府振興經濟、促進南北均衡發展政策的壯舉，為高雄市沉寂的經濟發展帶來了大利多。筆者認為其意義與影響值得我們重視。

鴻海集團對外揭露的計畫主要將投資包括結合先進感測技術與無線網路的安全監控軟體、Linux核心及應用軟體平台、電子商務營運平台及企業應用資訊服務軟體、無線通信嵌入式軟體等，幾乎都是結合資訊硬體產業與應用軟體內容的深具市場潛力發展項目，其是否能引領競爭力強大的台灣資訊硬體產業，導向高附加價值的軟體創新研發領域，產生示範作用與群聚效應，值得我們期待。對於長期受限於市場瓶頸之苦的台灣資訊軟體產業而言，若能夠與資訊硬體產業緊密合作，或許也將開闢另一個更寬廣的發展方向與市場空間。

然而，鴻海集團此一投資計畫如果需要三千個軟體工程師，甚至因應未來歐、美、日等國際知名企業來台投資設立軟體研發中心的需要，筆者認為我們馬上會面臨的就是人才供給的問題。捫心自問，目前國內足夠供應這麼多符合需要的軟體工程師嗎？

過去台灣的資訊軟體開發以小型規模居多，人才需求也是以技能性的程式設計師為主，因此不論學校或民間的電腦培訓機構，包括筆者於民國八十九年到九十一年負責執行，由當時行政院劉兆玄副院長推動的「行政院加強資訊軟體人才培訓方案」，也都是以培訓電腦程式設計師為主，雖然充分因應了當時國內各行各業導入電腦化的人才需要，但是結果只是延續台灣小型軟體商品和小型軟體公司的林立，軟體產業結構與競爭力並沒有因此出現太大的改善。

近年來全球軟體工業的發展已經出現重大變革，今天的軟體研發主角已從過去單打獨鬥的程式設計師，變成分工合作研發的軟體工程師團隊。前者重視的只是創意與程式設計技能，後者重視的是標準、品質與製程管理。因此，今日的軟體工程師已與傳統的程式設計師有所不同。一個專業軟體工程師不但需要懂得程式設計方法與需求分析技術，還需要瞭解軟體製程的相關標準，以及軟體製程有關的測試、品保、文件撰寫等知識，甚至還需要具備專案管理方面的基本觀念。

而許多國內企業因為面臨大型資訊軟體開發的需要，或有感於過去缺乏管理的軟體開發方式問題重重，已紛紛要求其程式設計人員進行在職訓練，協助其轉型升級為專業的軟體工程師。反觀目前國內大學資訊工程、資訊管理相關科系或民間電腦培訓機構的課程內容，仍舊偏重程式設計知識能力的培養，對於軟體工程觀念的教育仍嫌不足，恐將成為未來軟體工程師供給面的隱憂。

因此，筆者建議教育當局宜加速相關課程內容的檢討與調整，以縮減學校教育與企業實務需求的落差。同時我也呼籲從事資訊軟體人才培育的教師，應鼓勵同學們平時多加強軟體工程與管理方面的知識，瞭解專案團隊開發軟體的分工運作方式。因為未來像鴻海集團這種國際級企業需要的軟體研發人才，應是具備團隊合作觀念的專業軟體工程師，而不會只是善於單打獨鬥的傳統程式設計師。

（作者為前中華民國資訊軟體品質協會理事長）

要找 3000 個軟體工程師也許不難，但要找 100 個懂軟體工程標準與系統工程標準的系統工程師就很難了。要再往上找既懂 SAFETY 標準又懂軟體工程標準與系統工程標準的工程師更難。

　就像大陸網路上所講的“ 帶有軟體控制的產品若能符合 EN50126、EN50128、EN50129、RTCA/DO-178B 或 IEC 61508 標準的產品，價值馬上翻百倍 ”。 因為這些產品目前都應用在軌道系統、飛機、高速鐵路、化工廠等高安全性領域，同時也是高附加價值。

　台灣還未能由 CMMI 跨入IEEE-STD-XXX 標準，所以軟體工程也僅能做低風險領域產品。

這個問題其實並不在於個人的身上，而在於公司本身的策略與基於策略所建立的基礎建設。
這樣的問題雖普遍存在，並產生了非常大的反差(因為懂得這些標準的公司畢竟是少數)。
我們不能去期待所有的工程師是十八般武藝都精通，甚至於超越工程師的專業與技能的範圍。
精通那些標準，對於工程師是一種加分而已，因為基本上用不到的。當然有一天，他們真正到達了分析師、架構師的層次時，這些就有意義了。
但對於一個公司而言，其實它不能夠去冀望每個工程師都了解所有的標準。每個工程師在學習與積累經驗的時候，並沒有辦法自己做選擇，也不是所有的公司都需要用到相同的標準，更何況標準推陳出新，就算是同一個標準也會與時俱進的，所以工程師是否有義務隨時追蹤這些最新的標準，值得商榷。我反而認為工程師就是該學好系統工程、軟體工程、程式語言、資料庫設計技術等等基礎的東西。而標準與工程的過程則是公司的事，這些是一個公司的基礎建設，一些可以再利用的資產，公司有責任去建立這些資產，讓工程師、分析師、架構師、專案經理等人依據專案、產品與服務的需要，檢索、了解及採用。如果公司認為這些標準很重要，並且公司產品或服務必須追求與符合的，那麼公司本身就該負起責任，辦理這些標準與過程的教育訓練，讓公司的相關人員都了解、遵循，並落實到產品與服務上。

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

我非常同意泰龍兄的看法：這個問題不在個人而在於公司。

我的意思是要看鴻海(或其它任何其它的公司)如何經營與管理這個新公司，如果它要用新的方式(不同於國內大多數軟體組織現行的方式)來經營與管理這個公司。那麼，它必然需要各種不同專業能力的軟體工程師與系統工程師以及其它專業人員共同合作，方能立足於國際舞台與它國同質的企業競爭。

所謂各種不同專業能力的軟體工程師，包括：程式設計師、軟體設計師、需求工程師、軟體架構師、測試工程師、軟體製程工程師、軟體品保工程師、軟體專案管理師、資料庫管理師…等不一而足，其種類有多少端視組織如何分工而定。他們各有各的專業技能與知識，不是每一位(或任一位)軟體專業工程師必須具備全部的這些技能。譬如：程式設計師是不須要瞭解CMMI的，也不需要瞭解全部的CNS14837；但是，他必須看懂以UML(或其它類似工具)所呈現的軟體設計說明並以要求的程式語言將其轉換成程式碼，而且在這個過程中遵循公司訂定的程式撰寫風格並恪遵工作紀律(意即：不會在程式碼中自行加上設計說明書中所沒有描述的功能)…。需求工程師、軟體專案經理、測試工程師…等也不一定需要懂JAVA、.NET…等技術。

當今優質的軟體，必然是經由具有各種不同專業能力的軟體工程師與其它專業人員共同合作所完成的。

然而，這麼多種的軟體工程師在國內一直被『軟體工程師』這個汎用的名稱所統稱了。因此，談到相關的問題，總是以軟體工程師要懂什麼…來論述。好像軟體工程師不懂這些是多麼的不成材。其實問題不是這樣的，真正的問題是：用人的公司會不會以不同的專業條件來招募、任用、領導、管理、培訓…這些不同的專業人才。軟體公司績效的好壞主要因素不在於它的成員，而是該公司的領導人。衷心寄望：台灣能儘早出現真正善於領導、經營與管理軟體開發團隊的公司領導人。

周茂松

要從程式設計師邁向擁有一點管理能力的leader或manager，可以讀溫伯格(Gerald M. Weinberg)所寫的《領導的技術：如何成為問題解決型領導者》，書是專門為technical leader而寫的，不過書裡清楚解釋了從技術專家到leader或manager有什麼差別，要如何去轉型。要付出什麼代價。評價很高的一本書。

其他一些溫伯格的書，軟體工程師也可以利用。例如《從需求到設計》這本書談需求分析，如何因應那些「自己都不知道自己要什麼」的客戶。

還有《溫伯格的軟體管理學：系統化思考（第1卷)》，提出利用系統化思考，以便綜觀全局，有效管好專案。書裡一開始就提出軟體公司的行為模式，分為：

模式0（渾然不知）：我們都不知道我們正循著一個過程在做事。
　　模式1（變化無常）：我們全憑當時的感覺來做事。
　　模式2（照章行事）：我們凡事皆依照工作慣例（除非我們陷入恐慌）。
　　模式3（把穩方向）：我們會選擇結果較好的工作慣例來行事。
　　模式4（防範未然）：我們會參照過往的經驗制定出一套工作慣例。
　　模式5（全面關照）：人人時時刻刻都會參與所有事務的改善工作。

書裡強調要用系統動態學的方式，來觀察專案、人發生了什麼事。書裡提到的主題包括：品質、軟體文化、品質模式、管理模式、反饋效應、壓力與工作績效間的關係、規模對應於複雜度的動態學、功能失常的偵測與反應、缺陷解決之道的動態學、以及顧客的角色等。

如果軟體公司真能讀過這本書，就會了解到專案團隊要如何維繫，也更能讓大案子也成功吧。

( 轉載自 98/5/17 聯合報 [ 民意論壇 ] )

知識、管理性 - 軟體人才新方向

• 2009-05-17
•【聯合報】
•【程家麒】

近日克魯曼訪台和國內青年學子代表對談時，有學生提問擔心畢業後面臨失業的問題，克魯曼建議在學青年要培養溝通能力，在學校時要訓練自己的分析、解決問題的專業能力，專業技能越好，就業機會也越大。筆者認為，克魯曼的建議其實也給台灣許多面臨失業壓力的軟體人才，指引出了一個新的機會和方向。

印度近年發展成為全球欽羨的高利潤國際軟體外包設計王國，其成功關鍵最重要的因素，是在客戶當地必須要有專業且溝通能力良好的系統分析專家、需求工程師、軟體架構設計師，確保開發出來的軟體符合需求，再加上成熟的專案管理和品質管理，確保如期、如質、如預算完成大型複雜的軟體專案。

台灣軟體業者幾乎都是中小企業，除了系統分析和軟體程式設計人員之外，沒有系統架構設計、需求管理、專案管理等人力編制，軟體人才培育也不重視分析、溝通與管理的專業能力訓練，因此常見大型軟體外包專案，承包的業者和採購者雙方的軟體能力成熟度不足，不但寫不出標準的溝通文件，開發出來的軟體多因不符合使用者需求而一改再改，往往造成兩敗俱傷。

據估計全球軟體外包市場到公元二○一二年將達一兆美元，雖然目前中國大陸、印度、菲律賓 … 等低成本、高素質的軟體設計人力不虞匱乏，但是具有分析、溝通和解決問題專業能力的軟體規劃、專案管理等核心人才仍嚴重不足。

因此，建議台灣軟體人才培育方向應該趕緊調整，減少培育技術、作業性的軟體設計人才，加強培育「知識、管理性」的核心人才，如此不但可以增加軟體人才就業機會和薪酬，也有助於改善專案外包供需雙方的軟體能力成熟度，提升台灣軟體業的國際競爭力。

（作者為前中華民國資訊軟體品質協會理事長）

大部分學校剛畢業的軟體從業人員認為只要會寫程式就是軟體工程師, 可以從事軟體開發工作。 但是在學校的軟體開發經驗非常有限, 甚至有某些比例的同學, 程式作業是抄襲的, 到了業界常因工作壓力, 而拼湊出 leader 賦予之任務, 不僅無可重複使用之價值, 甚至造成後續之維護問題。 我曾聽到一新竹國立名校資工研究所畢業的工程師與 leader 之對話如下:

Leader: “為何新版本之功能出現舊版本未有之 bug? 這出現 bug 之模組是你維護的”。
工程師: “我發現原模組之功能有不足之處, 但不易改寫, 我就重寫原功能”。
Leader: %?$#...

就因為如此, 產品延誤出貨時間. 諸如此類例子經常可見。

軟體之工作, 需要緊密之 team work. 因此大部份學校畢業之軟體從業人員, 受雇用後皆需重新接受職前訓練; 筆者曾要求所有新進軟體工程師先進入SQA部門見習/工作 3個月, 以了解產品之功能與品質之重要性。

在台灣要召足 3,000名 qualified 軟體工程師是一件艱鉅之任務。 首先談 interview 時間, 保守估計每位工程師動輒需 1 ~ 3 小時 (含人資與各級 leaders 面談)。 以筆者經驗, 10 份履歷約可篩選出2-3名面談, 面談5名可錄取1-2名, 錄取後報到率, 可能介於30-70％, 以效率計算, 主管每花10-15工作小時可成功錄取1-2名軟體工程師(但可能需收集20份履歷); 若要成功雇用3,000軟體工程師, 可能要收集30,000 - 60,000份履歷, 加上面談時間, 工程浩大可想而知。 且軟體工程師之訓練是非常具挑戰性的, 若個人discipline與自我要求不足, 離職率會很高。

筆者在負責軟體工程之品質訓練時發現, 大部份工程師對軟體品質程序不感興趣, 對軟體需求也不重視, 當接受到任務時只想盡快把工作做完。 在台灣業界, 網路與消費性產品對軟體的需求很大, 但主管大都是機械或硬體背景, 軟體的進度要求要在硬體與機構完成前做結案. 如此也影響軟體品質, 但品質一但出現問題軟體人員經常被問到為何有bug? 而修復bug之patch, 也經常因無法驗證而失敗, 所以當軟體工程師若韌性不足, 時間一久, 很容易陣亡。

目前從事軟體開發工作之人員來自不同領域, 並非所有工程師都接受過專業訓練, 若能在學校邀請業界人士講授相關軟體設計需求, 並建立學生正確軟體設計觀念, 將有助於有志從事軟體同學, 踏上正確之路. 也為業界強化未來新進人員之素質。

- 張道宏

現在台灣自稱是 " 軟體工程師 " 的人好像不少, 但是真正優秀的專業軟體工程師在哪裡？這還真是個大問題.

前面各位先進的文章真是一針見血的道出問題關鍵所在, 值得大家省思.

最近有位朋友寄了一個名為：『從軟體手工業談起』的簡報檔，其目的是希望將目前軟體手工業轉型為軟體工業。

個人以為要建立任何一項工業，其首要之務即為：有足夠的合格從業人員。當然，軟體亦不例外。所以台灣要有軟體工業，第一要件就是要有足夠的軟體從業人員(意即：合格的軟體工程師)。一個企業的投資計畫就要三千名合格的軟體工程師，“找”起來尚且困難重重。台灣要有一個軟體工業，所需的合格從業人員當然遠遠超過於此數字，那不是要難如登天了嗎？

凡事求之於外必然困難重重，因為它操之於人；反之，求之於內就較為容易，因為它操之在我。所以，要從外部“找”到合格的軟體工程師，不如將內部的軟體手工業的“軟體工匠”轉“變為”軟體工業所須的“合格的軟體工程師”。

雖然這也是一件艱巨的大工程，但相對而言是較為可行的。不過要這麼做，首先要知道什麼是“合格的軟體工程師”。個人以為一個合格的軟體工程師必須具足兩個要件：其一，該名工程師必須打從心底接受“Software Engineering Code of Ethics and Professional Practice”，並致力以此做為其行為準則。其二，該名工程師必須於SWEBOK Version 2004的10項知識領域中至少有一個領域，能夠具足必要的知識並在不違背其知識內涵的情況下，獨立運用該項知識以執行工作。

有了這樣的標準，工程師個人可以將它作為努力的目標，致力於最短時間內使自己成為某一領域(譬如：需求工程、軟體設計)的合格的軟體工程師。而欲將自身由“軟體手工業”轉型為“軟體工業”的組織(不論這個組織小至一個專案團隊，或大至一個公司或整個台灣軟體界)，則必須於其組織範圍內，具足10個知識領域的合格軟體工程師，且每一知識領域的合格軟體工程師的數量都是足夠的。那麼，那個組織就是一個以從事“軟體工業”的組織。

以上是個人對此一議題的一點淺見，雖是淺見，卻也是個人對台灣軟體界的深切期望。最後，祈請業界前輩先進不吝指教！願早日見到

台灣軟體工業　成型！與成功！！

周茂松　敬上

老是在講這一些不知肉糜為何物的話，看了覺得各位大大根本不知道軟體工程師是很悲哀的生物嗎？

要能懂聽懂客戶話語裡面的深層需求，還要會唬爛軟體開發工程的正向開發流程，實做上卻總是被客戶催促快一點上線，要做又要快又要好又要簡潔易懂的軟體，專案出想法一堆人，實做卻就咱兩線上開幹。除了資料庫、報表、UI、還要搞定跟其他已經Run了許久的系統連結與整合，強一點的還得去設法想一些數值模式放在你的軟體裡面，然後給你三個月的時間。重點是一個人同時不是只有一件案子要搞，新出來的技術Web Service啊，老技術從如何監聽封包或RS232介面轉成資料庫裡面的數據資料都得辦法搞懂。

怪不得沒看到軟體工程師寫到40歲的，軟體開發環境不比打棒球好啊！

對liubi的說法個人有些小看法。

一個人事系統從無到有，多久可以完成？我看過最短的是半個月的時間(利用暑假時間完成的，半個月的開發工具學習時間，半個月真正投入開發的時間)！而且，開發者不用寫任何一行程式，因為開發人員根本沒有程式設計的經驗，而且是非資訊科系的大學在學學生(大學一、二年級的學生，這可不是學生的程式設計課程專案，而是實實在在，在真實環境中使用的系統)，人數也僅有兩個人而已，如果用一般的開發方式，就算不寫文件，也要三個人、半年的時間(亦即，至少18個人月)才能完成。寫出來的東西絕對可以結案，而且程式碼是java程語言，系統效能很好。我提這件事的目的，不在於炫耀這個人事系統的開發期有多短，這個系統做出來，沒有任何文件，但是修改並不困難，因為是應用系統產生器直接做出來的。那麼，程式設計師的價值何在？我遇到很多程式設計師，年紀四五十歲了，還在寫，包括這個應用系統產生器的作者在內，是位將近六十歲的人，該應用系統產生器的每一行程式均出自他的手。

我說句不客氣的話，台灣絕大多數的軟體從業人員，只能算是程式員，而沒有辦法稱為"工程師"，因為台灣軟體從業人員在專業能力及職業道德上仍需要再加把勁。當然這種情況的是因為歷史及各種包袱造成的。但是，軟體從業人員應該要一起努力把這種情況扭轉過來才對。如果我們現在還是普遍認為程式完成才是軟體專案的唯一出口，那麼這件事情絕對只會更加惡化，而且是最終，軟體工程人員會被使用應用系統產生器的非資訊專業人員所取代，(不要以為應用系統產生器一定有限制，不好用，最終沒有辦法取代人腦，但是技術不斷進步，問題都會被解決，而且會做得更好，功能更加包羅萬象，迎合更多的需求的)，當然，走到這一步時，台灣的軟體業大概就瓦解了。

如果軟體開發流程是唬爛就行的話，那麼，軟體從業人員的苦難是不會被解除的(尤其面對應用系統產生器的競爭會更加惡化)，也不可能做到真正朝九晚五，真正正常上下班(不把工作帶回家做，進影響到正常的家庭及社交生活)。如果，軟體從業人員一直以自己寫的軟體可以run、客戶接受一項項個別的功能，就很有成就感或者自感驕傲，而不是為了能夠完成的是一套高品質、容易維護的系統而自豪的話，那就永遠走不出軟體行業的地獄，無法走向光明坦途的。面對應用系統產生器的競爭，軟體從業人員要能夠生存，就是要會做並落實軟體工程過程，要樂於寫文件，因為當系統更加複雜時，各項文件就更形重要了，就算是使用應用系統產生器開發系統，也需要寫文件的，這也是應用系統產生器作者所承認，因為畢竟人腦的思考與記憶還是所有限制的。

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

感謝回應，基本上我們這些小人物講話沒什麼多大份量，只是單純希望一些發的了聲音的多體會現實的苦境。