從高鐵售票系統談大型公共建設軟體開發專案

本文係投稿於 CNet / ZDNet Taiwan 的上下兩篇文章初稿，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。

這篇文章引來不少爭議，有人認為同人是在為某些組織消毒，所以把同人當人假想敵，而有些情緒性的言詞批評與指責。也有人認為同人說高鐵售票系統未用資料庫技術就是問題所在，以為高鐵售票系統的問題就是迷信新技術。還有人認為，技術才是解決問題的關鍵，要用技術的角度來思考問題才是標準答案。

對於這些意見，同人認為別人的情緒是他的問題，我會寫那篇文章，並不想為誰辯駁，只是提出個人思考的觀點，所以要把同人當成假想敵，想激怒我，本人可沒那麼容易上當。至於看到迷信新技術的推論，實在令人大開眼界，不幸地，這個推論顯然是錯誤的，這就是只會用技術看事情的迷思呀。至於要用技術觀點來思考問題的意見，同人覺得再解釋都顯得多餘了，過去我已談過太多了，碰到沒問題症候群（Gerald M. Weinberg，1986）的患者，這次我選擇躲遠點，明哲保身呀;^)。

以下就是這篇引來不少意見之文章。

高鐵售票系統在上線後產生一連串的問題，除了媒體不斷地報導外，網路上也引起熱烈的討論。其中批評與指責多過讚美，同人對這些意見的感想是「外行人看熱鬧，內行人看門道」。我們是否能從他人的失敗經驗得到些許啟示；還是跟著湊熱鬧，把它當成茶餘飯後的話題，是很值得深思的問題。

於是，當我們基於以上所言的反思來檢視這些評論時，會發現到許多人對高鐵售票系統的批評是不夠成熟，並且他們對問題的了解似乎是不夠深入的。筆者深深地感受到，有些人根據自己的懷疑來推測事實，然後據此提出推論來當作結論；然而，在推論過程中，他們看得見他們所深信的解決方案，但對於問題本身，卻因為過度簡化問題而看不清楚真正的問題。

依照筆者參與軟體開發專案多年的經驗看來，軟體專案的規模與問題的複雜度之間的關係並非如一般人想像的線性關係。我深信大型軟體專案絕對不是只比中小型軟體專案大一點而已，因此不能用做中小型軟體專案的思維模式來思考大型軟體專案的問題，因為其問題的複雜性常超乎我們的想像。

本文以筆者參與過大型軟體公共建設開發的心得與感想，分別在管理面及技術面上，分享個人對專案管理及軟體開發的看法，希望對大型公共建設軟體開發專案，提供一些實務上的經驗以供大家參考。

管理面

管理軟體專案比管理其它產品開發專案要來得困難，探究其主要原因並不在軟體技術難以掌握，而是在軟體開發過程中有高度的不確定性，尤其是軟體抽象的本質更使這些不確定性更難以控制。大型公共建設軟體開發專案更會因為環境的改變及不同利益觀點的關係人（stakeholders）之間對專案產生複雜的交互作用而助長其不確定性。因此，相形之下，大型軟體公共建設專案在管理上，常會顯得格外地困難。

依據筆者在軟體開發實務上的觀察，許多專案管理者，都會想盡辦法在軟體開發過程中，試圖減少軟體開發的不確定性，以降低專案的風險。例如，專案管理者會希望客戶的需求不會改變，為了達到這個目的，軟體開發團隊會花費很多的努力在分析客戶需求上，並要求客戶，在需求一經確認後，不得隨意修改變更。直到所有需求都確認沒問題了，專案管理者才能放心，讓他的開發團隊開始動工做系統設計與程式開發。

然而，要讓客戶不得更改需求，在專案管理實務上，卻是非常困難的。以客戶的角度而言，在看不到真正可讓他們操作的軟體之前，他們很難知道他們真正需要的軟體是什麼，直到他們看到軟體並不能符合他們的需要時，才會了解他們真正需要的軟體需求是什麼。另一方面，客戶使用軟體的環境其實也是會變動的，往往因為客戶作業環境的改變，往往會對軟體需求造成不小的蝴蝶效應，尤其是對於大型公共建設軟體專案而言，問題的複雜性更導致需求相當難以管理。

為什麼大型公共建設軟體專案的問題會如此複雜呢？筆者認為，最複雜也最難解的部分應該歸因為「人」的因素。前已提及，不同利益觀點的關係人之間對專案產生複雜的交互作用也是助長專案不確定性的因素之一。在大型公共建設專案開發的過程中，牽涉到的專案關係人相當多，除了甲方的使用單位、資訊部門、乙方的主要及分包委外服務提供者及甲乙雙方所聘請的顧問以外，還會包括上級政府機關、與系統有關的民眾、甚至立法機關都應包括在內。或許有人會奇怪：這關乎立法機關什麼事？在筆者參與的大型公共建設軟體專案中，就有好幾次因為立法院預算或法案審查的結果而影響到專案的目標，而必須修改合約內容。這些關係人來自不同的組織、擁有不同的專業、對專案有不同的目標與期待；因此，其實對於專案管理者而言，要做好關係人管理，達到同時兼顧所有關係人的期待其實是一大挑戰。

因此關係人之間的目標不相容，而造成利害衝突的現象，其實在大型公共建設軟體專案是相當常見的。例如：委外服務提供者與資訊部門之間常會發生衝突與對立。站在委外服務提供者的立場來看，資訊部門相當難以溝通，在開發過程中不尊重專業，同時對我們開發的成果百般刁難與阻礙；站在資訊部門的立場來看，這麼大規模的專案，我必須善盡把關的職責，委外服務提供者不要以為我們看不懂他在搞什麼，不要想在我面前敷衍了事。而雙方相互鬥法的結果，消耗了相當大量的溝通與代理成本，有了資訊部門擋在中間委外服務提供者也沒辦法取得到使用單位真正的需求，於是開發出來的軟體並沒辦法符合使用單位的需要，於是委外廠商就會掉入無止盡的變更需求的惡夢當中。

此外，主要委外服務提供者與分包委外服務提供者之間，也常會因為目標不相容而產生利害衝突的問題，造成開發過程中系統整合的困難。對於委外服務提供者而言，大型公共建設軟體專案的規模相當大，因此必須依據專業分工將非本身專長的領域分包給其他委外服務提供者，以增進專案開發的效率。然而，對於分包委外提供者而言，這個專案不見得是對公司最重要的專案；因此，有時候分包委外服務提供者會因為自身利益考量而無法配合，甚至違約乃至斷絕合作關係。一旦發生此種現象，將造成系統整合困難，而對整個專案成果將造成莫大的衝擊。因此，主要委外提供者對分包委外提供者的管理，在大型公共建設軟體專案的成功上，扮演著極關鍵的角色。

筆者站在一個資深的軟體開發者的角度來看高鐵售票系統的問題，表面上高鐵售票系統不能符合使用者需求、以及系統無法正常運作等問題，雖然都是顯而易見的實情。但是，我所擁有的軟體開發的經驗與專業卻告訴我：不能只站在表面上來看事情，而是要思考問題背後的問題，要做好大型公共建設軟體專案的需求與整合，本來就比較困難，但推諉責任是沒有意義的，那麼我們可以做些什麼？又該如何做呢？筆者認為，專案管理者應破除需求是不能改變的迷思，在態度上應抱持著擁抱改變的積極態度，用反覆演進的方式逐步調整開發的軟體以滿足使用者的需求。同時，與主要專案關係人之間應建立起足夠的信任，使主要關係人認同大家其實是生命共同體，大家才能真正為共同目標而努力。

技術面

有些人認為，高鐵售票系統會發生重覆劃位的問題，是因為在資料庫設計上面，沒有加上資料庫 unique key 來限制資料的唯一性，或是在確認交易完成前，並未加檢查同一個位置是否已被買走了（筆者認為，他大概指得是類似資料庫寫入時加入 lock 鎖定的機制）。不過，筆者發現這樣的看法可能有問題。因為，據可靠的馬路消息來源指出，高鐵售票系統並未採用資料庫技術。因此，重覆訂票的問題與資料庫表格有沒有設 unique key 或在交易過程中有沒有加入 lock 鎖定的機制是沒有關係的。

因此，當筆者發現許多技術人員，習於以自己所熟知的技術經驗，來尋求問題的解答，卻未先去深入地探討問題，這種問題處理模式其實是相當令人憂心的。因為這種做法，常常會造成設計的盲目現象，當然不可能解決真正的問題。試想，如果我們沒辦法看清楚問題，對問題茫然，又怎能期待真正解決問題呢？

筆者認為，大型公共建設軟體專案在技術上的關鍵，並不在於技術本身，而是開發者的心態問題，也就是開發者深入了解問題之後，選擇可用的技術，並加以不斷的調適、熟練的過程。大型公共建設專案常常不能單純只站在技術的著眼點來看事情，因為除了工程技術（engineering technology）觀點之外，軟體資訊系統往往是社會技術觀點（social technology）下的產物，有時候必須要捨棄從單純技術觀點認為最佳的解法。如同前面所言及的，要兼顧不同關係人的期望與目標，問正確的問題，才能找到最適當的解決方案。

依據筆者的觀察，愈資深的技術人員，在面臨軟體出現功能失常（failure）時，愈容易傾向於用猜測的方式來解決。可能是因為他們自認經驗豐富，問題應該不出於他們的經驗範圍之外，所以不管軟體出現的失常現象有棘手，他們並不想花時間寫測試程式找出軟體的瑕疵（defect）。可能拜開發技術進步及開發工具的強大所賜，筆者近年來也常發現，一些新進的軟體開發者也有這種習慣猜問題來找答案的習慣。

筆者非常不認同這樣處理軟體功能失常的態度，當有人尋求我的支援，協助他（她）找到程式bug的過程中，我都會提醒開發者：問題不要用猜的！我們當然可以假設問題，但必須要去求證，所以不要吝惜寫測試程式或加上程式執行過程的記錄（log）。

到底高鐵售票系統的重覆劃位問題，問題出在什麼地方呢？筆者並未參與其中，同時也不想妄加臆測；因為筆者相信，不管經驗有多麼豐富，我永遠不知道我所不知道的事情，所以經驗往往是最不可靠的東西之一。不過，筆者卻知道，問題不要用猜的，而是要經由穩定及可見的觀察、假設後的求證、尋求問題的對策、最後再採取行動解決的過程，態度才是決定技術得以成功的決定因素呀！

Please follow and like us: