星期四, 10月 05, 2006
星期二, 10月 03, 2006
BenQ 啟示錄
BenQ 啟示錄
彭蕙仙
BenQ （明基）以類似申請破產的方式宣佈停止德國子公司的營運，不但在產業界引爆震撼，甚至也在國際政治上引發議論，德國朝野已紛紛對台灣 BenQ 提出討伐；被中止合作的 Siemens 肯定覺得面子、裡子盡失，這些年 Siemens 手機的營運本有每下愈況之勢，併購不到一年 BenQ 就宣告莎喲娜啦，在商言商，這當然是一個嚴重的否定。
這些年來，台灣認真思考並且實踐「全球品牌」（ global branding）的台灣企業裡，BenQ 絕 對是個令人關注的名字，去年6 月併購Siemens手機部門的大手筆讓人對「台灣走向世界」的可能性有了更深的期待，因此，當 BenQ 走到了如今的這一步，不僅僅令人嘆息，更讓人省思，「品牌」、或者說「全球消費性品牌」這條路是否真的是台灣企業終須一試的不歸路？
明基董事會日前通過不再投資德國手機子公司，以向德國政府聲請無力清償保護 （insol-vency protection）的方式，明基將關掉在德國的製造營運部門，但 BenQ 表示，BenQ-Siemens手機品牌及銷售管道仍保留下來，只是，現在 Siemens 正在火頭上，揚言要收回品牌使用權 ；目前BenQ與西門子（Siemens ）之間的權利義務、品牌、專利權等關係仍在剪不斷、理還亂的狀態，需要一段時間的釐清。
☉嫁妝難抵敗家
估計過去三季， BenQ 因為投資 Siemens ，帳上認列的虧損超 過 6 億 歐元（折合新台幣約 250 億 元），明基董事長李焜耀（KY ）說，停止投資德國西門子實在是不得已之舉，為的是避免虧損加劇。
BenQ 併購 Siemens 之初， 一定知道 Siemens 的營運問題，所以，其實當初 BenQ 併購 Siemens 時，Siemens 還雙手奉上 3億 歐元，但 日昨，Siemens 一肚子委屈說不只 3 億！意思是說，當初嫁妝如此豐厚，不到一年你就把我甩了，良心何在？ BenQ 則萬分不爽地說，我哪裡知道你會這麼敗家？
當初， BenQ 的想法也許是希望結合台灣、中國優異生產製造能力與德國的技術強度，再加上 BenQ –Siemens 品牌，打出一條生路來；最重要的是要藉此合併擴大 RD、技術、生產、行銷、通路、品牌規模，拚到全球第三、第四；老實說，就消費性電子品牌而言，若是不能擠進前三大、前四大、至不濟，前五大，根本是生存不下去的， BenQ 深知這一點，所以千辛萬苦也要併購西門子，就是希望能有機會藉此擠進全球手機大腕之列。
但這是一件困難的事。 Sony、Ericsson 都夠大了吧！但。Sony 併 Ericsson 都 5 年了，Sony-Ericsson 這個品牌在全球的排名還是只能在第三、第四徘徊，和南韓的 LG 與 Samsung 互為瑜亮；Sony 併 Ericsson 也只能是這樣已，況且，當初兩者手機部門合併時，還很聰明地把營運製造部分切割了出去，不像 BenQ 併購 Siemens，還承接了 Siemens 的營運部門，負擔更為沉重；再加上新產品開發速度較之預期慢太多，與重要商機身而過，本來預計要「挺」兩年的併購磨合期，三季就玩不下去了。
☉BenQ 併Siemens 綜效何在？
為了要在 B2C 品牌戰場上取得勝利、而且是以比較快的速度勝出，透過併購幾乎是必走的路，只是 BenQ 和 Siemens 的合併似乎並無「截長補短」的綜效。手機是個技創新快速的產業，台灣業者若無突出且可有一定領先期間的技術，如智慧型手機領導廠商多普達 Smartphone，卻想在一般性的手機上從 Nokia 、Motorola 等堡壘堅實的國際大品牌手上攻下城池，難度太高了。
要做品牌，台灣業者只能倚靠非凡的技術利基，問題是， BenQ 與 Siemens 本來各自在這部分就不突出，1 加 1，又怎麼創造出大於 2 的加乘效果呢？
BenQ 併購 Siemens 是有點勉強的，有人比喻說，就像一個個子矮的男士想追林志玲，踮起腳尖或可與名模匹配，但是踮腳尖走路終究是走不遠的，腳一酸、一放，當場就矮了大半截。但 BenQ 一直努力想走自我品牌的路，不這樣併購好像也沒別的路子走，因此不忍心苛責這名男子幹嘛老要踮起腳尖走路，而是，他就非要追林志玲不可嗎？
☉台灣有多少能耐走「品牌的路」？
這裡回到一個很基本的問題，台灣究竟有多少能耐走「品牌的路」？ Nokia 很了不起，但芬蘭也就這個品牌，2300 萬人口的台灣可以支持多少個全球品牌？即使把中國當作支持品牌的母市場（home market ），從中國走向世界，中國自己的消費性品牌（電子、資訊產品）也算不上開張；台灣的全球品牌之路，宏碁幾度顛躓，最終也是在運用（leverage ）了整個台灣辛苦建立了30年的 NB 生產系統、還請了歐洲人負責經營，搞定生產到通路方得成事； B2C，不只是錢坑，也是時間與系統整合的戰役。
然而，台灣產業在 B2B 的製造體系裡已經有很大的、某些領域裡還有關鍵性的影響力，或許台灣沒有能力可以做產品、品項的定義者，因此要發展消費性電子產品的全球品牌有一定的難度，但是在「材料」、「零組件」、「工法」、「製程」、「模具」乃至於部分「工業設計」上，對國際品牌來說，台灣業者在全球製造體系裡，已從單純的執行者躍升為「可敬的對話者」，來自台灣的生產智慧早已在 B2C的循環結構裡多所回饋，早已是這個系統裡不可或缺的一個角色（ player）。
☉品牌認同就是生活風格的認同
但做品牌、或者說做全球品牌，卻實在遠遠不只這些。在一般性技術幾無門檻的情況下，要不就是要有殺手級的技術突破，永遠領先對手一步；要不，就是創造出一種給人有想像力的品牌情調，那通常是一種生活風格的認同，往往，這需要有肥沃的社會資本（ social capital）作為滋養的土壤，非單一企業可竟全功；要販賣台灣風格， BenQ 還須等待台灣人確實在生活與美學上有集體的甦醒。
消費電子品牌就賣技術與情調這兩樣東西。大手筆砸錢的行銷膽識背後，若少了一種技術厚度與美學深度，很快就會無以為繼，何況，認真說來，台灣企業也沒有用之不盡的行銷子彈。
10 年前，當 KY 意氣風發論及「品牌」與「代工」雙軌並行時，豈料想得到為了發展品牌，終使 Motorola 的訂單流出；又豈能料到，合併 Siemens，三季燒掉 6 億歐元，淨值跌至 10 元左 右，也因而引發市場另一大廠默默吃股近三成以上、甚而有遭遇非合意併購的危機？BenQ 是台灣截至目前為止，在工業設計上最用心思、也最肯投資的企業之一，在國際產品設計大獎上，一路走來，總是讓人驕傲的台灣之光，因此，BenQ 的全球牌品牌雄心與行動，或許多少也誘發了人們在不知不覺中寄與承載過高的期望。
郭泓志下放三 A沈潛後，今年終於有了讓人驚豔的成績；對 BenQ 這一回的挫敗，或許很多人也做如是想。併購 Siemens 一如經歷了一次 Tommy John 手術，休養需要時間，但若手術做得好，之後的投球生涯亦可望延長。
在如今的這個時代，敢做夢、肯跨步的人，都該給予掌聲。
彭蕙仙
BenQ （明基）以類似申請破產的方式宣佈停止德國子公司的營運，不但在產業界引爆震撼，甚至也在國際政治上引發議論，德國朝野已紛紛對台灣 BenQ 提出討伐；被中止合作的 Siemens 肯定覺得面子、裡子盡失，這些年 Siemens 手機的營運本有每下愈況之勢，併購不到一年 BenQ 就宣告莎喲娜啦，在商言商，這當然是一個嚴重的否定。
這些年來，台灣認真思考並且實踐「全球品牌」（ global branding）的台灣企業裡，BenQ 絕 對是個令人關注的名字，去年6 月併購Siemens手機部門的大手筆讓人對「台灣走向世界」的可能性有了更深的期待，因此，當 BenQ 走到了如今的這一步，不僅僅令人嘆息，更讓人省思，「品牌」、或者說「全球消費性品牌」這條路是否真的是台灣企業終須一試的不歸路？
明基董事會日前通過不再投資德國手機子公司，以向德國政府聲請無力清償保護 （insol-vency protection）的方式，明基將關掉在德國的製造營運部門，但 BenQ 表示，BenQ-Siemens手機品牌及銷售管道仍保留下來，只是，現在 Siemens 正在火頭上，揚言要收回品牌使用權 ；目前BenQ與西門子（Siemens ）之間的權利義務、品牌、專利權等關係仍在剪不斷、理還亂的狀態，需要一段時間的釐清。
☉嫁妝難抵敗家
估計過去三季， BenQ 因為投資 Siemens ，帳上認列的虧損超 過 6 億 歐元（折合新台幣約 250 億 元），明基董事長李焜耀（KY ）說，停止投資德國西門子實在是不得已之舉，為的是避免虧損加劇。
BenQ 併購 Siemens 之初， 一定知道 Siemens 的營運問題，所以，其實當初 BenQ 併購 Siemens 時，Siemens 還雙手奉上 3億 歐元，但 日昨，Siemens 一肚子委屈說不只 3 億！意思是說，當初嫁妝如此豐厚，不到一年你就把我甩了，良心何在？ BenQ 則萬分不爽地說，我哪裡知道你會這麼敗家？
當初， BenQ 的想法也許是希望結合台灣、中國優異生產製造能力與德國的技術強度，再加上 BenQ –Siemens 品牌，打出一條生路來；最重要的是要藉此合併擴大 RD、技術、生產、行銷、通路、品牌規模，拚到全球第三、第四；老實說，就消費性電子品牌而言，若是不能擠進前三大、前四大、至不濟，前五大，根本是生存不下去的， BenQ 深知這一點，所以千辛萬苦也要併購西門子，就是希望能有機會藉此擠進全球手機大腕之列。
但這是一件困難的事。 Sony、Ericsson 都夠大了吧！但。Sony 併 Ericsson 都 5 年了，Sony-Ericsson 這個品牌在全球的排名還是只能在第三、第四徘徊，和南韓的 LG 與 Samsung 互為瑜亮；Sony 併 Ericsson 也只能是這樣已，況且，當初兩者手機部門合併時，還很聰明地把營運製造部分切割了出去，不像 BenQ 併購 Siemens，還承接了 Siemens 的營運部門，負擔更為沉重；再加上新產品開發速度較之預期慢太多，與重要商機身而過，本來預計要「挺」兩年的併購磨合期，三季就玩不下去了。
☉BenQ 併Siemens 綜效何在？
為了要在 B2C 品牌戰場上取得勝利、而且是以比較快的速度勝出，透過併購幾乎是必走的路，只是 BenQ 和 Siemens 的合併似乎並無「截長補短」的綜效。手機是個技創新快速的產業，台灣業者若無突出且可有一定領先期間的技術，如智慧型手機領導廠商多普達 Smartphone，卻想在一般性的手機上從 Nokia 、Motorola 等堡壘堅實的國際大品牌手上攻下城池，難度太高了。
要做品牌，台灣業者只能倚靠非凡的技術利基，問題是， BenQ 與 Siemens 本來各自在這部分就不突出，1 加 1，又怎麼創造出大於 2 的加乘效果呢？
BenQ 併購 Siemens 是有點勉強的，有人比喻說，就像一個個子矮的男士想追林志玲，踮起腳尖或可與名模匹配，但是踮腳尖走路終究是走不遠的，腳一酸、一放，當場就矮了大半截。但 BenQ 一直努力想走自我品牌的路，不這樣併購好像也沒別的路子走，因此不忍心苛責這名男子幹嘛老要踮起腳尖走路，而是，他就非要追林志玲不可嗎？
☉台灣有多少能耐走「品牌的路」？
這裡回到一個很基本的問題，台灣究竟有多少能耐走「品牌的路」？ Nokia 很了不起，但芬蘭也就這個品牌，2300 萬人口的台灣可以支持多少個全球品牌？即使把中國當作支持品牌的母市場（home market ），從中國走向世界，中國自己的消費性品牌（電子、資訊產品）也算不上開張；台灣的全球品牌之路，宏碁幾度顛躓，最終也是在運用（leverage ）了整個台灣辛苦建立了30年的 NB 生產系統、還請了歐洲人負責經營，搞定生產到通路方得成事； B2C，不只是錢坑，也是時間與系統整合的戰役。
然而，台灣產業在 B2B 的製造體系裡已經有很大的、某些領域裡還有關鍵性的影響力，或許台灣沒有能力可以做產品、品項的定義者，因此要發展消費性電子產品的全球品牌有一定的難度，但是在「材料」、「零組件」、「工法」、「製程」、「模具」乃至於部分「工業設計」上，對國際品牌來說，台灣業者在全球製造體系裡，已從單純的執行者躍升為「可敬的對話者」，來自台灣的生產智慧早已在 B2C的循環結構裡多所回饋，早已是這個系統裡不可或缺的一個角色（ player）。
☉品牌認同就是生活風格的認同
但做品牌、或者說做全球品牌，卻實在遠遠不只這些。在一般性技術幾無門檻的情況下，要不就是要有殺手級的技術突破，永遠領先對手一步；要不，就是創造出一種給人有想像力的品牌情調，那通常是一種生活風格的認同，往往，這需要有肥沃的社會資本（ social capital）作為滋養的土壤，非單一企業可竟全功；要販賣台灣風格， BenQ 還須等待台灣人確實在生活與美學上有集體的甦醒。
消費電子品牌就賣技術與情調這兩樣東西。大手筆砸錢的行銷膽識背後，若少了一種技術厚度與美學深度，很快就會無以為繼，何況，認真說來，台灣企業也沒有用之不盡的行銷子彈。
10 年前，當 KY 意氣風發論及「品牌」與「代工」雙軌並行時，豈料想得到為了發展品牌，終使 Motorola 的訂單流出；又豈能料到，合併 Siemens，三季燒掉 6 億歐元，淨值跌至 10 元左 右，也因而引發市場另一大廠默默吃股近三成以上、甚而有遭遇非合意併購的危機？BenQ 是台灣截至目前為止，在工業設計上最用心思、也最肯投資的企業之一，在國際產品設計大獎上，一路走來，總是讓人驕傲的台灣之光，因此，BenQ 的全球牌品牌雄心與行動，或許多少也誘發了人們在不知不覺中寄與承載過高的期望。
郭泓志下放三 A沈潛後，今年終於有了讓人驚豔的成績；對 BenQ 這一回的挫敗，或許很多人也做如是想。併購 Siemens 一如經歷了一次 Tommy John 手術，休養需要時間，但若手術做得好，之後的投球生涯亦可望延長。
在如今的這個時代，敢做夢、肯跨步的人，都該給予掌聲。
星期一, 10月 02, 2006
星期六, 9月 30, 2006
星期五, 9月 29, 2006
星期四, 9月 28, 2006
星期三, 9月 27, 2006
星期二, 9月 26, 2006
需求分析的方法
需求分析的方法
需求分析各個方法論的派別均有不同的作法，以下簡述RUP（Rational Unified Process）、XP（eXtreme Programming）、MSF（Microsoft Solutions Framework）及鼎新研發的MDM（Model Driven Methodology）開發方法論需求分析的方法：
RUP：使用案例（Use Case）－在需求分析階段繪製使用案例圖（Use Case Diagram），描述操作者（Actor）的行為模式。
一個使用案例就是一個系統功能，不過，使用案例沒有描述使用者介面，是在User Interface Analysis中建立User Experience Model作為使用介面製作的依據。
XP：客戶駐點及User Story－XP並沒有需求分析的過程，每個人都身兼分析師、設計師與開發者的角色，而且開發者與使用者均是專案團隊的成員。藉由客戶駐點使用者提供第一手的需求描述，開發者根據使用者的描述，或Story Card的內容，產出可執行的版本，交給使用者確認，再根據使用者的回饋，持續修正或增加新的功能，經由一次次反覆的互動與調適，最後實作出最貼近需求的產品。
MSF：案例（Scenario）－案例與RUP的使用案例（Use Case）的精神類似，利用案例反映不同角色的使用者的需求。「Persona」就代表不同角色的使用者，類似RUP Use Case中的Actor（操作員），其用意類似劇本中的演員，呈現了使用者的角色、行為、背景與動機等，例如惡意使用者的操作行為與一般使用者的行為模式便有很大的不同。以區分角色與行為模式的方式，更貼近真實的系統需求。
鼎新MDM：模型驅動－軟體需求的表達太過抽象，可能使用者描述不清；也可能開發者理解有誤；更多的例子是使用者看到實際的成品後，才知道怎麼做是符合需求的。
鼎新希望在需求分析階段徹底解決可能的誤差，以模型導向的方式，改變生產流程，並創造了塑模師的角色，提前呈現系統的面貌，讓使用者在需求定義階段，就確認系統是不是他們要的樣子。
流程改善5步驟－沒有偉大的流程，只有適合的流程
專家觀點
鄭炳強
●國立中山大學資管系教授
●臺灣軟體工程學會理事
●高雄醫學大學資訊處顧問
“在選擇開發的方法與工具之前，一定要先了解它的缺點與限制。”
周忠信
●東海大學資訊工程系教授
●臺灣軟體工程學會理事
●鼎新電腦技術總顧問
“簡單就是美。簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。”
胡佑長
●美國SEI授權臺灣首位CMMI主任評鑑員
●寶發科技總經理
“不要迷信最佳實務。流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。”
David Anderson
●微軟總部參與MSF設計的Visual Enterprise Studio部門流程架構師
“流程應該像汽車的引擎，發動之後就自動運行。”
軟體開發流程的學派林立，從輕量級的如XP、SCRUM、FDD到重量級的RUP有多種選擇。不過，所有知名的理論，都找得到成功案例與和失敗教材，企業應考量自身的規模、文化、人員素質、開發方式及開發團隊的成熟度，選擇適合的流程，並允許保留調適的空間，硬套死板的理論或僵硬的工具，其實無法複製他人成功的經驗。
標準化是為了強化控管
軟體專案不能沒有管理，而管理必須透過計畫與流程落實。專案初期制訂的計畫都很理想，但是經過長時間的演變，實際情況往往與計畫脫勾。
制訂標準化的流程，開發階段的所有活動，便可區分為「進行中」、「完成」、「停滯」或「延遲」等各種狀態，其實與Workflow的概念類似，透明化的資訊，幫助管理者掌握實際的進展，便可有效地追蹤與管理分析、設計、開發、測試等各項活動執行的情況。
「制度」會帶來相對的「限制」，不過，寶發科技總經理胡佑長：「企業越希望靈活，就越需要制訂流程。」流程與靈活並不衝突，如果流程無法因應改變，表示流程過於死板而需要改善。
選擇方法論前，先了解缺點與限制
軟體開發的方法論很多，每一種都有令人嚮往的好處。不過，中山大學資訊管理系教授鄭炳強認為：「在選擇方法與工具之前，一定要先了解它的缺點與限制。」例如採用XP的前提，是擁有實力堅強的開發團隊；RUP不適合無法以使用案例（Use Case）描述需求的專案。若選擇了錯誤的方法，會為專案帶來無窮的困擾。
任何方法論找得到失敗的案例，微軟總部Visual Enterprise Studio部門流程架構師David Anderson分享在過去參與新加坡銀行開發信用貸款系統的經驗，在David加入前，原先採用RUP方法論，耗時3年產生3,500頁的文件，客戶最常說的一句話是：「Show me Something to eat!」除了成堆文件之外，客戶希望看到實際的東西，最終專案宣告失敗。David接手後，丟掉數以噸計的文件，採用敏捷的FDD（Feature Driven Development，特性驅動開發）方法論，結果出奇成功地在期限與預算內結案。
這表示敏捷的流程比較好嗎？在微軟舉辦的企業軟體工程高峰會中，便有使用者詢問，他們採用XP方法論，初期很順利，但開發到一定規模之後，逐漸面臨重構的困難，導致進度持續延宕。
再看看目前臺灣軟體界興起的CMMI全民運動，似乎為臺灣軟體開發流程品質找到了改善的契機，但若軟體廠商以通過「評鑑」為目標，實際開發專案仍以老方法做事情，大家也可以共同檢視品質改善的成果。
步驟１：考量自身的特質
成功的案例值得參考，失敗的教材不代表理論本身有問題，而是應該依據專案性質的不同，調整或混合應用成為真正適合的開發流程，並允許團隊在執行過程中，做必要的彈性修改。胡佑長認為：「流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。」
此外，胡佑長強調：「不要迷信最佳實務。」流程改善工程，大家都希望尋求參考的「範本」，然而並沒有「一體適用」或所謂的「最佳實務」存在，流程是需要量身訂作的。
凌群電腦研發二處經理鄧大宇，以3次參與導入CMMI的經驗分析：「即使同一集團的不同企業體，流程也有很大的差異。」凌安電腦是凌群電腦集團於大陸投資的子公司，鄧大宇協助凌安電腦導入CMMI Level 3時，曾以凌群電腦的流程提供參考，最終卻修改了60%以上的內容。
步驟2：尋找改善的目標
與其硬套別人的學說或理論，不如基於既有習慣的開發流程，調適成為標準化的步驟，再參考其他方法論的作法，補強自身脆弱的環節，就可以形成一個量身訂作的最佳流程。
至於什麼是脆弱的環節，鄭炳強認為：「如果某些問題一再發生，就需特別針對重複出現的問題，設計因應的流程。」軟體開發最常發生的問題，是層出不窮、無法預期的臭蟲（Bug），凌群電腦長達10年的品質改善工程，便是起因於臭蟲，進而開始學習測試的方法，建立專責的測試單位與測試流程，由測試又引發一連串對品質各環節的重視。
周忠信認為：「管理者可以從想『看』什麼，作為思考流程的出發點。」敏捷的流程，注重溝通與互動，文件與控管相對較少；如果希望掌握工作的細節，流程的設計必定複雜，那麼RUP或許是不錯的選擇。
此外，專案與產品導向的軟體，開發的流程是不同的。資訊單位面對主管今天提出需求，明天就希望看到成果的要求，從「服務」的角度思考，流程的設計與產品導向的流程絕對是不同的。
步驟3：從簡單開始
從資策會工程研究所的案例分析，導入RUP需要對架構與概念有一定程度的了解，因為專案負責人李至霓對RUP與Java均有相當程度的了解，再加上團隊成員人數少且實力平均，所以李至霓在每個階段，都親自示範一個功能的實作，工程師就可以跟著依樣畫葫蘆產出其他功能的實作。
但是對於剛開始改善流程的企業，周忠信建議：「簡單就是美。」簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。
David Anderson表示：「流程應該像汽車的引擎，發動之後就自動運行。」好的流程是無感的，觸發以後便自然推動每個環節的進行。
步驟4：先訂流程，再選工具
鄭炳強建議：「從簡單流程的開始，初期甚至不需要電腦工具。」利用人工化的流程，觀察初期的使用情況，並做必要的調整，待專案團隊達成共識，流程發揮效益後，再考慮自動化，提升工作的效率。
根據景華科技顧問協助軟體公司導入CMMI的經驗，第一階段設計流程、表單與控管機制，經過不斷地討論、試行與調整，找出最適合也最有效益的流程。在流程逐漸固定，也看出改善的效益後，才會選擇工具來搭配流程，享受自動化的好處。
屈就工具制訂流程是本末倒置的作法，一開始就自動化，套用僵硬的流程，只會造成困擾。企業應該先定義流程，然後選擇適合的工具，讓工具配合流程的需求，才不會限制了流程的可能性。
步驟5：持續改善
改善是持續的過程，企業發現新的問題時，再針對問題改善流程，才能強化應變的能力。所以流程絕非不是一陳不變，就像CMMI不是通過評鑑就結束。
凌群電腦在CMMI評鑑的前兩天，仍然在修改流程，評鑑過後又立即擬定了新的改善計畫。當你對企業軟體開發流程的強弱環節瞭若指掌時，可以變化的花樣就多了。
XP訴求以最佳智慧做出客戶最想要的東西
敏捷軟體開發聯盟宣言
● 個人及互動勝於流程和工具
● 可用的軟體勝於詳盡的文件
● 與客戶合作勝於合約談判
● 回應變更勝於墨守計畫
導入XP（eXtreme Programming，極限製程）的第一步就是拿起扳手與螺絲起子，動手拆隔板，因為XP強調的溝通、簡單、回饋與決心這4個價值觀，以及12項實務，主要精神說穿了就是貫徹「溝通」兩字。
XP是以少數人力在短時間開發系統的方式，適合2～12人的開發團隊，特別適合應用在需求經常改變的領域，因為需求的不確定性，所以相當重視客戶在開發過程所扮演的角色。管理者、客戶及開發人員對XP而言，都是專案的成員，必須透過充分的溝通與回饋，讓每個成員了解目前的版本能否滿足需求。
12項實務貫穿XP的核心精神－溝通
仔細研究XP，會發現以下12項實務多數只是為了達到充分溝通的手段：
1. 客戶駐廠：為方便隨時隨地的溝通，因此客戶必須駐廠，即時地回饋意見，並確認目前的版本能否符合需求。
2. 系統隱喻：XP並沒有系統分析師（SA）、系統設計師（SD）與程式開發人員等區別，每個人都扮演SA、SD和程式開發者的角色，直接跳過需求分析的階段，藉由客戶駐點面對面溝通的方式，取得第一手的需求，並直接做給客戶看，目的是為了做出符合客戶真正想要的東西。
而隱喻是為了讓客戶與開發者以共通的語言，確保彼此的溝通沒有誤解。以實際的比喻或故事，取代冗長而難以理解的文件，比喻可以與IT無關。例如說明授權機制可以舉實際生活的例子說明：一棟房子有很多層樓，每一層又很多房間，而某人的鑰匙只能開啟9樓A室的房間。總之盡量以易於了解的方式，表達需要的功能。
3. 通盤規畫：透過使用案例（User Story）發掘與評估需求，並在卡片（Story Card）寫上對需求的描述，讓開發者得以根據客戶的描述切割工作量，並確保在穩定的周期內，發布新的版本。
4. 小階段發行：依據Story Card切割工作，分階段發行新版本，而且必須是可執行的版本。
5. 簡單設計：今天的需求可能明天就改變，預留彈性反而是包袱，而且環境與技術都會改變，因此不去預想未來可能的功能，盡可能保持符合需求的最簡單版本。
6. 測試先行：XP的創始者Kent Beck提出的測試哲學，包括單元測試與整合測試。單元測試由開發者在撰寫系統程式前先寫測試程式，所以專案應有25~50%的時間是開發測試程式；而整合測試才是由測試人員負責。
7. 編程標準化：包括命名原則、編碼風格、函數、類別設計、繼承、運算符號等，設定一致的表現方式，提高程式的可讀性，將有助於改善軟體品質、提高開發效率並簡化維護工作。
8. 重構：在每個小階段發行、每個往覆式（Iteration）的周期後，甚至是每天下班前都可以執行一次重構，以保持程式碼的乾淨、簡單且具表達性。
9. 搭檔編程：兩個人共同開發一隻程式，一個人寫程式，另一個人看程式，檢視是否有錯誤或可改進的地方。兩人經常互換角色，這麼做的目的，是藉由充分的溝通與交流提升團隊整體的能力。
10. 共同維護：搭檔編程的搭檔關係，也需要經常替換（Switch Pair），讓每個人都可以維護系統的每個部分。
11. 持續整合：在開發期間，每一組搭檔可以隨時在測試過後，將程式簽入整合至系統，並諮詢其他搭檔執行所有測試，所以XP一天可能建構系統好幾次。
12. 每周40工時：為避免精疲力盡，XP希望以持久穩定的步調，維持高品質的工作效率，不借用明天的精力，強求在今天多完成一些工作，因此XP不允許團隊超時工作。唯一可以超時工作的例外，是發行前的最後一周，做最後的衝刺。
測試驅動的開發流程
XP之類的敏捷開發方法論，其輕巧特質，頗受開發者認同，然而大家著眼於其簡單設計與靈活因應需求改變的主張，卻往往忽略XP是測試驅動（Test Driven）的開發方法論，「測試」是必要的條件，若未撰寫測試程式，便不算是XP。
需求恆變是許多專案團隊抱怨的問題，然而XP的建議是擁抱改變，測試案例的目的，就是為了因應改變。以XP的經驗來看，透過錄製使用者介面的操作劇情，所執行的測試太過脆弱，系統底層很多功能與使用者介面無關，可能導致測試的漏洞，而建置健全的測試案例將使專案無懼改變。
未著手寫程式前，如何寫測試「程式」的程式？事實上，寫測試程式本身就是在進行系統的細部設計，寫測試程式前，必須決定Class（類別）的命名、參數為何、功能為何等。從測試的角度分析，叫用者（Caller）的觀點將多於開發者觀點，有助於設計更彈性、易用及簡潔的系統。
而先寫程式再寫測試的問題，在於開發完成後，團隊往往會缺乏動力，而且可能因為遺漏，使得有些程式沒有測試到，或者也可能將測試寫得太複雜。
強調不拘型式的文件
XP的「文件無用論」廣受IT界爭議：一個沒有文件的專案，後續的維護性令人質疑。其實XP有文件，而且是不拘型式的文件，以「Story Card」說故事打比方、畫UML圖、拍下白板上畫好架構的圖，甚至手繪的各種圖或文，都可以是文件的一種。
更重要的是，軟體會變，文件會過時，所以最好的文件是程式碼。為了讓程式擁有像文件一樣的可讀性，所以必須落實編程標準化，以同樣的風格撰寫程式，才能降低對文件的依賴性。
需求分析各個方法論的派別均有不同的作法，以下簡述RUP（Rational Unified Process）、XP（eXtreme Programming）、MSF（Microsoft Solutions Framework）及鼎新研發的MDM（Model Driven Methodology）開發方法論需求分析的方法：
RUP：使用案例（Use Case）－在需求分析階段繪製使用案例圖（Use Case Diagram），描述操作者（Actor）的行為模式。
一個使用案例就是一個系統功能，不過，使用案例沒有描述使用者介面，是在User Interface Analysis中建立User Experience Model作為使用介面製作的依據。
XP：客戶駐點及User Story－XP並沒有需求分析的過程，每個人都身兼分析師、設計師與開發者的角色，而且開發者與使用者均是專案團隊的成員。藉由客戶駐點使用者提供第一手的需求描述，開發者根據使用者的描述，或Story Card的內容，產出可執行的版本，交給使用者確認，再根據使用者的回饋，持續修正或增加新的功能，經由一次次反覆的互動與調適，最後實作出最貼近需求的產品。
MSF：案例（Scenario）－案例與RUP的使用案例（Use Case）的精神類似，利用案例反映不同角色的使用者的需求。「Persona」就代表不同角色的使用者，類似RUP Use Case中的Actor（操作員），其用意類似劇本中的演員，呈現了使用者的角色、行為、背景與動機等，例如惡意使用者的操作行為與一般使用者的行為模式便有很大的不同。以區分角色與行為模式的方式，更貼近真實的系統需求。
鼎新MDM：模型驅動－軟體需求的表達太過抽象，可能使用者描述不清；也可能開發者理解有誤；更多的例子是使用者看到實際的成品後，才知道怎麼做是符合需求的。
鼎新希望在需求分析階段徹底解決可能的誤差，以模型導向的方式，改變生產流程，並創造了塑模師的角色，提前呈現系統的面貌，讓使用者在需求定義階段，就確認系統是不是他們要的樣子。
流程改善5步驟－沒有偉大的流程，只有適合的流程
專家觀點
鄭炳強
●國立中山大學資管系教授
●臺灣軟體工程學會理事
●高雄醫學大學資訊處顧問
“在選擇開發的方法與工具之前，一定要先了解它的缺點與限制。”
周忠信
●東海大學資訊工程系教授
●臺灣軟體工程學會理事
●鼎新電腦技術總顧問
“簡單就是美。簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。”
胡佑長
●美國SEI授權臺灣首位CMMI主任評鑑員
●寶發科技總經理
“不要迷信最佳實務。流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。”
David Anderson
●微軟總部參與MSF設計的Visual Enterprise Studio部門流程架構師
“流程應該像汽車的引擎，發動之後就自動運行。”
軟體開發流程的學派林立，從輕量級的如XP、SCRUM、FDD到重量級的RUP有多種選擇。不過，所有知名的理論，都找得到成功案例與和失敗教材，企業應考量自身的規模、文化、人員素質、開發方式及開發團隊的成熟度，選擇適合的流程，並允許保留調適的空間，硬套死板的理論或僵硬的工具，其實無法複製他人成功的經驗。
標準化是為了強化控管
軟體專案不能沒有管理，而管理必須透過計畫與流程落實。專案初期制訂的計畫都很理想，但是經過長時間的演變，實際情況往往與計畫脫勾。
制訂標準化的流程，開發階段的所有活動，便可區分為「進行中」、「完成」、「停滯」或「延遲」等各種狀態，其實與Workflow的概念類似，透明化的資訊，幫助管理者掌握實際的進展，便可有效地追蹤與管理分析、設計、開發、測試等各項活動執行的情況。
「制度」會帶來相對的「限制」，不過，寶發科技總經理胡佑長：「企業越希望靈活，就越需要制訂流程。」流程與靈活並不衝突，如果流程無法因應改變，表示流程過於死板而需要改善。
選擇方法論前，先了解缺點與限制
軟體開發的方法論很多，每一種都有令人嚮往的好處。不過，中山大學資訊管理系教授鄭炳強認為：「在選擇方法與工具之前，一定要先了解它的缺點與限制。」例如採用XP的前提，是擁有實力堅強的開發團隊；RUP不適合無法以使用案例（Use Case）描述需求的專案。若選擇了錯誤的方法，會為專案帶來無窮的困擾。
任何方法論找得到失敗的案例，微軟總部Visual Enterprise Studio部門流程架構師David Anderson分享在過去參與新加坡銀行開發信用貸款系統的經驗，在David加入前，原先採用RUP方法論，耗時3年產生3,500頁的文件，客戶最常說的一句話是：「Show me Something to eat!」除了成堆文件之外，客戶希望看到實際的東西，最終專案宣告失敗。David接手後，丟掉數以噸計的文件，採用敏捷的FDD（Feature Driven Development，特性驅動開發）方法論，結果出奇成功地在期限與預算內結案。
這表示敏捷的流程比較好嗎？在微軟舉辦的企業軟體工程高峰會中，便有使用者詢問，他們採用XP方法論，初期很順利，但開發到一定規模之後，逐漸面臨重構的困難，導致進度持續延宕。
再看看目前臺灣軟體界興起的CMMI全民運動，似乎為臺灣軟體開發流程品質找到了改善的契機，但若軟體廠商以通過「評鑑」為目標，實際開發專案仍以老方法做事情，大家也可以共同檢視品質改善的成果。
步驟１：考量自身的特質
成功的案例值得參考，失敗的教材不代表理論本身有問題，而是應該依據專案性質的不同，調整或混合應用成為真正適合的開發流程，並允許團隊在執行過程中，做必要的彈性修改。胡佑長認為：「流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。」
此外，胡佑長強調：「不要迷信最佳實務。」流程改善工程，大家都希望尋求參考的「範本」，然而並沒有「一體適用」或所謂的「最佳實務」存在，流程是需要量身訂作的。
凌群電腦研發二處經理鄧大宇，以3次參與導入CMMI的經驗分析：「即使同一集團的不同企業體，流程也有很大的差異。」凌安電腦是凌群電腦集團於大陸投資的子公司，鄧大宇協助凌安電腦導入CMMI Level 3時，曾以凌群電腦的流程提供參考，最終卻修改了60%以上的內容。
步驟2：尋找改善的目標
與其硬套別人的學說或理論，不如基於既有習慣的開發流程，調適成為標準化的步驟，再參考其他方法論的作法，補強自身脆弱的環節，就可以形成一個量身訂作的最佳流程。
至於什麼是脆弱的環節，鄭炳強認為：「如果某些問題一再發生，就需特別針對重複出現的問題，設計因應的流程。」軟體開發最常發生的問題，是層出不窮、無法預期的臭蟲（Bug），凌群電腦長達10年的品質改善工程，便是起因於臭蟲，進而開始學習測試的方法，建立專責的測試單位與測試流程，由測試又引發一連串對品質各環節的重視。
周忠信認為：「管理者可以從想『看』什麼，作為思考流程的出發點。」敏捷的流程，注重溝通與互動，文件與控管相對較少；如果希望掌握工作的細節，流程的設計必定複雜，那麼RUP或許是不錯的選擇。
此外，專案與產品導向的軟體，開發的流程是不同的。資訊單位面對主管今天提出需求，明天就希望看到成果的要求，從「服務」的角度思考，流程的設計與產品導向的流程絕對是不同的。
步驟3：從簡單開始
從資策會工程研究所的案例分析，導入RUP需要對架構與概念有一定程度的了解，因為專案負責人李至霓對RUP與Java均有相當程度的了解，再加上團隊成員人數少且實力平均，所以李至霓在每個階段，都親自示範一個功能的實作，工程師就可以跟著依樣畫葫蘆產出其他功能的實作。
但是對於剛開始改善流程的企業，周忠信建議：「簡單就是美。」簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。
David Anderson表示：「流程應該像汽車的引擎，發動之後就自動運行。」好的流程是無感的，觸發以後便自然推動每個環節的進行。
步驟4：先訂流程，再選工具
鄭炳強建議：「從簡單流程的開始，初期甚至不需要電腦工具。」利用人工化的流程，觀察初期的使用情況，並做必要的調整，待專案團隊達成共識，流程發揮效益後，再考慮自動化，提升工作的效率。
根據景華科技顧問協助軟體公司導入CMMI的經驗，第一階段設計流程、表單與控管機制，經過不斷地討論、試行與調整，找出最適合也最有效益的流程。在流程逐漸固定，也看出改善的效益後，才會選擇工具來搭配流程，享受自動化的好處。
屈就工具制訂流程是本末倒置的作法，一開始就自動化，套用僵硬的流程，只會造成困擾。企業應該先定義流程，然後選擇適合的工具，讓工具配合流程的需求，才不會限制了流程的可能性。
步驟5：持續改善
改善是持續的過程，企業發現新的問題時，再針對問題改善流程，才能強化應變的能力。所以流程絕非不是一陳不變，就像CMMI不是通過評鑑就結束。
凌群電腦在CMMI評鑑的前兩天，仍然在修改流程，評鑑過後又立即擬定了新的改善計畫。當你對企業軟體開發流程的強弱環節瞭若指掌時，可以變化的花樣就多了。
XP訴求以最佳智慧做出客戶最想要的東西
敏捷軟體開發聯盟宣言
● 個人及互動勝於流程和工具
● 可用的軟體勝於詳盡的文件
● 與客戶合作勝於合約談判
● 回應變更勝於墨守計畫
導入XP（eXtreme Programming，極限製程）的第一步就是拿起扳手與螺絲起子，動手拆隔板，因為XP強調的溝通、簡單、回饋與決心這4個價值觀，以及12項實務，主要精神說穿了就是貫徹「溝通」兩字。
XP是以少數人力在短時間開發系統的方式，適合2～12人的開發團隊，特別適合應用在需求經常改變的領域，因為需求的不確定性，所以相當重視客戶在開發過程所扮演的角色。管理者、客戶及開發人員對XP而言，都是專案的成員，必須透過充分的溝通與回饋，讓每個成員了解目前的版本能否滿足需求。
12項實務貫穿XP的核心精神－溝通
仔細研究XP，會發現以下12項實務多數只是為了達到充分溝通的手段：
1. 客戶駐廠：為方便隨時隨地的溝通，因此客戶必須駐廠，即時地回饋意見，並確認目前的版本能否符合需求。
2. 系統隱喻：XP並沒有系統分析師（SA）、系統設計師（SD）與程式開發人員等區別，每個人都扮演SA、SD和程式開發者的角色，直接跳過需求分析的階段，藉由客戶駐點面對面溝通的方式，取得第一手的需求，並直接做給客戶看，目的是為了做出符合客戶真正想要的東西。
而隱喻是為了讓客戶與開發者以共通的語言，確保彼此的溝通沒有誤解。以實際的比喻或故事，取代冗長而難以理解的文件，比喻可以與IT無關。例如說明授權機制可以舉實際生活的例子說明：一棟房子有很多層樓，每一層又很多房間，而某人的鑰匙只能開啟9樓A室的房間。總之盡量以易於了解的方式，表達需要的功能。
3. 通盤規畫：透過使用案例（User Story）發掘與評估需求，並在卡片（Story Card）寫上對需求的描述，讓開發者得以根據客戶的描述切割工作量，並確保在穩定的周期內，發布新的版本。
4. 小階段發行：依據Story Card切割工作，分階段發行新版本，而且必須是可執行的版本。
5. 簡單設計：今天的需求可能明天就改變，預留彈性反而是包袱，而且環境與技術都會改變，因此不去預想未來可能的功能，盡可能保持符合需求的最簡單版本。
6. 測試先行：XP的創始者Kent Beck提出的測試哲學，包括單元測試與整合測試。單元測試由開發者在撰寫系統程式前先寫測試程式，所以專案應有25~50%的時間是開發測試程式；而整合測試才是由測試人員負責。
7. 編程標準化：包括命名原則、編碼風格、函數、類別設計、繼承、運算符號等，設定一致的表現方式，提高程式的可讀性，將有助於改善軟體品質、提高開發效率並簡化維護工作。
8. 重構：在每個小階段發行、每個往覆式（Iteration）的周期後，甚至是每天下班前都可以執行一次重構，以保持程式碼的乾淨、簡單且具表達性。
9. 搭檔編程：兩個人共同開發一隻程式，一個人寫程式，另一個人看程式，檢視是否有錯誤或可改進的地方。兩人經常互換角色，這麼做的目的，是藉由充分的溝通與交流提升團隊整體的能力。
10. 共同維護：搭檔編程的搭檔關係，也需要經常替換（Switch Pair），讓每個人都可以維護系統的每個部分。
11. 持續整合：在開發期間，每一組搭檔可以隨時在測試過後，將程式簽入整合至系統，並諮詢其他搭檔執行所有測試，所以XP一天可能建構系統好幾次。
12. 每周40工時：為避免精疲力盡，XP希望以持久穩定的步調，維持高品質的工作效率，不借用明天的精力，強求在今天多完成一些工作，因此XP不允許團隊超時工作。唯一可以超時工作的例外，是發行前的最後一周，做最後的衝刺。
測試驅動的開發流程
XP之類的敏捷開發方法論，其輕巧特質，頗受開發者認同，然而大家著眼於其簡單設計與靈活因應需求改變的主張，卻往往忽略XP是測試驅動（Test Driven）的開發方法論，「測試」是必要的條件，若未撰寫測試程式，便不算是XP。
需求恆變是許多專案團隊抱怨的問題，然而XP的建議是擁抱改變，測試案例的目的，就是為了因應改變。以XP的經驗來看，透過錄製使用者介面的操作劇情，所執行的測試太過脆弱，系統底層很多功能與使用者介面無關，可能導致測試的漏洞，而建置健全的測試案例將使專案無懼改變。
未著手寫程式前，如何寫測試「程式」的程式？事實上，寫測試程式本身就是在進行系統的細部設計，寫測試程式前，必須決定Class（類別）的命名、參數為何、功能為何等。從測試的角度分析，叫用者（Caller）的觀點將多於開發者觀點，有助於設計更彈性、易用及簡潔的系統。
而先寫程式再寫測試的問題，在於開發完成後，團隊往往會缺乏動力，而且可能因為遺漏，使得有些程式沒有測試到，或者也可能將測試寫得太複雜。
強調不拘型式的文件
XP的「文件無用論」廣受IT界爭議：一個沒有文件的專案，後續的維護性令人質疑。其實XP有文件，而且是不拘型式的文件，以「Story Card」說故事打比方、畫UML圖、拍下白板上畫好架構的圖，甚至手繪的各種圖或文，都可以是文件的一種。
更重要的是，軟體會變，文件會過時，所以最好的文件是程式碼。為了讓程式擁有像文件一樣的可讀性，所以必須落實編程標準化，以同樣的風格撰寫程式，才能降低對文件的依賴性。
專家獨家提供專案強身大補帖
專家獨家提供專案強身大補帖
文⊙李延華
先做好需求分析，否則其餘免談
研究與開發CMM與PSP（Personal Software Process）的Watts Humphrey曾說：「在客戶催促的時候，大部分的工程師就會下意識地做他擅長的事情－Coding。」但若不能在一開始把事情「做對」，後面再多的努力都是白費。
寫程式只是實作設計的過程，跳過前一階段最重要的需求分析與系統設計的過程，是捨本逐末的行為。軟體開發就像開車，若未確認目的地的方向，便一路往前衝，或者抱著且戰且走的心態，便可能多走冤枉路。
IT工程師不如水泥工？先反求諸己
在建築業確認藍圖之後，便依圖施工，客戶不會說：「你先蓋給我看，不喜歡再拆掉重蓋。」但軟體領域，使用者卻有可能隨時在推翻之前的想法。
當水泥工表示：「水泥需要3天才會乾。」大家不會質疑水泥工的說法；但是軟體專案卻經常面臨客戶縮短工時的不合理要求。
IT工程師的專業不如水泥工嗎？目前軟體業正流行CMMI，廠商在努力調整體質的同時，卻也常抱怨：「廠商已經進步到Level 3了；而客戶卻還在Level 0。」對於客戶不合理的要求，或者想法改來改去的善變心態，寶發科技總經理胡佑長認同：「好的需求管理是甲乙雙方共同努力的結果。」（甲方：軟體購買者；乙方：資訊服務廠商）目前政府在大力推動CMMI-AM（Acquisition Module；籌獲模組）便是針對甲方的訓練，希望提升客戶端採購軟體應具備的相關能力。
不過，甲方的改變需要很長的時間，所以胡佑長提出更積極的建議：「乙方可以教育甲方。」甲方不了解軟體開發的「學問」，所以並不明白改變可能造成的影響，如果乙方有很好的流程，或可以提供量化的數據，便有機會說服甲方配合。
景華管理顧問資深經理李吟敏認為：「甲方是需要被教育的，但是怪罪甲方是單方面不負責任的行為。」需求的導出與確認是一門學問，臺灣從學校到企業，這方面下的功夫都太少。在國外的大學，需求分析稱之為「Business Analysis」是兩個學期的課程，每周都出一個題目，學生要學習分析與拆解，並提交完整的報告。
瞎子摸象才導致事倍功半
中山大學資訊管理系教授鄭炳強與學生開會時，都會要求學生記錄會議內容，整理成正式的文件；無獨有偶的，李家同也曾提到要求博幼基金會的小朋友看偵探小說，看完後寫出破案關鍵。會議記錄與讀書心得，都是釐清重點的訓練。使用者對於需求的表達是零散的，導出完整而正確的需求結構，是資訊人員應該具備的專業能力。
鄭炳強強調：「需求分析不只是資料搜集的工作。」純粹資料搜集的結果，就是一項需求對應一個功能，但若理解需求背後是解決何種問題，那麼也許只要10個功能就可以滿足100項需求。「報表」或「功能」只是滿足需求的「手段」而非目的，如果沒有了解背後的意義，就如同瞎子摸象，透過局部的印象，拼裝架構零散的系統，不僅事倍功半，而且開發出四不像的系統。
需求頻繁改變，很可能是因為始終沒有「搔到癢處」，需求分析不只是知道功能該如何運作（How），更要知道為什麼要這樣做（Why），才不會反客為主，被客戶牽著鼻子走。掌握領域知識（Domain Knowledge），贏得客戶的信任，就能主導專案的走向。所有的需求回溯到源頭，該掌握的是產業的精髓，知道客戶的痛才能對症下藥，否則頭痛醫頭、腳痛醫腳，只是治標不治本，才會如此的勞民又傷財。
e化若是競爭力的關鍵，改變是合理的
恆變是IT界唯一不變的現象，事前縝密的需求分析，可以避免大部分使用者說錯，或者開發者意會錯，所導致誤差的情況；然而另一個難解的問題是「Ｉ will know it,when I see it.」當使用者真正看到系統時，才能確認是不是自己想要的，或者又衍生出更好的想法。
鼎新電腦技術總顧問周忠信表示：「軟體界應該認清『變』是合理的現象。」如果e化是協助企業獲利的機制，那麼市場在變，沒道理要求客戶不能變。
若改變是必然的，那麼該著眼的是變更管理，以及讓客戶了解軟體開發的過程，認知修改的時間與金錢具體成本。軟體工程師的說服力不及水泥工，會被討價還價的原因，某種程度是因為軟體開發的過程比較抽象，是看不到也摸不到的。
新的需求引發額外的費用比較容易理解，而需求的修改就必須定義出變更的複雜性與影響的範圍，若能提出具體量化的數據或分析，使用者對於付費或延期交付的接受度便會提高。
文⊙李延華
軟體開發方法論的每個學派，都有一堆的理論基礎，不僅學習不易，而實作上也有許多的限制。那麼撇開深奧的方法論不談，軟體專案有沒有一些基本的準則，就可以提高「永保安康」的可能性？
鼎新電腦技術總顧問周忠信認為：「至少把握需求管理、專案管理、建構管理與測試管理四個最基本的原則。」對於一般的企業而言，以上4個重點就足夠了。
中山大學資訊管理系教授鄭炳強則建議：「能力優良的工程師、用戶需求的深入分析、確實的系統設計與風險評估。」
鄭炳強表示早年剛開始接觸軟體專案時，曾經經手幾個成功案子，反而種下失敗的因子，所以後來遭遇幾次嚴重的失敗，原因是缺乏風險意識與風險管理，以及對於技術能力的過分自信。所以鄭炳強強調：「光有技術其實是不夠的，軟體開發還有許多比技術更重要的東西。」
曾經有軟體廠商抱怨，某個公家機關標案的需求文件，內容竟然只有標題。對於軟體公司而言，若有風險意識，應該要拒絕此類的專案。
先做好需求分析，否則其餘免談
研究與開發CMM與PSP（Personal Software Process）的Watts Humphrey曾說：「在客戶催促的時候，大部分的工程師就會下意識地做他擅長的事情－Coding。」但若不能在一開始把事情「做對」，後面再多的努力都是白費。
寫程式只是實作設計的過程，跳過前一階段最重要的需求分析與系統設計的過程，是捨本逐末的行為。軟體開發就像開車，若未確認目的地的方向，便一路往前衝，或者抱著且戰且走的心態，便可能多走冤枉路。
IT工程師不如水泥工？先反求諸己
在建築業確認藍圖之後，便依圖施工，客戶不會說：「你先蓋給我看，不喜歡再拆掉重蓋。」但軟體領域，使用者卻有可能隨時在推翻之前的想法。
當水泥工表示：「水泥需要3天才會乾。」大家不會質疑水泥工的說法；但是軟體專案卻經常面臨客戶縮短工時的不合理要求。
IT工程師的專業不如水泥工嗎？目前軟體業正流行CMMI，廠商在努力調整體質的同時，卻也常抱怨：「廠商已經進步到Level 3了；而客戶卻還在Level 0。」對於客戶不合理的要求，或者想法改來改去的善變心態，寶發科技總經理胡佑長認同：「好的需求管理是甲乙雙方共同努力的結果。」（甲方：軟體購買者；乙方：資訊服務廠商）目前政府在大力推動CMMI-AM（Acquisition Module；籌獲模組）便是針對甲方的訓練，希望提升客戶端採購軟體應具備的相關能力。
不過，甲方的改變需要很長的時間，所以胡佑長提出更積極的建議：「乙方可以教育甲方。」甲方不了解軟體開發的「學問」，所以並不明白改變可能造成的影響，如果乙方有很好的流程，或可以提供量化的數據，便有機會說服甲方配合。
景華管理顧問資深經理李吟敏認為：「甲方是需要被教育的，但是怪罪甲方是單方面不負責任的行為。」需求的導出與確認是一門學問，臺灣從學校到企業，這方面下的功夫都太少。在國外的大學，需求分析稱之為「Business Analysis」是兩個學期的課程，每周都出一個題目，學生要學習分析與拆解，並提交完整的報告。
瞎子摸象才導致事倍功半
中山大學資訊管理系教授鄭炳強與學生開會時，都會要求學生記錄會議內容，整理成正式的文件；無獨有偶的，李家同也曾提到要求博幼基金會的小朋友看偵探小說，看完後寫出破案關鍵。會議記錄與讀書心得，都是釐清重點的訓練。使用者對於需求的表達是零散的，導出完整而正確的需求結構，是資訊人員應該具備的專業能力。
鄭炳強強調：「需求分析不只是資料搜集的工作。」純粹資料搜集的結果，就是一項需求對應一個功能，但若理解需求背後是解決何種問題，那麼也許只要10個功能就可以滿足100項需求。「報表」或「功能」只是滿足需求的「手段」而非目的，如果沒有了解背後的意義，就如同瞎子摸象，透過局部的印象，拼裝架構零散的系統，不僅事倍功半，而且開發出四不像的系統。
需求頻繁改變，很可能是因為始終沒有「搔到癢處」，需求分析不只是知道功能該如何運作（How），更要知道為什麼要這樣做（Why），才不會反客為主，被客戶牽著鼻子走。掌握領域知識（Domain Knowledge），贏得客戶的信任，就能主導專案的走向。所有的需求回溯到源頭，該掌握的是產業的精髓，知道客戶的痛才能對症下藥，否則頭痛醫頭、腳痛醫腳，只是治標不治本，才會如此的勞民又傷財。
e化若是競爭力的關鍵，改變是合理的
恆變是IT界唯一不變的現象，事前縝密的需求分析，可以避免大部分使用者說錯，或者開發者意會錯，所導致誤差的情況；然而另一個難解的問題是「Ｉ will know it,when I see it.」當使用者真正看到系統時，才能確認是不是自己想要的，或者又衍生出更好的想法。
鼎新電腦技術總顧問周忠信表示：「軟體界應該認清『變』是合理的現象。」如果e化是協助企業獲利的機制，那麼市場在變，沒道理要求客戶不能變。
若改變是必然的，那麼該著眼的是變更管理，以及讓客戶了解軟體開發的過程，認知修改的時間與金錢具體成本。軟體工程師的說服力不及水泥工，會被討價還價的原因，某種程度是因為軟體開發的過程比較抽象，是看不到也摸不到的。
新的需求引發額外的費用比較容易理解，而需求的修改就必須定義出變更的複雜性與影響的範圍，若能提出具體量化的數據或分析，使用者對於付費或延期交付的接受度便會提高。
軟體專案的困難
軟體專案的困難
南亞科技資訊部課經理曾鴻志表示：「制定流程並不難，但真正的落實流程卻有很多的問題存在。」
南亞科技所有的應用系統包括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」的廠商，其承諾令人質疑。
南亞科技資訊部課經理曾鴻志表示：「制定流程並不難，但真正的落實流程卻有很多的問題存在。」
南亞科技所有的應用系統包括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」的廠商，其承諾令人質疑。
訂閱：
文章 (Atom)