內行人看門道,外行人看熱鬧

最近高鐵售票系統的問題,在網路上引來許多的的熱烈討論。其中喲哪桑〈從高鐵售票看 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.
Please follow and like us:
分類: 利害關係人, 品質文化, 問題解決, 專案管理, 生活感觸。這篇內容的永久連結

在〈內行人看門道,外行人看熱鬧〉中有 9 則留言

  1. 自動引用通知: 同人的生活派對 » 有關「Stakeholder Management」的後續討論

  2. 自動引用通知: 同人的生活派對 » 專案經理不是 team leader?

  3. 自動引用通知: 同人的生活派對 » 「漫談高鐵訂票系統的結構分析—觀念篇」之我見

  4. 自動引用通知: 同人的生活派對 » 軟體開發見聞錄首部曲

  5. 自動引用通知: 同人的生活派對 » 從高鐵售票系統談大型公共建設軟體開發專案

  6. 自動引用通知: 同人的生活派對 » 新官上任三把火

  7. 自動引用通知: 從公共建設的系統失常看系統開發的複雜性 « 同人的生活派對

  8. 自動引用通知: 從公共建設的系統失常看系統開發的複雜性 « 同人的生活派對

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *