沒有技術的深度與經驗來配合,而只仰賴以溝通、協調與文件撰寫能力來管理專案的專案經理會是我所擔心的。然而這卻是台灣資訊業的普遍現象,沒有人願意做黑手工程師,大家都想去做專案經理,聽說有家公司,剛畢業的學生就可以做專案經理的,甚至還聽說,因為工程師很怕搞技術,所以讓他轉成打雜的專案經理(那時候,還是菜鳥工程師的我真的恨不得昭告世人說我是一個很遜的工程師)。他們並不一定沒有辦法勝任,而是他們往往不能發現隱藏在專案後面的風險。
人員的素質才是關鍵
就我所知,負責開發高鐵售票系統的系統廠商有通過CMMI認證。哇,這樣不是讓CMMI或PMP權威性遭到質疑?我並不是確定是否完全照表操課,專案經理妥善使用PMP中所提到的技術,並且完全遵照CMMI來完成整個系統的開發。不過,不論有沒有,依目前的情況,說CMMI或PMP是用來唬人騙錢是不公平的。舉個例子,飛機起飛的時候,理論都會有一個起飛的標準流程,但如果起飛失敗了,我們可以說是那個標準流程有問題嗎?
當然標準流程是有可能會被修正,不過,飛機起飛的失敗,有可能是天候因素、也有可能是飛機跑道有異常狀況、甚至是機場塔台的錯誤資訊等因素所造成的。其中,往往「飛行員」才是成功起飛與否的關鍵。好的飛行員在惡劣的環境下,他仍然會有機會成功飛上天空,而經驗比較不足的飛行員則可能因著一點其它外在的因素就起飛失敗。但我們並不會說這次的起飛失敗是因為標準流程的問題。
我無意為CMMI或PMP辯護,不過CMMI或PMP有能力規範的應該是在流程及管理層面的事物,規範出好的流程與溝通模式以方便大家做事。但有些東西本來就很難規範,例如:工程師與系統分析師的經驗值、或者測試人員與專案經理的深度。
所以,高鐵車位連三賣的事情,我不覺得它可以說明CMMI行不通或者証明開發廠商沒有照表操課。因為有可能該廠商真的乖乖地每一個流程都跑過了,但就是他們的人員在經驗上可能比較缺乏這種多人使用系統開發的經驗,再加上測試人員沒有想到這方面的問題,而疏忽這個細節才引發這場烏龍事件。
不過,高鐵這個案例倒提醒了我們另外一件事:不要太迷信CMMI或PMP--好的人員素質才是成功的關鍵。想想看,同樣在CMMI的流程規範下,如果換上另外一組比較有經驗的技術人員?測試人員?或者專案經理呢?或許就會是另一個故事了。從上述的討論中,我們會發現,技術人員、測試人員以及專案經理三者之一,只要其中之一(其它兩者都可以不需要)有意識到這問題,其本上就不會有「一位三賣」的情況了。
26.蓓蓓 於 2008/11/12 11:59 回應
這家軟體公司是翱騰嗎?25.匿名 於 2007/09/22 09:08 回應
高鐵售票系統的委外廠商其品管和測試部分,是某家南軟園區內輔導CMMI的廠商所輔導的,結果是一團亂,原因在於該顧問公司雖然號稱是軟體工程專家,但實際上卻是個只做過測試,沒有實際專案開發經驗的人,自然是會失敗囉!24.肯得雞 於 2007/08/24 12:26 回應
這不是售票系統而是自動收費系統
所以流程比一般的售票系統複雜
另前面幾位說的很對
這不是資料庫的問題
而是區間票未考慮周詳造成
學校教是很基本的
而如何活用這些東西
甚至更上一層樓
又是另一個門檻
23.lulu 於 2007/08/06 13:40 回應
我只知道我去買票時問題一堆~網路預訂的票要前30分鐘取~~可是未取的並無法立即拋出給等待買票的人...重點好不容易從台南回台北都沒位子的情況下,買了三小時後的一班台南到台中..想說從站回來好了(別問我為何不改搭客運..因為高鐵都蓋在鳥不生蛋的地方..抱小孩又拖行李再回市區坐也很累)...又回說不能喔~~會罰錢..很危險~~可是真的再下去小孩快受不了了...只好硬坐...結果是..車上有一堆空位回台北..都有地方坐..不知道他們的票務系統是怎樣規劃的呀?王今坐過三次都一肚子鳥氣~~22.路人 於 2007/08/04 15:03 回應
推好文……還是比較喜歡這一篇………
一個系統專案的運作本來就是一個team work 的關係,高鐵系統的問題,在這個專案下的成員是誰都推不了責任……專案經理、DBA、程式設計師、系統分析師、測試人員都有他們自己在這個專案中應該盡的本份……也在這個team work 的關係下,讓專案中的成員可以彼此互相地互補與支持,好讓專案可以順利的完成……
如作者所說的:「……想想看,同樣在CMMI的流程規範下,如果換上另外一組比較有經驗的技術人員?測試人員?或者專案經理呢?或許就會是另一個故事了。從上述的討論中,我們會發現,技術人員、測試人員以及專案經理三者之一,只要其中之一(其它兩者都可以不需要)有意識到這問題,其本上就不會有「一位三賣」的情況了……」
三組人馬中,只要有其中一組,想到這一個問題,一票三賣的情況,應該就不會發生了……
這也是這個案子好玩的地方……這三組人員為什麼都沒有意思到這個問題?
要死不死,這三組人員的經驗都不夠嗎?(不太可能吧,這是國家級的專案耶)
還是三組人員都無心是這件事上呢?
是誰(或者什麼因素)造成了這三組人員在同一個案子上都沒拿出應有的品質呢?
看得出來,這作者好像有點想避而不談這個問題……
不過他也留下了反省的空間………
21.看戲的 於 2007/08/03 13:00 回應
從高鐵談大型公共建設軟體開發專案(上)-連結
從高鐵售票系統談大型公共建設軟體開發專案(下)-
連結
20.DuanSun 於 2007/08/03 09:22 回應
高鐵這個案子在台灣軟體業引起這麼大的事件,既然大家這麼關心這個案子,如果高鐵同意的話,也許開發商可以考慮乾脆開個研討會,跟大家分享這個案例,總比大家你一言我一語的妄自推斷來得好,多麼具影響力的活教材,值大家瞭解,提升台灣整體軟體專案的經驗,也許有點糗,大家都在討論他們的缺失,但我想他們一定有考量到其他我們不知道的因素,所以乾脆開誠佈公吧.19.匿名 於 2007/08/02 22:37 回應
對於作者的觀點文中作者沒有考慮的Muti_thread的觀念
高鐵的訂票程式90%以上是Muti_Thread的開發方式
不是Signal_Thread可以解決的來
這一種狀況不得不多在Muti_Thread的狀況之下
有部份的邏輯是沒考慮到Lock的問題
而且這樣問題也不一定會在StressTest或Integation Test的狀況之下測的出來