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

最近高鐵售票系統的問題，在網路上引來許多的的熱烈討論。其中喲哪桑在〈從高鐵售票看 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）。

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

參考文獻：