軟體專案的困難
南亞科技資訊部課經理曾鴻志表示：「制定流程並不難，但真正的落實流程卻有很多的問題存在。」
南亞科技所有的應用系統包括ERP都是自行建置，資訊部門針對各部門的需求，皆會設法實作成為一套自動化系統，以便加速工作效率。南亞科技資訊部課經理曾鴻志表示：「早期系統開發流程與制度，充滿了『英雄主義』。」常常是一個人包辦系統分析、設計、開發、部署與維護的工作，沒有留下文件與記錄，所有的知識都在人的腦子裏。
當人員離職後，系統維護的困難度就相對提高。接手的人在沒有文件的協助下，只能解讀前人的程式碼，「這是哪個豬頭寫的？」是最常聽到的一句話，然而，就算重新改寫，就不會有下一個「豬頭」嗎？
南亞科技的高層逐步思考著制度與流程的改善方法，於是參考軟體廠商的作法，在2004年開始著手評估CMMI。對南亞而言，沒有評鑑的需求，而且導入CMMI的成本頗高，因此南亞傾向採用CMMI的精神，便於2005年組成跨部門的「流程改善小組」，每周定期開會檢討。
曾鴻志負責需求管理領域的流程，發現制定流程並不難，但真正的落實流程卻有很多的問題。因為對於工程師而言，填寫文件與表單，是很繁瑣的工作。為了落實CMMI的精神，南亞科技決定導入微軟的Visual Studio Team System，選擇MSF（Microsoft Solution Framework）中的MSF for CMMI Process Improvement流程，並加以調教，希望透過自動化工具降低工作負擔。
專案關乎競爭力
這樣一個追求軟體開發流程改善的例子，在同業中持續發酵，因為人員流動率高，是高科技製造業的痛，如果不能有效掌控軟體生命周期的每一個階段，企業將一再面臨專案失控的問題。企業或多或少都有軟體自製的需求，在國外，資訊服務（也就是專案開發）的比重，約是套裝產品的20倍；而國內根據MIC的統計套裝產品與專案開發的比例也有4:6的差距。
鼎新電腦技術總顧問周忠信分析：「套裝產品主要解決自動化的問題，專案開發的系統卻往往是營運的致勝關鍵。」電子郵件、文書處理甚至定型化的ERP系統，主要應付日常工作，提高工作效率與管理能力；但更多攸關核心競爭力的需求，是套裝產品無法滿足，必須透過客製化，甚至全程訂製，才能符合企業獨特的要求。
軟體本身的變化—
然而經過數十年的演進，軟體專案的成功率依然不高，其實軟體本身的變化也是原因之一，軟體從數百行至數千行，進展到數萬行乃至數十萬行程式碼的規模。而作業環境從簡單的批次作業，變成了複雜的多工、分時、分散式運算。當軟、硬體環境變得更大、更複雜時，軟體的發展流程也越來越複雜，從前小而簡單的開發方式，再也無法應付當前的需求。
中山大學資訊管理系教授鄭炳強認為，我們必須認清軟體開發工作具有以下本質上的困難：
● 複雜性－軟體要解決的問題，所牽涉的運算邏輯是一種人為、抽象的智能活動，多半是複雜的。
● 協同性－在大型軟體環境中，子系統之間的介面必須協同一致，但由於時間與環境的演變，維持一致性是十分困難的。
● 變易性－軟體所應用的環境，常是人、法規、硬體與應用領域各項因素融合而成，而這些因素皆會快速變化。
● 不可見性－尚未完成的軟體，即使利用圖像化的說明，也難以充分表達，使得溝通上面臨極大的問題。
人的影響—
除了軟體本身的變化與困難，更重要的因素是軟體開發是高度依賴「人」的活動，人不像機器可以長時間維持一貫的工作品質，所以人的素質、心情以及異動都會對專案造成影響。
專案可以承受幾輛卡車？
當一個專案換到第3個負責人的時候，我們還能期待他能清楚了解狀況嗎？因此如何降低人員異動對專案的影響，各式開發方法論皆提出因應的對策。
XP衡量專案健康指標之一的「卡車數量」理論：如果有一輛卡車撞死一個團隊成員，對專案的影響有多大？專案又可以承受幾輛卡車呢？雖然論調有些恐怖，不過XP的對策是強調搭檔編程（Pair Programming），並且要頻繁地更換搭檔（Switch Pair），力求所有的成員都可以共同維護專案的每一個部分，以降低對人的依賴性，那麼才不用擔心「卡車」可能的影響！這與企業管理強調的職務輪調是相同的概念。
而RUP的設計將軟體開發畫分不同的角色，每個工作流程皆有明確應執行的工作項目，每個工作項目又細分各種活動（Activity）與相對的產出（Artifact），再細看每個活動，也都包含詳細的執行步驟。當每個人只需專注於自身扮演角色所應處理的工作，在轉交給下一個人的時候，有明確定義應輸出/輸入的文件與程式，所以只要接續的人員，具有相同的背景知識，看得懂負責部分UML圖與文件，就可以快速參與工作，所以對專案的衝擊比較小。
鄭炳強提出了另一個觀點，他認為優良人才的流失，是專案最大的失敗，一個人力經常流動的團隊，不可能會有好的成效，因此應該盡量減少開發階段人力的中途離開。
專案要做到不依賴人，勢必需要大量的文件或自動化的工具，但文件與工具比人更不可靠，且需要付出額外的成本，所以比較好的策略，是盡量規畫良好的工作環境，讓人願意留下來。
流程的幫助—
事實上，流程是自然存在的。只要「人」開始「工作」，便啟動了一個流程，只不過，流程可能是混亂或變動的。「軟體工程」這個名詞已經問世38年了，開發方法論從前只是課本上的專有名詞，到現在已逐漸在軟體界發酵，而工程化的第一步，就是制訂標準化的流程。
沒有標準便無法可管
沒有事先的規畫、沒有固定的步驟、想到什麼就做什麼，雖然作法彈性，然而卻存在以下缺點：
● 任意刪改的危險：「哪個豬頭改了程式？」在不知情的狀況下，程式被別人修改，表示控管的流程出現問題。未經評估與審核的程式更動，可能牽一髮而動全身，引發一連串的錯誤。
● 自由心證的進度管理：專案負責人對於軟體開發的進度，若來自於是成員的自由心證，那麼覺得大概完成多少就說多少，擔心績效不佳就有可能出現虛報的情況，那麼所謂的「進度」，很可能只是美好的假象。
● 驚人的溝通成本：為了掌握真實的進度與狀況，不斷地確認與溝通，將有開不完的無效會議。
● 無法累積經驗：企業有不少制度或規定是因應過去曾經遭遇的問題，才衍生的特殊設計。若智慧與經驗是累積在特定人的腦袋裏，沒有標準化的制度與文件，企業便沒有累積與改善的依據。
軟體工程沒有銀彈
從採訪的案例中，不難發現流程標準化，改變原本的工作習慣，或多或少都會引起反彈。為降低習慣改變的衝擊，專家們建議從簡單做起。各式新穎的方法論與學說，如雨後春筍般出現，皆有相當吸引人的論調，但很有可能言過其實，軟體工程著名的暢銷書《人月神話》強調：「軟體工程沒有銀彈。」軟體開發至今仍困難重重的成因複雜，並不存在一帖見效的良方。
因此鄭炳強強調：「在評估方法論時，應先了解它的缺點與限制。」在大家盲目追求物件導向、多層式架構（N-Tier）時，鄭炳強最常問的便是：「你知道物件導向的缺點嗎？」、「你知道N-Tier架構的缺點嗎？」我們可以看到許多一窩蜂流行的後遺症。同樣的，任何工具與方法論皆有其強項與罩門，如果選錯了方法或工具，小心未蒙其利，先受其害！
與其革命，不如改善
每個企業的規模、文化、人員素質、專案特性與開發團隊的成熟度都不同，所以沒有足以一體適用的流程可以套用。如周忠信所言：「沒有多偉大的流程，確認習慣的流程就好。」企業並不是沒有流程，只是可能沒有「固定」發生的順序，或者存在一些缺失，因此需要的只是調整與補強。
一次革命性的變革衝擊過大，反而不易成功；基於既有的習慣尋求改善，漸進式的改變比較接受。因為痛苦的流程便不是好的流程，好的流程是無感的，如果可以丟掉所有的規章，讓制度融入企業成為文化與習慣的一部分，就是成功的流程。
3年 vs. 3個1年的經驗
在調適的過程中，面對成員的反彈，寶發科技總經理胡佑長表示：「如果覺得寫文件很浪費時間，表示寫文件的時間還不夠多。」以敷衍的心態寫文件，確實是很浪費時間；但若了解寫文件不是製造麻煩，而是為了避免未來更多的麻煩，就會花更多的心力與時間認真寫文件。
不過，在感受到寫文件留下記錄的好處前，仍需搭配稽核的手段，並有人擔任循循善誘的角色。以南亞科技為例，曾鴻志除了一再強調流程與文件的好處，並從個人競爭力的角度與員工分析他的看法：「在一家公司工作3年，你希望累積3年的經驗，還是3個1年的經驗？」如果還是以過去的方式開發系統，未來員工尋求新東家時，並沒有特別可以與他人競爭的優勢。
離岸委外的選擇—
委外開發也是軟體專案的選項之一，境內的委外是大家所熟悉的類型，考量的因素不離廠商的技術、服務品質、價格與存續性。當國內的委外費用因為人力成本的影響而墊高，人力便宜的大陸或印度成了另一種可能性。
印度委外模式挑戰人月神話
東森購物委外印度開發虛擬購物平臺ET1，帶回很多值得探討的寶貴經驗，印度精細的工作切割，使他們顛覆了《人月神話》「在一個延遲的專案裏再加派人手，只會讓專案更延遲」的說法。事實上，《人月神話》的說法至少在臺灣是正確的論點。
松凌科技技術總監李日貴便曾經目睹客戶的一個上仟萬的委外專案，廠商在延遲的情況下，不斷地加派人手，然而溝通的代價抵消了人力增加的好處，致使延遲的情況更加嚴重。
東富資訊總經理許世杰以營建業舉例，他認為印度軟體開發的分工方式，是依綁鋼筋、灌漿、水電、挑磚、刷油漆等專業分工，所以工程延遲，依照目前的進度加派人手，10個人與20個人綁鋼筋的速度，理所當然可以倍數成長。工人依監工的指示，照藍圖施工，不會質疑設計師的想法。
而臺灣的作法，是一群人負責客廳、一群人負責房間、另一群人負責廚房與浴室，每個人都會綁鋼筋、灌漿、水電、挑磚、刷油漆，但進度落後時，加派人手就存在許多交接、協同合作與溝通的問題，所以新人在「進入狀況」之前，必須「晾」在旁邊觀摩一段時間，所以產值是零。也因為搞不清楚狀況，所以常常反問為什麼要這樣、為什麼要那樣。
印度的分工方式，延伸的好處，是讓工程師有機會針對自身的專業持續累積經驗，例如設計報表的工程師，從各種專案經驗中，累積了許多報表樣式的範本，投入新的專案時便可以迅速套用，減少重工（Rework）加速工作效率。以印度軟體服務公司Wipro為例，每年都提撥15～20%的淨利，用於整理在過去專案中開發的元件，以利重複利用。
大陸委外屬於協同合作
印度軟體工程師的工作型態，類似生產線的作業員，不斷重複類似的動作，許世杰認為：「文化的關聯大於收入的影響，同樣的模式移植到同樣人力便宜的大陸，未必行得通。」在我們訪問凌群電腦的時候，談到凌群電腦集團於大陸成立的凌安電腦，其業務正是承接臺灣委外的專案或人力，細問凌安電腦的委外模式，確實與印度大不相同，印證了許世杰的說法。
凌安電腦是以工作「階段」切割，例如臺灣負責設計、大陸負責開發；或者臺灣開發系統、大陸協助測試。從許世杰的觀點分析，這樣的模式確實較符合大中華地區注重個人價值的民族特性。
領導型企業的核心系統適合委外印度
至於離岸委外該選擇印度還是大陸呢？根據我們的分析，領導型的企業，或者產品型的軟體適合委外印度。領導型的企業是產業的龍頭，最熟稔該領域的核心競爭力，例如東森購物不但產業性質特殊，而且是臺灣電視購物領域的第一把交椅，不可能有廠商或現成的產品，比東森更了解電視購物的領域知識，所以選擇專案開發才能完全貼近需求。
而攸關核心競爭力的系統，必須是短期製程，許世杰強調：「當一個專案的期程大於2年，其失敗的機率將大幅提高。」市場瞬息萬變，2年前的需求很可能已經不符合現實的情況，所以專案必須投入大量的人力在2年之內完成。此類領導型企業的專案，便適合尋求印度大量且專業的人力與分工能力。
此外，周忠信表示：「委外印度適合產品類型的軟體開發。」因為產品的功能固定，而專案型的軟體必須因應市場而變動，但印度的軟體代工在專案結束後，人力便徹出臺灣，鞭長莫及的情況下，不可能因應需求經常性變動的專案。專案後續的維護，便是必須考量的問題，除非企業有能力接手處理，否則維護工作將成燙手山芋，這也正是接手維護東森購物ET1系統的東富資訊，未來將面臨的考驗。
訴求降低人力成本，可放眼大陸
大陸的委外對企業而言，可視為資訊團隊的「分身」，只要做好安全的控管，臺灣與大陸便可以運用各自的優勢，分工合作協助企業建置e化系統。例如臺灣負責分析與設計，開發與測試的工作，委外由大陸較便宜的人力，便可降低成本，專注心力於更重要的事情。
目前已有企業以長期合作的方式，與對岸的資訊公司簽約，將資訊部門一定比例的工作，委外大陸完成，以降低臺灣的人力成本。
整體解決方案的陷阱
許世杰認為，臺灣資訊廠商喜歡強調整體解決方案（Total Solution），正是委外賺不到錢的原因。長榮航空電算本部應用程式部經理侯憲裕則分享他們委外的兩個經驗，一個是上仟萬的專案委外IBM；另一個預算規模較小的專案，則委外一家臺灣資訊服務廠商開發。IBM評估專案時，便言明哪些需求可以完成，哪些功能有困難；而臺商則是什麼都「OK沒問題」。
結果，是IBM在期限內結案，而且加入了部分原先保守評估無法提供的功能；而臺商負責的專案，不但延遲交付，而且不同於剛開始打包票的態度，有些功能是無法完成的。整體解決方案的概念，確實讓資訊廠商吃足苦頭，企業也必須體認：只會說「Yes」的廠商，其承諾令人質疑。
