山丘突歐

今天重點不在高鐵台西路段的地層下陷問題、不管重金買入的入口閘門只有現代化的外表、不理狀況頻傳的行車控管機制、不追世界最高貴的高鐵造價的錢流向哪裡。就把重點放在山丘比較了解的專案管理與系統分析上吧！

山丘曾經歷過兩家稍具規模的網路公司的帳務系統，一家B2B的軟體專案公司系統分析師和一家擁有十五家以上子公司的跨國電子表單系統。這些比起高鐵的票務系統來說雖然只是小巫見大巫，但高鐵的票務系統和專案管理的渙散，也真的讓山丘大開眼界。

遲到兩年的專案管理

先看這兩年的一則2003年6月高鐵自己發表的舊聞提到：
『台灣高鐵位在高雄燕巢的總機場預定七月動工，鐵軌舖設也預定在七月展開，台灣高鐵仍樂觀民國九十四年十月可以完工通車。 』
以外包的專案管理標準來看一般會以週為單位，如果大一些也可能以月為單位，細密的訂出每個子專案的關聯與時程(Schedule)，並在專案進行的每一個階段檢驗每個查核點時程是否趕上，不管是明確定出每個檢查點的傳統瀑布式模型(waterfall)，或是可重複檢驗調整的螺旋式模型(spiral)，為了就是一個目的，精準的控制時間，因為時間就是專案最大的成本，人力的成本、辦公室設備租金、營運延後造成的減短收益等等都是一天一天算的，高鐵兩年的延遲的專案，專案經理人責無旁貸。

另外網路上也有人寫文章希望高鐵加強知識管理，我很認同這樣的說法！知識管理正是專案管理中最常被忽略的一環。專案的資訊如何流通，不同部門用什麼方式知到彼此之間的協調狀況，同部門該如何讓整個團隊實力一同成長，而不會只有一兩個厲害的工程師搞個人主義！讓團隊的知識分享變成習慣，讓每個人成員在工作過程中受益，一個好的專案經理真的不好當阿！

系統分析－專案成功的基石
山丘不是高鐵的系統分析師，該如何檢討高鐵的系統分析狀態？其實系統分析就是在動工前找到大部分可能發生的錯誤做出良好的預防規劃，事後檢討就不是什麼系統分析的功力問題。所以寫這篇不代表山丘有多高明，即使山丘這樣滷肉腳的系統分析經驗，事後諸葛一下卻也還綽綽有餘。

• 重複購票與程式互斥問題
  資工系應該是大三的系統分析課中就會花個兩三個小時討論可能發生重複寫入錯誤的臨界區 （Critical Section） 和避免的互斥存取（Mutual exclusion access）的各種策略，這樣的問題看似基礎、簡單，卻是很難做得面面俱到，所以得靠系統分析師事先能把所有臨界區抓出來解決，並且用各種ＱＡ的腳本(scenario)來補足(這裡看來高鐵的QA也有很大的改善空間了)。
• 唯一管道的購票管道
  我想高鐵的需求分析應該早就有多管道的購票規劃，所以才會有「多元化的訂位、付款及取票通路」及「多樣化的付款方式」的對外宣告。目前遲遲沒有推出多元購票的結果看來，正是系統分析出了問題。因為購票方式即使平台各異，但給程式讀取的API應該早就是規格的一部份，接著才針對不同的購買介面給予不同的存取權限，寫不同的用戶端（Client） 程式，通常這樣的用戶端程式（電話訂票、網路訂票等等）通常只需與API溝通，這僅能算一兩個工程師的小專案，以高鐵票務系統的億元的預算，這不過是零頭而已，如今只有自動售票機可用，也真是浪費了這廣大的internet 資源，與存在已久的市話固網。
• 春節來回票分兩次購買
  系統分析師通常在規劃時，會把很多資料寫成參數，遇到春節連續假期或其他的狀況時，只需針對參數調整而無須重寫程式，所以看到了『受系統只能訂14天以內車票的限制』，明顯的，高鐵系統分析師們又是一個很大的錯誤規劃，原本只需修改參數就能達到的功能，卻需要將系統程式修改才能完成。
• 購票速度慢是因為銀行端串接出問題？
  通常銀行端或許因為資訊安全考量，所以會捨棄對效率的追求而導向更嚴謹的安全溝通模式，但這通常是一兩秒以內就可以達成的銀行端的授權與扣款，不至於讓排隊的人潮難以散退。即使真的是銀行出狀況，那麼當初介面溝通沒寫明交易逾時的責任與罰款？而且測試時都沒有測試出銀行端的瓶頸進行改善？

其實山丘在資訊業也工作了七年，很清楚大公司中常常是出一張嘴巴，用口水畫大餅的人卡在重要的位置，拿了許多錢卻沒有實質能力處裡重大的決策，一旦出了錯就要下面的人寫報告，由下面的人承擔所有責任。軟體工程經驗能有部份影響，但需要先知智慧和特殊天份，國外多的是二十來歲就成為架構師、總系統分析師的天才，但國內的軟體業大老板還是像傳統產業用人的方式，重年資、重誇浮的自信表演。

這次高鐵的票務軟體專案由神通電腦所承接，我相信神通裡面一定也有很多厲害的工程師早就看到了這些問題，只是上面的人沒能力思考到問題癥結，也接收不到基層工程師的提醒。但這次出了錯之後，這些工程師們可能得一個一個面對嚴苛的指責與檢討，但高階專案經理人和資深系統分析師呢？是否依舊穩坐了所有位置？

文章快結束前才從Java Wold 上看到了一堆同樣感到不可思議的程式人員討論這件事情，也正好回應了我這一個月來看新聞的感覺，和山丘這篇紀錄的存在意義。

圖片來源

—
再找出一則新聞：所有規格都是高鐵開出，神通只是系統承包商之一
其實專案公司接了專案，對規格也多少有著顧問的責任和義務在，因為發包廠商通常沒有承包商的系統分析經驗，這時候把責任推回給發包廠商的規格制定問題，對山丘來說也是不可思議的。有時候做錯事情除了道歉之外，最佳的方式就是不講話，像這樣推卸責任的感覺只是讓自己越來越難看而已！

很久沒寫些東西，因為最近投入ppolis 的心力太多，大致情況我也寫了一篇在ppolis blog。