今天我們來討論一個很有意思的議題，那就是台灣高教普及和電子業興盛時養成的大批軟體人才，若全部導入軟體業，不就能夠振興台灣科技業了嗎？
沒錯，依照常理，台灣的工程師薪資水準相較其他先進國家如此「物美價廉」，而且台灣人受高教比例很高，照理來說應該是先進國家爭搶的重要軟體研發據點。
但是，事實卻不是如此。國際軟體巨擘如 Google、Facebook、微軟、IBM 等，在台灣有一些小型的硬體研發和工程部門（如 Google 的 Chromebook），但是真正的亞洲軟體工程和研發卻幾乎都是以北京為據點，台灣則以業務據點為主。一些廠商甚至將台灣業務的工程需求外包給台灣的工作室和承包商，不養自己的工程團隊。
有在美國科技業當作工程師或 PM 的朋友都知道，軟體公司的工程師和軟體承包商（Contractor / Consulting firm）的工程師，不論在能力、思維還是薪資都有天壤之別。
如果今天是講究創新、功能和效能的軟體公司，都會自己養工程團隊（如 Google、微軟、Facebook、IBM 都在美國都用高薪養了數千甚至數萬名軟體工程師）。如果台灣工程人才俗擱大碗，為什麼外商在台灣反而是常發包而不是自己養團隊呢？
敝人過去幾年在台灣擔任數家台灣公司和團隊的業師和顧問後，有個小理論或許可供解惑，那就是軟體工程不是單單寫程式和管理專案就好，還有許多網路架構、計算科學、科技管理、營運管理等知識來幫助工程師和科技管理者來設計有效的解決方案。
今天的科技業已經不是1+1=2，而是要靠有效管理發揮成級數的增長。台灣不乏會寫程式的人，但是過去全球軟體業突飛猛進的十餘年，台灣卻因為達康泡沫心有餘悸，並未積極投資，在管理方法與管理人才上積極補強。因此，台灣今天面對的問題不是工程師不會寫程式，而是工程團隊不論在個人還是在組織上的管理觀念與方法都已嚴重落後，導致軟體工程的表現不彰。
達康泡沫後的十年
西元2000年以前，世界上網人口不過三億多人（當時先進國家就佔了七成以上，美國加日本就占了三分之一），當時台灣算是軟體產業發展相對先進的國家。不管是入口網站、搜尋引擎、新聞群組、影像處理、防毒軟體還是影音播放，台灣都有穩健成長的科技公司。
當達康經濟泡沫化後，以美國為首，許多科技公司接連倒閉，主要原因在於網路經濟產值（當時多以廣告為主）仍只是在網路相關科技公司的小池塘中漂浮，並沒有深入與實體經濟結合。網路經濟崩盤，台灣軟體業也不免蒙塵。台灣政府與投資人也對網路業失去信心。
而達康經濟泡沫後，美國方面復甦不久，軟體業馬上揭開序幕：一場桌用軟體大廠（以微軟為首）與大型網路公司（Google為首）的兩強之爭。2000年初期的微軟（與 IBM、昇陽等）是標準的保守勢力，憑自己在軟體業三十年的版圖活埋了網景（Netscape），同時也強力壓制住了雅虎等大型網路公司的發展。反觀今日的微軟已經捨棄原本的 Windows 帝國，走向雲端、跨平台、開放原始碼和分散式運算，轉型成為了標準的網路公司。
另一方面，2000年初期的網路公司仍搔著腦袋思考要如何走出廣告收益來擴大版圖跟傳統軟體公司抗衡，但其首要之務是突破微軟、昇陽、IBM等傳統軟體巨人的封鎖線。這樣的角力作用下，催生了許多新一代的網路技術、開發流程和管理方法。
傳統軟體公司產品開發的模式就如同工廠生產線，所有的產品都訂出了企劃書（如工廠的組裝清單），然後將工作分配給工程師、設計師（美工）後，再將所有的成果拼裝成產品，經過測試後，就裝箱成為桌用軟體上架。至於軟體好不好用，等到市場反應後再重新訂出新的企劃書，重回生產線。
而網路公司的產品開發模式則像是神經網路，Google、Amazon 等網路公司已看到了網路與資料互連所產生的即時回饋必將成為產品開發流程和產品本身的一部份，必須將各種資料妥善管理、各種軟體工具自動化，才能夠即時通知公司內的各種設計、工程和管理人才來改進產品。因此，大型網路公司的方向，就是要跳出桌上型作業系統，將一切搬到網路上，才能即時採集資料。（小趣聞：後來網路平台盛行所仰賴之 Ajax，其實出自微軟2005的 IE，最後成為W3C標準，也就是說微軟自己的產品幫助網路公司推翻 Windows 帝國。）
這場角力賽持續了將近十年，結果大家都知道：網路公司徹底擊敗了傳統軟體公司，改變了美國的科技業產品開發方法。Facebook、Google 與 Amazon 躍升為科技巨擘，而微軟全盤轉型成為網路公司（最大收益來自於企業運算、雲端服務、數位內容/遊戲與辦公解決方案，Windows 僅占公司營收不到15%）、IBM Business轉型成為 IT 與軟體顧問公司、昇陽則是被甲骨文併購，而甲骨文本身也投資軟體顧問業務來平衡資料庫軟體市場的相對頹勢。
由此可見，這場角力對科技業的衝擊之大，已經不純粹是產品和公司業務的改變，而是科技公司內部之開發、管理等方法之全面革新。
若說台灣再次對軟體業和網路業燃起興趣，是在2008左右，那我們必須很擔憂的一點是：台灣的軟體業幾乎完全錯過了這場革命。
我們可以學習 Node.js、Mongo、Python/Django、Hadoop 等新工具，但是最後我們碰到的瓶頸是：究竟有誰能夠管理新一代的工程團隊？台灣科技業的領導人，已經是上一個（傳統）軟體世代的人了。這個世代的人在美國已經被淘汰或強迫轉型，但是在台灣，他們卻是唯一有實戰經驗的人。
看到問題了嗎？美國在達康泡沫化後廝殺至血流成河的近十年，累積了諸多新一代的科技和產品管理人才，而台灣呢？
台灣的軟體新創，必須先克服過去十餘年留下的重大管理斷層。
這問題一點兒也不單純。
科技方法論革新的十餘年
所以，美國為首的科技產業過去十餘年究竟發生了甚麼樣的革新，才造成各種管理方法的重大改變呢？
敝人認為主要的變革有：問題導向與跨領域專長融合、服務導向架構、元件化與模組化、雲端與平行運算、主動與被動品管流程、使用者中心設計六項為主。
這些重大產業變革，使得軟體工程組織走向扁平化、自動化、技能導向與資料導向。
問題導向與跨領域專長融合
達康泡沫前的傳統軟體業，跟其他產業一樣，是非常職務導向的。
許多公司的團隊都是跟隨某種公式組成：高階主管、專案管理、行銷、業務、設計、工程、品管、IT、會計等。以前的觀點就是認為只要這些專業找齊了，公司就可以開發產品還是承包案件了。而運作方式就像生產線一樣，一人做完丟給下一個人，最後只要符合企劃規格，就可以交差結案。
這種模式在2000年受到很大的挑戰，因為許多科技相關的研究機構研究的題材，如機器人、人工智慧、生物資訊、化學資訊等，都已經不是傳統的職務人才可以勝任的了。
以機器人學為例，一位機器人工程師一般來說都要懂得偵測辨識、資訊處理和機體控制三大塊。雖然不需要是專家，但這代表做機器人的工程師必須要同時懂基本的電機、資工、機械、工程數學，可能還有認知心理學。
從傳統職務分配的角度來看，這位機器人工程師要升任軟體工程師絕對不夠格，但是因為他專精於機器人整體架構的工程問題，他卻可能是機器人產業最好的工程人才。至於他在個別領域需要協助的地方可以再請該領域專家來幫忙。
因此後來衍生出來的許多新科技業人才，如生物資訊專家、機器人工程師、資料科學家等，象徵了我們的團隊已經走向一種問題導向的思維，意思就是針對想解決的問題去尋找所需要的領域知識與經驗。回到軟體團隊來說，傳統團隊會找網頁工程師和美工，但是現在科技業的需求包含行動科技、後台架構、各類資料庫、平行運算、視覺設計、UI、UX 研究等，並不是每家公司都需要所有專長，因此公司可以針對所需要的專長，去找擁有不同組合的人才來滿足需求，而不見得有一須遵循的團隊公式。
而台灣碰到的問題，在於用傳統的軟體團隊思維去看待現代的工程需求。我們可以從台灣新創和其他公司的求職內容發現，大部分的需求都是非常職務導向（比如說要會 Javascript、NoSQL、Photoshop 等），但是卻很少從解決問題的角度去尋找人才（比如說懂得設計高頻交易系統的工程師人才）。台灣現有的工程團隊思維長期下來，會創造依賴性很強、中斷率很高的團隊。主要原因在於團隊成員的工作都是以職務責任為主，各個成員對於公司產品所解決的問題缺乏全面性的基本知識，變成只要沒有專案主管盯的情況下，團隊很容易就會你等我、我等你的情況，而不懂得自己去調配管理自己的時間。因為團隊成員不懂問題的全面性，最後就是一個號令一個動作，雖然都是設計師、工程師，這種團隊的管理成本（時間、人力與金錢）會比以問題導向籌組的團隊高出許多，開發效率亦不彰。
先前提到當網路公司向傳統軟體巨擘宣戰時，網路公司紛紛致力於發展網頁相關技術（2006年前後更大幅投入行動科技相關技術）來跟桌用軟體功能一較高下。兩陣營的摩擦，加上非同步網頁技術（如 Ajax ）和行動裝置的普及，使得網路公司與傳統軟體巨擘大幅投資服務導向架構（ Service-oriented Architecture ）。
所謂服務導向架構，其實簡單來說，就是透過非常簡單、無使用者介面的網路服務去傳送資料給介面，使網路和手機軟體介面可以非同步載入新資料，達到跟桌用軟體類似的更新率，而無須重新載入整個網頁。當時微軟和昇陽的企業式運算架構偏好 SOAP（Simple Object Access Protocol）服務架構，而其他網路公司則以走向 Restful（Representational state transfer）為主。如今，服務導向架構已經成為重要的架構設計方法，一些網路軟體架構（如 Node.js）幾乎是專為服務導向架構為基礎去設計的。
而服務導向架構對於管理有甚麼樣的衝擊呢？
其實這衝擊的概念很簡單：當服務導向架構將後台和介面拆開後，新一代的後端、前端與行動端工程師的工作不再需要被綁在一起，只要大家使用的資料格式一致，團隊可以有不同專長的工程師平行開發而不需要擔心踩到對方的腳。另一非常重要的優勢，就是服務導向架構下的產品，可以達到修介面完全不會影響到資料端，一來失誤風險大幅降低、二來就是單一團隊成員可以進行微型更新。在這種管理方法下，團隊甚至可以一天內把資料庫整個換掉，只要資料格式不變，產品可以馬上上線運作。當產品平台流量快速成長，團隊可以針對各個部分進行漸進的調效和升級，而不需要一次性的推出整個平台的調效方案。
這種管理方法的革新，對團隊的意義不是技術能力的高低，而是規劃能力的重要性提升了。若事先產品的架構規劃得好，團隊合作不但效率高、耗時短且出錯機率低。
台灣的許多工程團隊（尤其是新創公司）在這部份碰到的挑戰就是團隊並沒有花足夠的時間去規劃軟體架構，就叫工程師開始動手做事了。甚至有很多人會把特定語言架構（比如說用 Python、用 Node.js）當作規劃問題的萬靈丹。其實最終的問題不再於你用甚麼語言或是甚麼軟體架構，而是一開始是否有將產品內部的資料管理、資料介面規劃好，接著才跟工程師們討論要如何分工。
如果完全不做規劃就隨便叫工程師「ㄟ，你先把這功能寫出來看看」，那他做事時完全不會考慮如何跟其他工程師的程式碼溝通，更不會考慮到未來產品需要增加功能或是需要調效時，要如何才不能局部作業而不需將整個功能摘下來開刀。
初期的規劃是一種管理科技負債（Tech debt）的方法。一開始投資幾天的架構規劃時間，長時間下來可以剩下數周、甚至數個月的開發和品管成本。這是台灣團隊需加強的地方。
元件化與模組化
達康泡沫後，開源社群的蓬勃發展也幫助軟體工程進一步發展—特別是在模組、元件和函式庫的普及化。
在程式和軟體架構層面，相較起2000初期的語言，今天的架構與語言幾乎都有統一的模組管理工具，讓工程師可以輕鬆搜尋和安裝新的模組和函式庫而不用手動修改程式碼。不管是 Java 中的 Jar、.NET 的 Nuget 還是 Ruby 的 Gem，全套式的模組管理已經非常健全。
而許多語言之上，則發展出了更多的上層軟體套件，如 Javascript 上發展出的 JQuery 或是跨手機平台的 React Native 和 Xamarin 都是很好的例子。這些套件將本身語言中的一些複雜度簡化，進而自己發展成為另一種技能。
最後就是軟體平台和系統的元件化。以內容管理系統為例，從 Drupal、Joomla、Wordpress 到 Sharepoint，所有的系統都有許多可下載的新元件來增加功能。而工程師也可以透過撰寫自己的元件來跟其他軟體平台溝通。
元件化與模組化的潮流對產業的衝擊，除了減少軟體開發的時間外，更促進了軟體平台的整合和自動化。對人力資源而言，團隊從以前的生產線工程模式，走向精簡型的團隊。比如說過去一位工程師可能專精於寫前端介面，但今天由於自動排版元件、資料彙整元件的普及化，單一工程師可以用更短的時間搞定前端與後端，過去五人團隊做的事情今天可能一人就可以完成。
台灣在這塊的難題在於達康世代的軟體公司使用的平台技術已老舊，無奈公司成長緩慢，遲遲無法進行升級；而今天新創團隊雖多也願意接觸新的模組化平台潮流，但是卻缺乏實戰開發和管理經驗，因此很難有效地運用模組化平台，常常過度信奉特定的模組化套件而缺乏判斷能力，無法對症下藥。
模組化平台的管理難題不在於開發，而是在於根據公司的發展情況選擇合適的整合層級。有些套件只是單純整合前端（如 Twitter Bootstrap）、有些套件整合後端與前端（如企業式運算的 Server components），有些套件則是整合後端跟資料庫（如 ORM 模組）。這些軟體套件自然都有其用處，但是你卻不可能一次全部用，也很難用了一者後快速置換，用錯了之後可能要花幾周甚至幾月的時間去修改。
缺乏實戰管理經驗的新創團隊，在運用軟體套件和平台時，最大的問題就是「用了卻不知為何而用」。比如說有人習慣用 Angular.js 去開發介面，但是也因此決定了前端與後端的互動方式。若該團隊的介面不需非同步的資料載入，其實採用伺服器端 Data-binding（註：Angular.js 是前端 Data-binding）會更容易統一管理程式碼和資料格式，開發時間反而會更短。很多新創團隊因為讀到國外的新創團隊在用甚麼新的軟體套件，馬上就一窩蜂跟著用，卻無法解釋原因，這樣很容易創造不必要的技術負債（Tech debt）。
source: opensource.com
雲端與分散式運算
雖說雲端是個沒甚麼實際技術意涵的噱頭詞（Buzzword），雲端卻象徵了一種新的作業模式。如果說上一世代的網路軟體業是管理獨立透天厝，那今天的網路軟體業就是租用中央管理的公寓大樓。前者必須樣樣都要自己來，打掃、澆水、水電裝修等，如果想要運動還得去外面的健身俱樂部；後者則是將大樓基本的設施管理交給管理公司，要運動還有共用的設施可以使用。
整個雲端經濟的概念就是各類的軟體公司，不管是提供軟體雲（Software-as-a-Service，SaaS：提供軟體應用解決方案）、平台雲（Platform-as-a-Service，PaaS：提供可供軟體服務運行的平台）、架構雲（Infrastructure-as-a-Service，IaaS：提供遠端硬體讓開發商選擇運行自己的平台和軟體服務），都是要將原本軟體和硬體平台繁瑣的前置、架設、維護和資訊安全作業全部顧好，然後透過網路介面提供給開發商或使用者使用。
雲端經濟所建立起的基礎建設，使得軟體創業的成本大幅降低。原本需要自己租用網路頻寬、自己管理伺服器、自己防毒的高硬體和軟體授權成本，今天全部都降到每個小時幾毛甚至幾分美金，真謂物美價廉。
雲端經濟對於軟體產業的衝擊，第一在於其將軟體開發變成了開關式解決方案（Turn key solution），可隨時控制資源投入和適度增加人力需求；第二在於軟體平台的平行化，由於公司可以快速地將工作分配到多台遠端主機上，使得今天軟體服務的後端架構幾乎都是以分散式的方式運作。
台灣的雲端經濟的劣勢非常明顯，應該說是台灣軟體業落後的主因之一。過去十餘年，除了趨勢科技曾喊過要做雲端以外，台灣的雲端經濟幾乎都是電子和製造商在喊，而用意只是在於提升硬體設備銷售量，而完全沒有軟體配套措施。而過去七年，中國的廠商如百度、阿里巴巴等都投資雲端，使中國的雲端環境規模和功能成長迅速，今天僅次於美國。台灣軟體業沒有自己的大型雲端供應商，代表若要使用高品質雲端服務，必須把軟體架在亞洲其他國家（如新加坡）才行。
可以架在其他國家就算了，最大的問題在於雲端服務的最新服務往往都是國內限用。以美國亞馬遜、微軟和Google為例，其雲端新功能都是先在美東或美西發表，亞洲往往都要等數個月甚至一年以上。台灣在此無法跟歐美和其他亞洲國家競爭，代表我們在工具上、軟體製程上永遠會比別人落後。
而工具落後時，我們團隊的人事規模和成本就會比其他團隊肥大。
主動與被動品管流程
說穿了，就是主動偵錯和被動偵錯。2000年後的主流程式語言和軟體架構，都將偵錯流程視為重要的標準套件之一。主動的品管流程，主要以各類的軟體測試，如 Unit testing、Integration Testing、Regression Testing、Load Testing等。而被動的品管流程，從程式語言層級的 try-catch，到專案層級和解決方案層級的偵錯程序，許多自動化的套件都已經成為相當盛行。
為什麼要品管流程很重要呢？
當然，除了抓蟲以外，品管流程最重要的就是可以全面改善軟體開發團隊的時間。如果今天任何新版本推出之前團隊都會先執行一次各層級的主動測試，那可大幅減少上線後一些大大小小的毛病；而新版本上線後，若發生甚麼問題，第一時間系統應該自動偵錯、找到出錯的程式碼、時間、使用者帳號、資料數值等，並且將這些資料彙整後傳送給工程團隊，使其能在最短的時間內對出錯的地方直接進行修復。
目前敝人在台灣的經驗指向台灣團隊對於品管流程的重視程度遠不及開發流程。但實戰情況下，大家都知道抓蟲的時間遠比開發時間長，因此事先規劃和設計品管流程對於科技公司的長遠發展，重要性絕對不亞於開發流程的管理。
使用者中心設計
這其實就是使用者經驗的中心觀念。使用者經驗所進行的各類設計工作其實過去幾十年早就已存在，真正不同的在於整個產品的設計理念、資料彙整和團隊互動方式改變了。
傳統軟體公司的模式是以功能中心設計（Feature-centric design），意思就是整個專案的管理、彙整和執行都是以產品規格為主，而很少去討論使用者如何使用這產品。傳統的設計模式，我們很難去判斷到底功能的重要性和先後順序，一旦發生變數，也很難客觀地去調整或裁撤功能。
在過去六七年內，以人機互動（Human-computer Interaction）為基礎的使用者經驗設計（User Experience Design，簡稱 UX Design）逐漸浮現。而UX的重點在於建立使用者模型（User Model，可包含 Persona、User Story 等不同敘述模式），來形容使用者的工作環境和工作流程，並且從中萃取出工作必要的資訊和流程（剔除現有工具對使用者行為的負面影響），來找到好的設計所需的互動元素。
UX 的革命重點在於設計流程的管理方法革新。由於 UX 設計的潮流是最近幾年才吹起，許多流派上在概念上仍未釐清，因此有非常多的設計師將畫畫 UI、繪製 Wireframe、製作互動式介面等當作 UX 去行銷自己，可謂掛羊頭賣狗肉。
但是這 UX 盛行的過去幾年，科技業的各類專案的管理都已積極從功能中心設計走向使用者中心設計。換句話說，就是專案的定義除了功能性的敘述外，更要能深入討論各個功能對使用者的重要性，以及如何持續用量性（如流量分析）和質性（如個別訪談）使用者資料去改進產品功能。
台灣這過去兩三年內自然也隨風起舞，但是台灣的問題在於設計師幾乎都沒搞清楚 UI 和 UX 的差別。許多台灣設計師常常把 UI 與 UX 二字綁在一起行銷，卻完全不知道 UI 是設計界面，UX 卻是任何設計工作背後的資料調查和可行性管理。故此，台灣許多 UX 設計師，只是視覺設計師和產品設計師改職稱，實際上都是用功能性中心的理念在設計。就算一心想做 UX 的事，轉向使用者中心設計，老闆和主管普偏缺乏正確認知也不夠重視。
為什麼會發生這種情況呢？
其實我們可以從台灣學術界觀察到問題的源頭：台灣的高等學府有世界級的工程學系和研究所，但是卻沒有世界級的人機互動研究中心。主要原因在於人機互動和 UX 需要工程學系、設計、人文學系等跨學系合作，才能夠從多個方面深入了解使用者。人文和社會科學不強，就不可能會發展出像樣的人機互動和 UX 設計學院。
台灣長久以來漠視工程以外學系的發展，當世界科技業已經走到了一個必須要跨領域合作才能深入解決產業問題的階段時，台灣的設計和管理思維就明顯脫節了。台灣的設計師要畫、要做都很行，但是講到觀察、分析、溝通、合作，卻是完全外行，因此至今難以吸收 UX 設計的精髓。
需痛定思痛，需長遠投資
如果說傳統的網路軟體公司是龐大的陸軍師在對抗，那今天的科技業已經轉型成為非傳統戰爭，其編制更像遊騎兵或海豹部隊一般由各個身懷絕技的成員組成的排（15-30人）。美國許多成功的軟體新創公司，A 輪以後產品團隊（管理、設計、工程、品管）都在五人以下，B 輪或 C 輪以後的公司也幾乎都在20人以內。當初被 Facebook 以十億美金收購的 Instagram，當時公司只有13人。
反觀台灣，絕大多數的新創團隊和軟體公司都有很嚴重的人事肥大問題。許多尚未籌資的公司已經有好幾個人，而只有種子資金的團隊都已經破十人，A輪以後的公司員工更是擠滿了辦公室。問題在於這些公司幾乎業務都尚未起飛，養的人事規模卻是矽谷和紐約同階段公司的兩倍以上。甚至比美國很多市值破億的科技公司人事規模更大。
公司辦公室一堆人不代表厲害，只是告訴大家你的公司的效率非常差而已。
這顯示出台灣的管理方法出了很嚴重的問題，而原因有二：第一是因為薪資水準太低而導致濫用人事，把上士當二等兵操；第二則是管理者經驗不足，無法妥善運用本文提及之工具與方法來提升團隊效率；第三就是個別員工自主性和自發性不足，增加了管理的難度。
因此當我們台灣人在想說因為工程師多就可以拼出軟體新創的時候，很遺憾地，敝人必須直言：矽谷和紐約走一趟，就會發現不只是台灣，全世界的工程師都很多。而大家工程人力過剩，不知如何消耗的時候就是去找案子接，在矽谷和紐約，滿街都有來自於印度、哥倫比亞、墨西哥、阿根廷、烏克蘭、斯洛伐克、巴基斯坦等國家的承包商在美國找客戶，而這些國家的成本比台灣低非常多。
台灣人以為寫寫 iOS、Android 手機 App，用 ReactJS、AngularJS 做 Web，用 Hadoop 做大數據，就很厲害嗎？抱歉，世界上一大票開發中國家的承包商全部都會寫，要甚麼有甚麼，但是他們的問題在於管理方法非常拙劣，且工程理念過時。如果美國公司外包案件，要不就是需要每天自己請人盯承包商，不然就要有承受高技術負債的心理準備。（當然，很多案件都是一次性的，未來也不會再延伸發展）換句話說，就是許多開發中國家的工程團隊的管理和開發方法瓶頸，跟台灣是同病相憐。
所以當我們問自己，台灣工程師那麼便宜，為什麼國際大廠不會搶著要？答案已經很明顯了。我們的薪資水準雖遜於多數已開發國家，但卻高出開發中國家，但同時我們提供的軟體工程水準卻也沒比開發中國家好到哪裡去。
便宜但是效率不彰，最後只有貪小便宜的慣老闆才愛用。
故此，台灣早該忘卻美好的國際接案夢，我們早就失去成本上的競爭力了。而我們的科技業管理人才已經是十餘年來沒有好好培養，請多投資我們的員工和主管，並積極挖角海外有相關管理經驗之台籍人士回流，刺激管理方法的升級。這不是一年兩年的事情，而是要多年去持之以恆，才能提振台灣失落的軟體產業。
如果大家有什麼非情緒性的觀點或意見願意交流，也歡迎在下面留言！
Image Credit: Pixabay
