新官上任三把火

本篇文章是投稿 ZDNet 的文章原稿，並以〈新官上任三把火〉與〈新官上任三把火(下): 建立團隊的創新文化〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。

新政府能否為台灣開創新局還有待觀察。但從馬蕭辦公室與府院籌辦五二○就職典禮，卻出現許多的問題，加上當天的慶典南北奔波，被稱為有史來最複雜的就職典禮看來；新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。

許多主導專案改變的領導者總是新官上任三把火，認為專案應該要進行改變以展現出自己的決心與魄力，因此要求團隊改變開發流程。然而，專案時間與資源的限制多半很難讓團隊有足夠的時間來調適或熟悉改變後的開發流程，結果總是令專案團隊倍感艱辛。

改革的困難正是考驗著領導者的領導能力，他更需要懂得如何讓團隊發揮創意與執行力來實現改革的目標。領導者應該如何領導團隊來進行成功的改革呢？筆者認為從領導者的價值觀、流程方法的改變、以及團隊的創新文化這三方面來看，我們可以從中體會到專案成功改變的箇中三昧，以助於掌握改革重點，有效地組織資源來幫助團隊實現改革目標。

領導者的價值觀

多數的開發者都希望能夠盡其所能地追求完美，然而，受限於許多因素，他們必須有所取捨。例如，專案時程及資源的限制總是讓他們不可能採用最佳的開發流程來發展解決方案，往往只能針對解決特定問題來選用最適當的開發流程。

因此，主導改變的領導者必須要了解沒有最完美的開發流程，而只有適用於解決某些問題的開發流程。這是領導者必須建立的價值觀，才能確保專案在正確的方向進行改革。

然而，許多領導者希望專案改變開發流程，並不是基於專案的實際需要，而是基於個人在情感上的需要，希望團隊能用更成熟的方式來開發系統。知名的軟體顧問溫伯格卻提醒我們，追求不必要的完美並不是成熟，而是幼稚。他在《溫伯格的軟體管理學：系統化思考（第1卷）》中表示：

正如我們所親眼看到的，文化的模式無所謂較成熟或不成熟，而只有合適或不合適。當然啦，有些人對於追求完美有其情感上的需要，而他們會將此情感上的需要加諸在他們所做的每一件事上。他們會做這樣的比較，完全與機構所面臨的問題無關，而只與他們自己的問題有關。

溫伯格提到在軟體工程界有許多所謂的改革者，其改革工作的第一步是要求他們要改革的「對象」先承認自己從前是低劣的，結果這些改革者皆未能遂行其願。他認為如果我們的目標是為了改變一個機構，一開始就不應該用有比較優劣意味的用語，例如「成熟」這類偏頗的字眼。曾昭屏譯（2006），《溫伯格的軟體管理學：系統化思考（第1卷）》，經濟新潮社。

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

其實任何流程模式所產出的品質應該都是相同的，它們都必須能夠解決組織與專案的問題、以及符合客戶的要求。因此，如果主導改革者的心態不是基於解決的問題或客戶的要求，而是基於自己情感的訴求，所謂的改革也只不過為了遂行其願的私心，卻讓專案與團隊成為無辜的陪葬品。這都是因為領導者沒有建立起正確的價值觀。

流程方法的改變

在軟體產業中，或許是受到用工程來隱喻開發過程的影響，許多人都希望能夠發展出放諸四海皆準的開發方法，以增進開發的效率及降低溝通成本。如果可以用標準化的方式來主導開發流程的變革，進而讓團隊落實良好的開發制度，似乎就意味著可以增進開發的效率並確保品質，但事實上真的是如此嗎？

《Peopleware：腦力密集產業的人才管理之道》提到基層的流程改善乃是知識工作者的基本作為，但是，正式的流程改善卻是把責任從個人向上轉移至組織。個人還有可能會勤訓苦練，並且提昇良好的技能，但組織就只會把東西制度化，而危機就在制度化當中。

制度化會讓組織不願意去冒險，也不會尋求真正的挑戰。而且當工作流程獲得了實質改善，工作就會愈艱難。因為把比較瑣碎的工作交由機器去做，或把不重要的事情從專案中剔除之後，剩下的沒有被替除的工作將會變得更知識密集，需要更多技術與經驗。也就需要更有天份，更有經驗的人來做事。

另外，經過改善的方法，讓人們可以從事更艱難的挑戰。如果我們不敢面對這些挑戰，我們就會採取穩紮穩打的行為以規避風險，但如此一來，這些專案也只能帶來低利潤。方亞瀾、錢一一譯（2007），《Peopleware： 腦力密集產業的人才管理之道》，經濟新潮社。

由此可知，流程方法的改變其實並不意味著可以提昇專案的績效。如果團隊的能力不足，再有效率的流程方法也只能讓團隊只能勝任簡單而低利潤的專案。而依照筆者的觀察，愈依賴組織開發制度的團隊，其創新能力愈難以發揮。因為團隊成員的想法多半會受到制式的標準或規範所限制，難以對解決問題產生新的創見。因此，要讓團隊的創意得以發揮，應該重視成員對問題的見解，而不是用組織的制度來僵化他們的思考。

團隊的創新文化

不管開發方法多麼創新，達成專案目標的最後關鍵終究還是在於執行層面，否則最後必然發生如「誰來幫貓掛鈴鐺」的困窘局面。筆者的一個朋友曾經分享過他對共通性開發方法的看法：

方法論都是要讓問題簡化以適用大部分的情況；可是就如同郭台銘說過的一句話：「魔鬼就藏在細節中」。

因此，與其相信存在終極流程可以保證解決所有問題，還不如發揮團隊的效能，讓成員們可以在細節中展現他們的專業與創意。如同《專案管理之美學》這本書所提到的，不要把焦點擺在流程及方法上，專案經理應該把焦點放在團隊上，規劃和追踪系統必須符合專案的複雜度，以及團隊的文化。

這本書提醒我們，每個團隊和專案都不同，對過去的判斷有所質疑，通常都有很好的理由。因此如果只是因為有本書或某位執行長說要做某事，或者上個月或去年採用了某項技術，並不表示今天也適用。陳建勳、劉漢山譯（2006），《專案管理之美學》，歐萊禮。

筆者常看到許多具有優秀人才的團隊，常常無法發揮整體效能，其主要的原因多半是團隊缺乏創新的文化。尤其位於組織高階的管理者或自視甚高的顧問經常以為他們所主導的流程有必然成功的原因，無法容忍別人有不一樣的意見，於是破壞了團隊的創新文化與創意思考。

其實，軟體開發是知識與腦力密集的行業，有效地溝通比流程與規範的遵循還來得重要。換句話說，如果我們沒有因應專案的複雜度與團隊文化來調適與熟悉開發方法，堅持按照開發方法照章行事很容易讓我們對專案問題產生迷惘。這正是新官上任三把火最大的問題呀。

Please follow and like us: