從客戶端觀點 思考軟體開發的精神
楊東城 叡揚資訊 技術發展辦公室 經理
在一個資訊展覽會(COMDEX) 上，微軟公司的創辦人比爾蓋茲語重心長的表示：「如果通用汽車（美國最大的汽車製造商）能使他們的科技進展速度如同資訊產業，那麼我們今天的汽車售價僅需廿五美元，每一加侖汽油可以跑一千英哩。」全場來賓皆深有同感並給予他熱烈的掌聲。
為了回應比爾蓋茲的評論，通用汽車當時的總裁傑克威治特別發佈一篇新聞稿，內容重點為：
如果通用汽車科技發展的方式如同微軟一般，那麼我們今天的汽車就有以下特色：
1.汽車每天會毫無理由撞毀(Crash) 兩次。
2.每一次道路標線重漆或是交通標識改變時，你就必須買一輛新車。
3.有時候你的汽車會毫無理由在高速公路上停下來，你只好接受事實，然後重新發動，重新上路。
4.有時候你操控汽車右轉、左轉或倒車時，可能會造成汽車熄火，而且拒絕再度發動，唯一解決方法是重新安裝引擎。
5.每一輛車只能有一名乘客，除非你買的是汽車95/98或汽車NT/2000。即使如此，你還得另加座椅，座椅的價格和汽車差不多。
6.麥金塔（Macintosh，著名電腦製造商）製造一種非常耐用的汽車，由太陽能（Sun，著名系統軟體供應商）推動，速度快五倍，使用方式易學易熟練，但它只使用百分之五的道路。
7.原先儀表板上所有的指示燈，例如：油量、水量、溫度等，現在濃縮成一個，上面標示為一般汽車錯誤。
8.新的座椅要求每個人的臀部要一樣大。
9.安全氣囊彈出之前會問：「你確定嗎？」
10.有時候你的汽車會毫無理由將你鎖在門外，唯一的進入方式是同一時間右手拉門開關、左手轉動車鑰匙、口內咬著汽車天線。
11.不管車主願不願意，通用汽車會要求車主必須購買由通用汽車子公司出版的地圖。如果車主不願意使用並將它丟掉，汽車的效能會銳減百分之五十，如果車主使用別家出版的導航地圖，汽車撞毀(Crash) 的次數會增加。
12.每一次通用汽車推出新車型時，車主必須重新學習駕駛方式，因為新車和舊車的控制方式不盡相同。
13.你必須按啟動才能關閉引擎。
14.車主手冊最後一頁：如果所有救急措施都無效時，請關掉所有窗子，出去再進來。
這雖然只是一個笑話，但卻值得我們好好思考其中隱含的意義。有些部分純屬笑談，但另一部分卻是真實反應出軟體的困難性與特殊性。我相信在微軟工作的人應該不會比在通用工作的人不聰明，但為什麼現在世界第一軟體大廠微軟的軟體卻依然有這麼多的問題呢？我想答案只有一個，就是軟體本身的特殊性所造成這樣的結果，軟體的進展在於能夠涵蓋的範圍越來越廣、執行速度越來越快，從最早只在研究中心做為特殊的科學研究之用，到現在能夠人手操作一台電腦，涵蓋人們的生活、工作等領域，但是，軟體本身的複雜度卻也與日俱增，如何控制軟體的品質一直都是軟體開發世界中永遠的課題。對於軟體開發與汽車之間的差異可能只是一個笑話，但在真實生活上這樣的差異卻往往造就了許多的軟體慘案，從1963年的美國太空總署因軟體問題造成飛往火星的火箭爆炸，損失了1,000萬美金，還有1994年華航名古屋空難、1995年美國航空在哥倫比亞撞山、1997年的韓國空難，到最近台灣的高鐵訂票服務、彩券系統當機等等，這些軟體慘案造成了無數金錢與生命的喪失，因此如何提高軟體的品質是所有的軟體人員與客戶共同的期望。
讓軟體廠商與客戶端「相愛容易、相處也不難」
單以微軟的軟體產品就有如此多的問題與困難，更何況是以專案方式開發的軟體，這其中還有一半的主導權與決定權是在客戶手上。我在軟體業服務了快10 年了，時常聽到客戶與軟體開發人員朋友互相抱怨彼此，而這樣的抱怨不亞於男女之間永遠無法瞭解彼此所造成的誤會，關於男女差異有很多的書籍曾討論過，但面對軟體開發的鴻溝，卻缺少這樣互相瞭解的機會，因此往往造成事倍功半或甚至軟體慘案的發生。當慘案發生時受害的將不只是軟體公司，對客戶產生的損失可能更高。如何預防這樣的結果其實是有些科學的方法，但需要軟體廠商與客戶有相同的共識才能發揮效果。就如同男女之間的感情，我們常說「相愛容易、相處難」，從一開始的蜜月期，到後來逐漸發現現實生活中的種種差異與限制，更有可能當感情出問題時採用造成反效果的措施，互相指責，最後往往走向分手一途。
在台灣軟體廠商與客戶間難解的困境其實也發生在世界的各個角落，這幾年政府努力推動的CMMI，其前身其實也是因為美國國防部發現在軟體委外時充滿無法掌握的變數，因而委由美國卡內基大學軟體工程實驗室(SEI)所訂定的一套用來衡量軟體公司成熟度的模型。在台灣軟體公司目前已經有了不錯的成績，但是在參加一些國內的CMMI研討會中，最常聽到軟體廠商抱怨的話就是，「軟體廠商達到了CMMI的標準，但是客戶沒有達到一樣的成熟度，反而讓開發的成本更高了」。
也許你可以把這當成軟體廠商在推卸責任的藉口，但客觀來看這也可能是一個重要的理由。你如果去找一些較古老的軟體工程書籍，裡面通常都是以軟體開發人員的觀點來說明軟體開發程序，但是如果你看的是較近代的一些軟體工程書籍，或是參考一些現階段流行的軟體開發程序，例如Agile，當中都會專門對「客戶」觀點來加以說明。也就是說軟體工程已經不僅僅是「軟體開發人員」的事，而是包含「客戶」一起組成，然後以共同的觀點來進行軟體開發。關於軟體廠商的軟體工程我們已經有太多的資料了，但是對於客戶的軟體工程則剛屬於起步階段，即使是CMMI ACQ在台灣也都只是剛萌芽而已。
掌握「時程、品質、成本、規模」四大要點
提昇軟體專案成功機率
所以在這篇文章中我想試著以如果我是一個客戶的觀點來說明如何增加軟體的成功機率。如果我是一個客戶，我會需要先瞭解「軟體專案」中關於「時程、品質、成本、規模」彼此的關係：
時程
*根據軟體的規模存在一個不可能再更短的時程，而該時程並無法利用增加人手而達到。根據研究，合理的時程可能是3*(總人月)1/3(Boehm1981)。
*當時程縮短至無法達成的時間點時，軟體廠商最有可能的因應方式就是很快的投入至「Coding」，但結果往往是造成更高的Rework 而增加了時程。
*當面對無法達成的壓力時，最容易被忽略的因子就是「品質」，但忽略「品質」往往會造成後期的「時程及成本」的增加。
*縮短時程最有效的因子只有「規模」，根據80/20原則，先開發最重要的20%的功能。
*一個Delay一年的專案，其實是從Delay一天開始的，一個專案的完成度應該由實際產出的客觀來界定，而非專案成員的主觀認定。
*當專案Miss掉一個Milestone，如果專案的時程與規模不變，沒有太多合理的根據可以支持專案能夠Meet後續的Milestone。
品質
*在軟體初期忽略的一個錯誤，在後期將需花費50-200倍的代價來解決。
*品質是需要花費成本與時間來達成的，在高度壓力下，往往在初期因忽略品質，但後期將付出更大的代價。
*每一次的變更都將造成軟體複雜度的增加，如果沒有給予足夠的時間與人力修改，則軟體本身的穩定性將越來越糟。
*每一次的變更如果無法完整的測試整個系統，沒有人可以擔保系統不會在其他地方發生錯誤，而如果沒有自動化的測試這是不可能達到的。
*系統會動，能夠正常執行不表示系統內部的品質是好的，在駱駝被最後一根稻草壓垮前是很難從表面上看出來。
*選擇有品質的軟體廠商，往往比一開始選擇看似便宜的軟體廠商最後所花費的總成本是更低許多的。
*品質的好壞不是靠廠商的品牌或是掛在嘴上的說法，而必須是清楚可見的。
*一個亂七八糟的系統，其實是從第一行程式碼開始，更甚至於是從還沒有開始寫程式之前就已經決定了。
成本
*如果選擇錯誤的軟體廠商，即使一開始的成本看似低廉，但最後的結果往往會超過一開始選擇合理成本的優良軟體廠商。
*一個系統驗收上線並不表示花費的停止，一個無法維護的系統對客戶造成的商業成長限制往往遠超過該軟體本身的開發成本。
*增加專案的人手並不等於就能夠縮短專案的時程，人員的溝通與管理問題將隨著人手的增加呈現快速的成長。
*在錯誤的時機點（例如：已經Delay的專案後期）增加人手，往往會造成專案更加的Delay。
規模
*將所有軟體廠商的產品特色集中在一起變成一個專案的規格所需的成本不等於直接購買所有產品的價格總和。
*在軟體專案的世界，想用買腳踏車的錢來買一台賓士，最後只能夠買到一台掛著賓士標誌的壞掉的腳踏車。
*不同的關鍵人員對於軟體專案所想要的功能往往是衝突的，沒有客戶高層參與的專案往往失敗於較不重要的需求所產生的蔓延。
*對一個已經完成的系統修改或增加功能所需的時程與成本一定比在需求階段就提出所增加的時程與成本高出許多。
*需求往往跟隨著專案的進行或是系統的使用才逐漸清楚，大部分的專案在一開始的時候規模都只是預估而已。
*變更是軟體開發的常態，要求不能變更是不可能的，但如何合理的處理變更是現代軟體開發的關鍵
實踐「客戶端」軟體專案的責任與要求
不知道各位讀者看到這裡的感覺如何？我自己寫完了以上的內容之後有點覺得好像都在說廢話的感覺，就好像是我們都希望身體健康，也知道都要經常的運動，重視飲食，早睡早起.... 但是在實際生活中卻常常反其道而行。不過雖然我們不見得做得到讓身體健康的總總行為，但是我們至少還知道那些行為是有幫助的。從本篇一開始的笑話來看，單是「軟體廠商」自己在開發軟體產品上就已經困難重重了，更何況在一般的軟體專案中，有著「軟體廠商」與「客戶」兩種的觀點，如果我們不能夠將這兩種觀點找出一個共同一致的看法，往往會因為偏重某一個觀點而忽略了其中某一個重要的因素，造成整體的失敗或至少額外增加許多無效的Effort，為已經岌岌可危的軟體專案帶來更多負面的影響。
如果我是客戶，對於軟體專案我會有這樣的責任與要求，但這些責任與要求必須是互相搭配的，你不能只要求品質而不願在時程、規模與成本上同時一併考量：
品質
*品質是唯一不可妥協的要求，因為不好的品質將造成無法彌補的結果，甚至於無法維護的專案，因而造成企業成長的限制。
*專案管理的品質：希望能夠清楚的看到專案的計畫與執行的過程及產出，不需要額外整理文件，但是要能夠每天都可以看到跟專案團隊相同的資訊，從當中可以清楚的判斷出該專案目前的狀況。
*重要的產出需要該專案團隊進行「審查」的行為，並且必須要花費足夠的時間及找出可能的問題。
*影響深遠的決定需要該團隊評估出至少三種的解決方案，並由其中客觀地找出最好的解法。
*系統必須有一致性的外觀與操作行為，並滿足效能、穩定性等非功能性需求。
*對於程式碼在一開始就要求進行抽樣的Code Review行為，並且程式碼必須是一個接受過簡單訓練的工程師能夠看得懂的。
*對於程式要求至少進行每日自動化之測試，並且程式碼涵蓋率至少必須達到80%左右。
時程
*時程是一般專案第二要求的重點，因為他會影響客戶後續的商業策略規劃與資源的佈局。
*Delay可能是由於客戶未能適時的決定需求或是審閱文件造成的。
*當時程無法合理的達成時（可從專案進度追蹤發現），客戶可以決定規模的優先順序，將重要的核心功能優先完成，後續的功能可預留未來的空間。
*何謂合理的時程與規模需由雙方彼此的專家共同達成共識（可使用合理的估算模式）。
*當需求變更足以影響時程的時候，需由雙方關鍵人員共同討論影響的幅度，並將新需求納入原有之規模中重新進行優先順序的調整。
*根據專案特性，建議選擇合適的生命週期模式，對於需求較不確定的專案，建議採用Iteration的生命週期模式。
規模
*系統的目標與需求是由客戶決定，但是客戶也必須訂出合理的需求優先順序以滿足品質與時程的限制。
*需求的優先順序必須經由客戶端的關鍵人員共同討論，而非單由個別人員就決定整個系統的需求（客戶的需求也可能是衝突的，例如：資訊人員與使用者便有不同的考量）。
*需求必須是明確可測試的，並且在需求確認之後將由客戶來訂定出相關的驗收測試個案。
*在「增加專案人員工作的時間」、「在專案後期增加人手」、「延遲專案的時程」當中，做出選擇前客戶仍應考量是否可以調整需求的順序。
成本
*要求軟體廠商完成華麗但非核心需求的功能往往增加系統的複雜度，對長期來看可能是增加客戶成本的行為。
*如果改變客戶的流程能夠讓系統的複雜度降低，這是一個有效的降低成本的方式。
成本分析來決定對彼此都有利的減緩或應變措施。
*客戶應避免只為了讓客戶自身看懂而要求撰寫的文件，如果這是一般性的技術能力，那麼客戶應該要求自己去學習而減少專案產出不必要文件的成本。
融合「軟體廠商」及「客戶」觀點 邁向軟體專案雙贏局面
雖然我已經盡可能的讓自己從「客戶」的觀點來思考，但由於我還是一個屬於「軟體公司」的成員，在思考的觀點上很可能還是隱含著「軟體公司」的框框而有失偏頗，但重點在於這樣的思考時必須由「專案整體」的利益來做考量，以賽局理論的觀點來看軟體開發，如果我們不能夠同時站在彼此的角度上來思考，那麼我們所能得到的往往不是一個最佳解決方案，甚至可能是雙輸的結果，而付出代價的將不只是「軟體公司」，而是彼此雙方。最後以Steve McConnell軟體快速開發一書中一段話來彼此勉勵：「我們都幻想有一個簡單的解決方案可以解決開發速度的問題，但簡單的解決方案只能解決簡單的問題，軟體的開發不是一個簡單的問題。對於每一個複雜的問題都會有一個簡短但不精確的答案- H.L. Mencken」。如果您對於軟體開發有興趣的話，建議您可以購買這本書，他將能提供給你一個不簡單但真實的答案。