jim yeh on 二月 3rd, 2007

最近高鐵售票系統的問題,在網路上引來許多的的熱烈討論。其中喲哪桑〈從高鐵售票看 CMMI 〉一文中認為神通的問題是開發者與 CMMI 都有問題,有網友針對這個觀點評論說:

就我所知,CMMI是用來規範開發流程,使專案能夠在規定的時間及預算內完成,至於開發出的產品是好是壞,就不是CMMI能控制的了。

另外神通電腦的客戶是高鐵公司,而不是乘客。提需求的是高鐵,驗收的也是高鐵,只要高鐵驗收通過,就不是神通的責任,是高鐵要對民眾負責。

喲哪桑對這則評論另行撰文,並提出:

坦白說,猛然一看我還有點氣,然而再想想,這不正是典型工程師的想法嗎?

「我就只是照規格做哇!你們規格這樣開,我也照著做,明明我沒做錯,為什麼要罵我小小工程師呢?」

唉!這下不只要說ML3的PA沒做好,我還想請神通與高鐵的人去看看PMBOK、看看Stakeholder Management了。

看了這一連串的對話,我發現似乎很多人都可以從高鐵售票系統指出神通的問題,好像他們都變成無所不知的專家,那這樣神通找他們當顧問是不是就會成功了呢?

很明顯地,以上推論並不會成立,為什麼呢?因為那些專家只是在紙上談兵,他們建構了許多假設,然後依據這些假設作出結論。然而那些假設都是未經證實的,所以如果神通找他們當顧問,我想專案要成功就會遭遇更大的風險,因為假設往往是專案風險的主要來源

責怪神通 CMMI 沒做好而導致高鐵售票系統品質不良是沒有意義的,CMMI 只是讓我們可以管理專案(ML2),然後用比較適當的方法來做事(ML3),當然我們也需要知道什麼是比較好的做事方式(ML4),最後可以持續改善及最佳化(ML5);然而不管我們怎麼做,專案永遠會有我們所不想發生的意外發生,不管誰說「不准有意外」,意外還是會發生的(溫伯格,1993),導入 CMMI 並不能防止意外的發生,而是在第一時間就能針對問題做及時而適切的反應。

有網友在獨孤木寫的〈CMMI與大便風牛肉麵〉中發表評論說:「CMMI level3只有到了解流程的程度,要到level4才被認為有做到改善,當然跟品質沒有絕對正比的關係」。其實這樣的想法是有問題的,ML4 不意味著 ML3 更成熟,品質更好。每一種成熟度的品質都是相同的,都要能滿足客戶的需要及組織本身所要解決的問題,因此軟體品質模式是不須有任何道德層次的徧見的(溫伯格,1993)。也就是說面對更複雜的專案、回應客戶更多的需要,我們才會選擇較高的成熟等級,並不是說要高成熟度才對專案品質有所改善。

軟體專案最大的問題是變是不變的真理,千萬不要有我可以取得正確無誤的需求的幻想。當我們拿起教科書來說:你沒有把需求做好,需求要以廣泛的方式確認需求。但我們卻忘了,不管我們怎麼做,客戶和使用者總是不知道他們要什麼,再則永遠有沒有被發現的需求,更不用說開發者與客戶的認知差距了,這些困難會導致我們的需求永遠理不清(Dean Leffingwell & Don Widrig,2003)。所以,我們的道德宣示,對專案的成功根本沒有幫助,因為專案的成功不需要理論家,而是需要實踐家。

所以喲哪桑說了,要神通的人看 PMBOK,讓我這個 PMP 有個疑問:看了PMBOK就能解決問題了嗎?

專案管理不該流於理論而已,沒有自己親身實踐,你是不可能懂得專案管理到底該怎麼做的,相信曾參與過複雜軟體專案的人都知道,專案過程中,我們無法料想到的難題是不可勝數的,專案的成功與否是取決於您的反應是否及時且正確,而不是理論怎麼說。不要忘了,大專案絕對不是比小專案大一點而已,其複雜度與風險的增加是以非線性的成長,絕對不是我們有限的腦容量所能應付的(溫伯格,1993)。

所以與其評論別人什麼沒做到,那裡沒做好,態度有問題等,不如換個立場來看事情-我可以從別人的失敗中學到什麼呢?對於神通而言,跌倒了可以爬起來,順便從地上撿到別人看不到的東西,然而在外圍看熱鬧的人除了看到神通出糗之外,卻什麼也看不到。可惜呀,內行人看門道,而外行人卻只能看熱鬧,專案團隊的辛勤努力不容被抺煞,但他們所帶來的啟示我們看到了嗎?

參考文獻:

  1. 曾昭屏譯,2006,溫伯格的軟體管理學:系統化思考(第1卷),經濟新潮社出版。
  2. Dean Leffingwell & Don Widrig, 2003, Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley Professional.


     

9 Responses to “內行人看門道,外行人看熱鬧”

  1. 喲哪桑 說道:

    嗨! 同人你好, 很高興認識你! 看到你給我的意見與批評, 我欣然接受! 畢竟, 我還沒坐過高鐵, 更不是他們開發組織裡的什麼人, 我真的只是個看熱鬧的外行人.

    看了你的作品, 我的感想在這裡: Stakeholder Management

    BTW. 你的兩本參考文獻我都有! 真是太巧了

  2. [...]其實我還蠻高興喲哪桑對於我在〈內行人看門道,外行人看熱鬧〉的意見有正面的回應,距離神通高 鐵開發團隊,我可能比喲哪桑近了一些,雖然我也沒坐過高鐵,也不屬於高鐵專案成員,但是網路上的言論卻讓我發現,很多人都在不了解狀況下來做評論,這是很 危險的。當然,如果立場互換,我的反應可能也會一樣。然而,我觀察到這一點,為文除了自我警愓外,也想藉此做個提醒,有時候我們的觀感可能只是誤解,因為 我們沒有看到事情的全貎。

    總之,藉由這次事次能認識一個學養豐富又心胸廣闊的朋友,也算是好事一件。喲哪桑說我所引用的參考文獻他也有,真巧!我猜可能是因為我愛看的書和喲哪桑很接近吧,他寫的其它文章一看就知道,呵呵~也是溫伯格書籍的讀者。[...]

  3. [...] 哈米尼斯針對了在 Java world 上 kenchu 的留言做了回應,這篇留言提到了專案經理的工作重點並不在人的管理,而是資源的調度,為了資源的調度他必須將所有的資源都量化,而專案團隊成員亦視做是一種資源。而在同一篇主題的其他回應中,他更強調專案經理不等於 team leader。哈米尼斯的回應則認為這樣觀點的前提在於 PM 的管理能力要夠格。不過,我想這個前提很難成立,因為擅長管理的人都知道要不涉入團隊而企求有效地管理專案,要實現這個天方夜譚,簡直是在痴人說夢,專案管理並沒有辦法紙上談兵呀。 [...]

  4. [...] 其實經驗是最不可靠的東西,很多技術人員看高鐵,很容易犯了沒問題症候群(NPS)的毛病[1],卻忘了內行人看門道,外行人看熱鬧。我在〈資訊系統設計的盲目〉中就曾提過,高鐵售票系統,並未採用資料庫技術,所以用資料庫角度來看高鐵售票系統,不會比瞎子摸象好到那裡去。 [...]

  5. [...] 當然,軟體開發的甘苦,不足為外人道矣,但成長不是我有話要說,而看得懂別人在說什麼。所以,內行人看門道,外行人看熱鬧,要思考成長或是推論指責,全憑我們自己的選擇,沒有對錯,卻只有認知上的差異而已。 [...]

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

  7. [...] 筆者發現,確實有些人會用「成熟」與否來對流程模式進行價值比較。例如,當年神通在高鐵售票系統出現紕漏時,在網路上筆者曾看到有人認為CMMI要達到ML4才算品質達到改善的水準,而ML3也只是了解流程的情況而已,因此算不上是品質有達到改善。筆者認為這樣的說法是有問題的。 [...]

  8. [...] 要認識系統開發的複雜性,這並不是一件很容易的事。不過,忽略它會讓我們和湊熱鬧的外行人一樣,從他人系統失敗的經驗中只能看得到表相;以為這只是犯了離譜的技術或方法論的錯誤。我們應該學習像內行人一樣,從系統失敗的教訓中看到成功的門道,了解到系統開發複雜性本質的真相;不天真地以為技術或方法論可以解決系統失敗,而是深入省思系統開發的複雜性。基於筆者過去對系統失常的觀察及體會,想以這篇文章從公共建設的系統失常看系統開發的複雜性。 [...]

  9. [...] 要認識系統開發的複雜性,這並不是一件很容易的事。不過,忽略它會讓我們和湊熱鬧的外行人一樣,從他人系統失敗的經驗中只能看得到表相;以為這只是犯了離譜的技術或方法論的錯誤。我們應該學習像內行人一樣,從系統失敗的教訓中看到成功的門道,了解到系統開發複雜性本質的真相;不天真地以為技術或方法論可以解決系統失敗,而是深入省思系統開發的複雜性。基於筆者過去對系統失常的觀察及體會,想以這篇文章從公共建設的系統失常看系統開發的複雜性。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">