當我們檢視這些評論時,會發現到許多人對高鐵售票系統的批評不是很成熟,並且他們對問題的了解似乎是不夠深入的。筆者深深地感受到,有些人根據自己的懷疑來推測事實,然後據此提出推論當作結論;然而,在推論過程中,他們看得見他們所深信的解決方案,但卻因為過度簡化推論而看不清楚真正的問題。
依照筆者參與軟體開發專案多年的經驗看來,軟體專案的規模與問題的複雜度之間的關係並非如一般人想像的線性關係。我深信大型軟體專案絕對不是只比中小型軟體專案大一點而已,因此不能用做中小型軟體專案的思維模式來思考大型軟體專案的問題,因為其中複雜性常超乎我們的想像。
本文以筆者參與過大型軟體公共建設開發的心得與感想,分別在管理面及技術面上,分享個人對專案管理及軟體開發的看法,希望對大型公共建設軟體開發專案,提供一些實務上的經驗以供大家參考。
不確定性因素高
管理軟體專案比管理其它產品開發專案要來得困難,探究其主要原因並不在軟體技術難以掌握,而是在軟體開發過程中有高度的不確定性,軟體抽象本質使這些不確定性更難以控制。大型公共建設軟體開發專案更會因為環境的改變及不同利益觀點的關係人(stakeholders)之間對專案產生複雜的交互作用而助長不確定性。因此,相形之下,大型軟體公共建設專案在管理上,常會顯得格外地困難。
依據筆者在軟體開發實務上的觀察,許多專案管理者,都會想盡辦法在軟體開發過程中,試圖減少軟體開發的不確定性,以降低專案的風險。例如,軟體開發團隊會花費很多的努力在分析客戶需求上,並要求客戶需求一經確認後,不得隨意修改變更。直到所有需求都確認沒問題了,專案管理者才能放心,他的開發團隊開始動工做系統設計與程式開發。
然而,在專案管理實務上,要客戶不得更改需求卻是非常困難的。以客戶的角度而言,在看不到真正可讓他們操作的軟體之前,他們很難知道他們真正需要的軟體是什麼,直到他們看到軟體不符合需要,才會了解他們真正需要的軟體需求是什麼。同時,客戶作業環境的改變,往往會對軟體需求造成不小的蝴蝶效應,尤其是對於大型公共建設軟體專案而言,問題的複雜性更導致需求相當難以管理。
為什麼大型公共建設軟體專案的問題會如此複雜呢?筆者認為,最複雜也最難解的部分應該歸因為「人」的因素。即前面提及的不同利益觀點的關係人。在大型公共建設專案開發的過程中,牽涉到的專案關係人相當多,除了甲方的使用單位、資訊部門、乙方的主要及分包委外服務提供者及甲乙雙方所聘請的顧問以外,還會包括上級政府機關、與系統有關的民眾、甚至立法機關都應包括在內。或許有人會奇怪:這關乎立法機關什麼事?
在筆者參與的大型公共建設軟體專案中,就有好幾次因為立法院預算或法案審查的結果而影響到專案目標而必須修改合約內容。這些關係人來自不同的組織、擁有不同的專業、對專案有不同的目標與期待;因此,其實對於專案管理者而言,要做好關係人管理,達到同時兼顧所有關係人的期待其實是一大挑戰。
IT部門與委外商關係
在大型公共建設軟體專案中,經常見到因為關係人之間的目標不相容造成的利害衝突的現象。例如:委外服務提供者與資訊部門之間常會發生衝突與對立。委外服務提供者覺得資訊部門相當難以溝通,在開發過程中不尊重專業,同時對他們開發成果百般刁難與阻礙。資訊部門則認為:「這麼大規模的專案,我必須善盡把關的職責,委外廠商不要以為我們看不懂他在搞什麼,不要想在我面前敷衍了事。」雙方相互鬥法的結果,消耗了相當大量的溝通與代理成本,有了資訊部門擋在中間委外業者也沒辦法取得到使用單位真正的需求,於是開發出來的軟體並沒辦法符合使用單位的需要,於是委外廠商就會掉入無止盡的變更需求惡夢當中。
主包與下包商關係
此外,主要委外服務業者(主包)與分包委外服務提供者(下包)之間,也常會因為目標不相容而產生利害衝突,造成開發過程中系統整合的困難。由於大型公共建設軟體專案的規模相當大,因此主包者必須依據專業分工將非本身專長的領域分包給其他委外服務提供者,以增進專案開發的效率。然而,對分包業者而言,這個專案不見得是對公司最重要的專案;因此,有時候分包委外服務提供者會因為自身利益考量而無法配合,甚至違約、斷絕合作關係。一旦發生此種現象,將造成系統整合困難,而對整個專案成果將造成莫大衝擊。因此,主包商對下包廠商的管理,在大型公共建設軟體專案上往往扮演著極關鍵的角色。(待續)
7.蓓蓓 於 2008/11/12 12:05 回應
這家軟體開發公司是翱騰嗎?6.匿名 於 2007/09/22 09:32 回應
其實CMMI LA 並沒有什麼了不起,只需要註冊SEI,花錢去上五天課程回來,你就具有資格了,SEI根本不會去研究這些LA的背景經歷,像軟體園區內一家號稱最多LA的CMMI輔導公司,不就是花錢送一堆人去上課就有資格,實際上輔導過的廠商死的死傷的傷,沒有一家大紅大紫。真實原因就是這些號稱軟體工程專家的人,都是一些學歷都跟資訊無關,且經歷更是慘烈,都沒有寫過程式帶過專案的,這樣的人輔導或是做軟體工程評鑑,實在很難想像,這樣的品質可以好到哪裡?這樣難道不是純粹賣證書嗎?
LA也就不難想像品質了,花錢就可以有LA,當然也是收錢就給你證書囉!評鑑的過程也不就是那樣嗎?造造假,做一些證據給你看囉!
台灣軟體業失敗的原因就在於這些假專家,請大家眼睛放亮點!慎思!
5.Eric 於 2007/08/27 08:26 回應
「軟體」存在的目的不就是為了可以隨時改來改去嗎?4.Bala 於 2007/08/09 21:59 回應
客戶不清楚自己的需求?在台灣 這是通病
在先進國家 這是笑話
本人在資訊軟體業十餘年
看盡了上頭一句話 下面一堆人到處揣摩上意而亂提需求的鬧劇
根本忘了資訊系統開發是為了解決問題 而不是製造更多問題
特別是幾乎所有的甲方都不瞭解自己的環境和能力
更不清楚到底該如何有效的解決問題
爭功諉過的下場 資訊系統不出亂子才怪
軟體工程的書說的好
專案管理 就是3P:People Process Procedure(Program)的協調整合
這3P只有Procedure(Program)完全是資訊委外廠商的責任
People and Process ,特別是Process 這不是甲方早就該先想好的嗎?
因此個人認為高鐵的售票系統和一般大型政府專案不同
它的目標應該是明確 流程也是固定的
而且system機電整合的需求並不高
所以最難的People and Process 問題應該出在高鐵公司自己
Procedure(Program)的問題 只是適度反應這家公司內部管理上的問題罷了
3.同人 於 2007/08/03 11:52 回應
在情感上,我認同”受人之託,就要忠人之事,就可以做好關係人管理”,但在理智及經驗上,卻往往發現我們事情往往出乎我們意料之外。為什麼呢?人的問題好複雜耶,除了資訊不對稱之外,利益的不相容所造成的代理問題外,還有對方是否值得信任的風險考量,背景與專業所造成的溝通困難等,都讓做好關係人管理這件事,充滿了變數,這對參與軟體開發實務管理者及開發者而言,是如人飲水,冷暖自知的呀。我相信,回到初心是最美的。讓甲乙雙方共同朝著目標前進,專案才會有成功的機會,這是大家都很清楚的,然而,壞就壞在我們常忽略了目標是有可能是不相容的,你我定義的目標並不同,又不肯明說,一旦熱臉貼上了冷屁股,一場零和的賽局遊戲於是展開。
我常看見有些管理者會有”客戶永遠是對的”的迷失,卻把質疑問題背後的假設的能力拱手讓人,結果只是讓開發團隊陷入泥沼而已,專案當然不會成功,這樣的專案管理者,吾未見其明呀。
供參考。
2.DuanSun 於 2007/08/03 09:23 回應
高鐵這個案子在台灣軟體業引起這麼大的事件,既然大家這麼關心這個案子,如果高鐵同意的話,也許開發商可以考慮乾脆開個研討會,跟大家分享這個案例,總比大家你一言我一語的妄自推斷來得好,多麼具影響力的活教材,值大家瞭解,提升台灣整體軟體專案的經驗,也許有點糗,大家都在討論他們的缺失,但我想他們一定有考量到其他我們不知道的因素,所以乾脆開誠佈公吧.1.匿名 於 2007/08/02 23:29 回應
此篇文章道盡了專案開發者與管理者的心酸,事實上大型公共建設軟體開發專案要讓大部分的人滿意,需要整體的合作與共識,例如"分包委外服務提供者"既然受人之託,就要忠人之事,若能做到的話,相信"做好關係人管理,達到同時兼顧所有關係人的期待"將不會是一項挑戰。