2007年1月20日

對台灣高鐵售票系統之我見

超熱門討論串:
  1. 大河馬的創意動物園:大河馬看高鐵自動售票系統
  2. JavaWorld@TW:高鐵,ETC原來都是同一家做的...
  3. 大砲開講:高鐵售票系統品質差嗎?
  4. Morton’s Weblog:高鐵售票系統大小狀況不斷,給台灣資訊業帶來什麼啟示?
  5. 喲哪桑 Speaking:從高鐵售票系統看CMMI
  6. 期待新服務上線的獨孤木:CMMI與大便風牛肉麵
2007-02-12 補充:
  1. 喲哪桑 Speaking | 管理.軟體.產品.專案:品質不好,誰有責任?
  2. 喲哪桑 Speaking | 管理.軟體.產品.專案:Stakeholder Management
  3. 同人的生活派對:內行人看門道,外行人看熱鬧
  4. 獨孤木with diggirl.net:stakeholder是誰?
  5. 關於高鐵的 Stakeholder
熱門討論的重點議題:
  1. 絕大多數的討論認為這是 Programming 上的失誤,是開發團隊的技術能力的問題,尤有甚者連開發人員不熟悉售票系統的 Domain knowledge 之類的言論都跑出來了。
  2. 還有許多的討論都認為且相信這是一套未經測試、匆促上線的系統,所以系統才會在開賣當天立刻陣亡。
  3. 也有些討論是針對合約的大、中、小包問題,導致神通電腦在碰到問題時完全無法掌握實際的狀況。
  4. 另外就是針對事主 神通電腦 所取得的 CMMI Level 3 認證開始有許多評估 CMMI 的討論。不過即使不考慮認不認同 CMMI 的情形,多數人都認為 CMMI 並非解決此脫序系統的密法。最後甚至有 CMMI 只能確保同一個公司的各個專案將有相近的品質,即使品質本身其實非常低劣。對了,國內常見的 ISO-9000 系列認證也是同樣的道理:該認證的內容是指品質的一致性,並非表示品質一定非常精良。
  5. 透過媒體大篇幅的報導該系統由神通電腦所開發後,許多人等著看神通電腦後續要如何去搶標案了。CMMI Level 3 這塊招牌能否發揮搶標案的威力呢?
個人的看法:
  1. 平心而論,要評量這個售票系統專案的成功與否,個人認為答案不會只有『失敗』一種。
  2. 相信在正式售票前,不管是神通電腦還是台灣高鐵恐怕都認為專案是成功的。所以在媒體開始大力批評系統的品質不佳及操作的不合人性時,神通和高鐵都慌了手腳,也因此冒出了一些可作為外人不斷批評的不當言論。
  3. 對高鐵乘客及嗜血媒體而言,這個不合購票習慣又會重覆劃位的售票系統絕對是個失敗的專案。
  4. PMI 認為專案成功的要件是專案成果必須符合專案利害關係人的要求與期望,所以要評量專案成敗前得先瞭解一下各方認知到的專案關係人有那些(只是這樣猜測,若與事實相同純屬意外巧合)。
    1. 神通電腦部份:台灣高鐵、神通電腦、售票系統開發團隊。
    2. 高鐵乘客部份:乘客本身、台灣高鐵。
  5. 因為神通電腦只看到自己人的要求與期望,所以他們認為專案成功了。
  6. 乘客部份發現自己的要求與期望完全未受考慮,所以專案失敗了。
結論:
  1. 技術可以解決的問題通常不應該是個問題(但若是堅持技術絕對沒有問題的情形是例外);技術以外的問題通常才是最麻煩而必須加以協調、妥協的。
  2. 個人相信只要一開始神通電腦能識別出專案的關鍵利害關係人其實是乘客(專案中實際使用系統者的需求永遠需優先被考慮)的話,那麼透過互動應該可以解決以下的問題:
    1. 發現購票流程的煩鎖與不便;
    2. 避免極度不友善的購票流程與操作界面;
    3. 極大的機會發現到重覆劃位的問題(其實這和測試方法關係較大)。