同人覺得喲哪桑的觀點讓人最疑惑的地方是有關「好產品」的定義，如何在開發產品之前具體而客觀地定義出什麼樣的產品是好產品，讓人能按照這樣的標準把產品開發出來。依據同人在系統開發的經驗來看，「好產品」的觀念總是只存在決定什麼好產品的「那個人」之主觀印象當中，它通常是來基於他的價值判斷而產生的，但其他人不見得都會認同他對好產品的主觀價值認定。

當然，如果市場上大部分人都能認同「那個人」對產品價值的認定，那麼做出他認定所謂的好產品就能夠賺到錢。但如果市場上認同「那個人」對好產品概念的人並不多，即使產品做得多好也不能讓產品開發者賺到錢。

換句話說，開發者開發出產品的好壞並不能決定產品是否能絕對獲利，更關鍵的決定因素在於市場。就算開發者有能力開發出盡善盡美的好產品，但那並不代表市場就一定會肯定它的價值，因此「好產品不一定能賺到錢」並不是一項迷思。其實它告訴我們一項真理：人想要靠開發出好產品而賺到錢，除了需要有能力把產品做出來之外，還需要其它因素的配合；把各種可能的因素加在一起，我們通常會通稱它叫機運。

對於一些勇於實踐冒險精神的創業家而言，他們的成功是因為承擔風險而獲得的報酬，然而，不要忘記可能不乏有人和他們做了相同的事而失敗的例子，只是這些多半是「沉默的證據」而讓人不得而知。

喲哪桑說，在 Phil 的演講中有提到幾個好產品的特性。他引用在他的文章中提到：

更明確點說，做個好產品，好到人們會長期地一直留下來​用，好到它對人們的價值愈用愈高，而且，還能壓低公司的​變動成本。

對於學長上面明確提到好產品的特性，同人不是不能認同。而是認為時空背景因素常會影響人們對產品使用的偏好；人們沒有長期使用某項產品，不代表它還不夠好，而是人們會感受到該項產品好用的時機還沒有到。很多時候，新穎或前衛的創新產品沒有受到人們的青睞，只是因為人們感知不到它的有用性，有時候不是因為產品易用性欠佳的原因，而是因為外在環境還沒有足夠的變因來刺激使用者的使用需求，這正是著名的科技接受模式所教導我們的觀念。

假設你打算花費了三個月的時間來做出一個好產品，你已經用專業的市場行銷眼光看到三個月之後將會大受歡迎的產品。於是你在工程方面投入了大量的功夫和心力，想辦法把產品做到盡善盡美。但假如你真的做出了無懈可擊的完美產品，是不是就會讓客戶認為這是有價值的好產品？答案恐怕是未必見得，因為你原先對市場的預測可能出現失誤、或是其間發生難以事先料想到時空背景的改變，使你的產品終究沒有得到客戶的認同。

喲哪桑說他們會每隔 1 天、3 天、1 個月、甚至是 1 年來檢查保留的比率，藉此來確認做出客戶覺得有價值的好產品。同人同意這種作法的確有助於增加產品在市場的成功，只是產品在市場上成功是因為產品做得好，這並不是客觀的事實，而是主觀的價值判斷。

其實產品的好壞很難客觀界定的，縱使你把產品做得好到大部分的人都愛用，也很難不讓其他的人覺得你的產品不好用或是不夠完美，尤其是在不同的時空因素下，同一個人對相同的產品常會有截然不同的評價。開發產品很難能夠做到滿足每一個人的需求，在現實因素的考量必須捨棄比較少人需要的功能時，難道是代表那些功能不好所以才會被捨棄嗎？

真相是捨棄不是因為它不好，而是因為多數的人現在不需要它，而且人很難預知將來會不會用到它。世界上從來不缺少比目前市場成功產品做得更完美的產品，但它們很多沒辦法成功地在市場上存活，並不是因為它們不是好產品，而是人們現在不太需要它們。同樣的道理，目前在市場上走紅的產品也不是因為它們是好產品，而是剛好符合市場上的條件；有一天這樣的條件會消失，而它們也將會被其它的產品所取代，就像它們曾經取代過的商品一樣。

最後喲哪桑學長說：要做出好產品，讓它更好。別畫唬爛、別搞政治，別搞關係，別打嘴炮。同人很認同這句話，但卻也不由得想到過去的一段經驗。當時同人在一家開發資料庫資訊安全​的公司負責軟體設計及開發，那家公司的總經理常說他不想讓公司成為詐騙集團。他認為台灣軟體業的問題是不重視把事情做好的紀律，只靠業務和行銷吹噓而沒有把產品做好。

只是同人發現在他主觀價值判斷上的執著，無形之中產生了組織的官僚特性和文化偏見，其實他不是沒有在參觀者的面前做樣子，只是沒有意識他並沒有做到言行一致，結果讓產品一直「收尾巴」收不完。這個經驗讓同人學習到了做好產品關鍵不在我們怎樣要求完美，而在於如何真的做到言行一致。

對於工作的兩種觀念

內切圓和外接圓的比喻是由過去的一位長官 JL 先生所提出來的。他是在台灣出生，在義務教育結束後前往美國完成學業、工作並且創業有成，直到這幾年才在回到台灣在軟體產品領域發展。由於他深受西方文化的薰陶，在台灣特別感受到很多人做事的態度和美國人很不一樣。

如果我們的工作可以區劃成一塊一塊的正方形方格，看做是工作必須要完成的目標。那麼我們用來完成工作目標的活動，就可以看成是與這些方格重疊的圓形，可能是在正方形裡面的內切圓、或是在正方形外面的外接圓。JL 指出依他的觀察，他覺得東方人做事像內切圓，而西方人做事則像外接圓。他認為內切圓和外接圓是來自不同文化而產生工作觀的差異。

JL 表示在台灣，人們工作似乎比較習慣按照制度或是規章來做事，也就是需要按照組織所規範的框架來做事。反觀在國外他長年和美國人工作的經驗顯示，美國人做事通常不受制式框架的約束，因此比較能夠進行思考的自由與創新，用一些方法來突破框架的限制。

當然依照框架來做事，也不見得是壞事，它可以讓人們暸解要付出多少心力來解決問題。但 JL 指出就好像內切圓並不能完全涵蓋外切的四邊形一樣；按照框架來思考問題，實際的問題和想法之間，很容易因為落差而出現缺漏。反過來說，如果想法可以超越框架的限制，想法的完整性就可以比實際問題更多一點。就像外接圓一樣，代表想法的圓形可以完全涵蓋代表問題的四邊形在其中。

JL 強調內切圓或是外接圓的工作觀，沒有絕對的對錯，這只是受到文化的影響而有不同的選擇。他表示熟悉西方文化的他，一開始很不習慣人們和他有不一樣的工作觀，但慢慢地他發現經過一些磨合，逐漸了解該如何與統合習慣不同文化的人，並且找到方法能夠讓事情進展更加順利。

觀念不同源自文化差異？

JL 認為東方人和西方人在工作觀念的不同，是源自於文化的差異。或許這是因為他對開發軟體產品有熱忱，想回到他出生的國家，以他從美國人那邊學習到的做事方法，希望為台灣的軟體產業貢獻一些心力，但是在跟台灣工程師共事之後，卻覺得他們並不像美國人可以打破常規，能夠突破傳統做事的方法而進行創新。但以同人的觀察來說，我認為文化影響工作觀念的看法，是基於他對工程師工作觀念的期望所致，這是一種主觀的刻板印象而並非客觀事實。

同人認為內切圓和外接圓工作觀念的不同，不是源自於文化差異，而是來自於組織角色對工作的期待不同所致，我是根據「尋求簡單之道」（search for a simple way）專案的研究結果做出這樣的論述。同人在〈簡單，複雜世界的致勝之道〉曾經提過這個研究，這本書是《越簡單越有力量》這本書作者投入該專案的研究心得，其中提到工作的複雜面向最主要的原因是變革欠缺整合。

高層主管與員工對整合觀點的懸殊態度，對於整合，領導者關心的焦點是管理、控制與協調的工具；而員工關切的重點是有利個人決策的工具，執行工作者的觀點常會受到不平等的對待。

對每個工作執行者來說，沒有人會不希望把工作做到盡善盡美。因此要在工作上突破傳統、超越框架，他們知道在工作上完成外接圓是最有效率的工作方式，而且也可以展現個人的專業能力。然而，實際上在執行工作的時候，他們卻常常會發現缺乏資訊、資源、工具等支援來進行如何工作的決策。

換句話說，員工執行工作的困難，通常在技術專業上都不成問題，而是在工作過程發生複雜的問題，而複雜最大的成因是領導者和員工對工作的觀念歧異，而員工的觀點總是被不平等的對待。很多高層經理希望工程師能夠發展外接圓，以涵蓋問題的面向，但受到時間急迫、資源或資訊不足的因素，必須要在工作上的各個面向有所取捨時，當然畫出外接圓是不可能的任務，而是以比較符合現實因素的內切圓來取而代之。

以上這種工作觀點的對立現象，並不是只有台灣而已，而是舉世皆然。這從「尋求簡單之道」（search for a simple way）專案的研究對象是美國企業，就可以得到證實；在美國工作，工作觀念對立的現象是普遍存在，顯見不是因為美國文化讓人傾向用外接圓的觀念來工作，而是因為角色的差異而選擇不同的工作觀念。

美國工程師能力強？

如果工作觀念的差異，並不是源自文化因素，那麼為什麼 JL 看不到美國工程師用內切圓的觀念做事？從同人從和 JL 共事的經驗來看，我不覺得他在軟體開發使用的流程，有什麼特別的不同，那這樣是不是意味著美國工程師能力強呢？同人相信 JL 的記性沒有錯誤，但我想並不是美國工程師能力比台灣工程師強，而是認為 JL 忽略了工作複雜性的分別。

雖然 JL 過去和最近這幾年都是開發網路安全的產品，但以前開發 L2、L3、L4 的防火牆，和最近幾年開發的產品，是在 L7 的網路安全應用領域，產品的複雜性和技術的成熟度當然差距非常大，因此在相較之下，如果是在產品複雜性低、技術成熟度高的領域開發產品，要用外接圓的觀念來做事當然是不會有太大的問題。

相反地，如果在產品複雜度高、技術成熟度低的領域開發產品，就不可避免地會碰到很多不確定因素，在這種情況下，想要以外接圓的觀念開發產品，期望做到一次到位談何容易？而且這樣做也很容易昧於現實而招致失敗的命運。所以，內切圓的觀念會比較適合在複雜性高的產品開發工作，必須集中資源去處理最關鍵或是最需要迫切解決的問題，而沒辦法期待在第一時間就兼顧所有的問題。

因此，同人認為選擇內切圓或外接圓的觀念來做事，與文化並沒有直接的關係，而是與問題的複雜性與技術的風險有關。談到文化，同人想到溫伯格在《溫伯格的軟體管理學（第一卷）－系統化思考》所提到的：

當寫到有關文化方面的東西時，往往會參雜一種批判的情緒。比方說，有些人會覺得「任何一種軟體文化都有成功的時候」是一種令人難以接受的說法。他們就像歐威爾的政治寓言小說《動物農莊》裡的那些豬，樂於接受「所有動物生而平等……但是，某些動物更該得到平等的對待」這類的觀念。有些人會同意「任何文化都有成功的可能……但是，某些種類的文化較其它的文化更有可能成功」。

諸如此類的想法大有八九都是藏在心中秘而不宣的。例如克勞斯比在他的「品質管理成熟度座標格」中描述了描述了品質管理五種不同的階段。這樣的座標格是一種極為有用的工具，不過，若簡化為「品質管理座標格」將會是更貼切的名稱。「成熟度」這個字眼所傳達的並非一個事實，而是一種價值判斷－基於事實所做的一種詮釋，最起碼，它並不符合事實。

溫伯格說：「追求不必要的完美不是成熟，而是幼稚」^[1]在他的書中提出了六種軟體模式，強調使用某一種軟體模式並沒有比其它軟體模式更「成熟」的問題，只端看問題的複雜度和客戶的需要。同樣的道理，如果外接圓和內切圓的工作觀念，我們可以看做是不同的工作模式，兩者應該也沒有那一種模式比較成熟的問題，不然很容易讓人陷入批判情緒當中。

兩種文化思維

同人不知道 JL 說工作觀的不同源自文化差異的說法，其中是不是帶有文化批判的情緒。我也看不出來，所謂統合東西文化，可以讓事情進展得更順利的方法，到底指的是什麼。但從同人對西方的管理學、科學、以及東方哲學觀點的認識來看，JL 的一番說法，倒是讓同人看到兩種文化思維各有所長。也就是西方文化強調理念與力量、東方文化則是重視經驗與關係。

同人曾經聽過 JL 和一位同事的對話，他告訴同事 Entropy 的觀念，提到：「任何穩定的系統，在沒有外力干預的情形下，都會從有秩序的狀態下慢慢走向衰敗，所以人必須要更有力量才能讓系統維持穩定」JL 或許並沒有說錯，人需要更有力量來控制系統，讓它維持穩定的狀態。但到底人要如何才能得到更大的力量呢？同人不方便對長官提出這個問題，因為這個對話我是旁觀者而不便插話。但依我平常對 JL 的觀察，我大概知道他口中所指的力量到底是什麼。

同人相信長官口裡所指的力量是指「理性」的能力，也就是針對事物所呈現的事實，進行邏輯思辨和推論，然後在決定目標及擬定策略之後，再運用技術能力來完成目標的方法論。這種方法論強調西方文化所重視的科技能力，而且確實可以發揮更高的效率在處理一般性問題上面，而使人擁有更大的力量。

不過，也許是科技的理念讓人擁有更大的力量，而容易使人疑惑，忽略世界並不是完全「理性」的，很多問題沒有辦法用「理性」來解決的。尤其是在當人們對工作上的意見分歧，影響心理層面的負面情緒時，這時候談「理性」的人其實他的行為是不理性。在行為不理性的情況下，「理性」其實並不能產生力量。

溫伯格說：「力量是一種關係」^[2]人所擁有的各種能力，包括知識、技術、專業、或是權力，它們的力量取決於它們所作用的對象上。如果人沒有清楚地認識自己，不清楚自己擁有能力要用來做什麼，就很容易把能力運用在不正確的對象上，這樣並不能產生力量，而會讓自己產生困惑。溫伯格說：「力量這概念經常使人困惑，因為我們通常不以相互關係的觀念來考量他」^[3]。

從溫伯格對力量的觀點，讓我們看到力量是一種合一的關係，而這正是東方文化思維重視關係的關鍵所在；關係存在才有力量可言，真理不是絕對的，以人如滄海之一粟的渺小，惟有以體驗來擴展經驗，對世界的認識才會更加全面。其實東西方文化各有所長，人用「理性」來創造科技文明，然而，心物的分離是過度強調理性必然得的代價，人必須回過頭來以心物合一的「經驗」來認識非理性的世界，才能重新再得到力量。

《易經乾卦象傳》曰：「天行，健，君子自強不息」代表理性的發展，人要效法天的精神，每天都要追求進步，才能讓自己不斷成長而擁有力量。不過，《乾卦》用九的原則是「天德不可為首」，要「見群龍無首」才能夠持盈保泰。所以《乾卦》上九曰：「亢龍有悔」告訴我們人在知進退而不失正道的情況下，才能得到真正的力量。

《易經坤卦象傳》曰：「地勢，坤，君子以厚德載物」代表經驗的成就，能夠包容萬物、順應所謂「積善之家，必有餘慶；積不善之家，必有餘殃」的趨勢的人，才會真正地成就事物。《坤卦》六二曰：「直、方、大，不習無不利」說明事物的永續發展，是模式不斷複製倍增的原理，它不用經過學習就能讓人運用自如，但不良的模式一旦成形，矯正它就要浪費更大的心力。

因此《坤卦文言》曰：「直其敬，方其內，君子直以敬外，義以方內。敬義立，則德不孤」這正代表了優秀領導者對人表現謙虛態度，而對內堅持專業的原則^[4]。否則，一個有能力而不懂得謙虛的人，很容易因為驕傲而忽略自知之明，讓他老是在眾人面前表現出愚蠢的樣子。

1. 曾昭屏譯（2006），《溫伯格的軟體管理學（第一卷）－系統化思考》，p.59-60，經濟新潮社。
2. 李田樹、褚耐安譯（2006），《領導的技術》，p.218，經濟新潮社。
3. 李田樹、褚耐安譯（2006），《領導的技術》，p.222，經濟新潮社。
4. 《從 A 到 A+》提到第五級領導者正是對人表現謙虛精神，對事堅持專業。

由於這兩項特性，在團隊中是彼此對立但卻又是相輔相成的，因而容易造成管理團隊合作的困難。團隊可以發揮成員能力多樣性的優勢，產生團隊綜效而創造更高的整體效益，但另一方面，團隊的多樣性太高，將會對一致性造成衝擊，使管理者面臨到管理的困難。

團隊多樣性有助於團隊績效，但多樣性很容易使成員之間因為意見分歧，進而產生情緒反應與相互的干擾行為而發生衝突。衝突通常對團隊績效是有損害的，這在團隊發展是需要注意的問題，因此團隊領導者通常需要想辦法增加團隊的一致性，以降低成員之間一旦發生衝突的麻煩。

同人之前在文章〈技術經理的教練角色〉，就曾經提到技術經理不應該為了增加一致性而犧牲多樣性。在那篇文章同人對通達人提出的觀點，表達我的看法。他認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。

同人當時以「必要多樣性法則」來說明如果技術經理的管理彈性不足，他就只能對團隊成員處處設限，以減少團隊的多樣性來降低管理的困難。但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。因為團隊可以視做一個動態系統，這個系統的行為將會由系統最有彈性的部分來掌控。換句話說，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他控制整個系統的困難度。

從「必要多樣性法則」可以理解，如果希望利用團隊創造出更高的效益，多樣性是不可或缺的，否則團隊合作所產生的效益必然會欠缺創造力。這樣的觀念就像自然界生物與社會發展的演進一樣，存在差異性才能促成個體致力於創新與改變，進而促成整體性的發展與成長。

有趣的是，前一陣子同人在《我不要當負翁！教你如何經濟思維》這本書中也看到以經濟學的交易及合作的觀念來解釋團隊多樣性的必要性，也覺得非常有意思。

《我不要當負翁！教你如何經濟思維》提到運用「絕對優勢」和「比較優勢」都可以創造合作的效益。「絕對優勢」可以降低生產的會計成本，而「比較優勢」則是可以降低生產的機會成本。所謂的「絕對優勢」是指一個人在某一項工作技能的生產力強過他人，而「比較優勢」則是指一個人在某一項工作技能的生產力強過自己的其它生產力。

讓人們從事各自具有比較優勢的工作，然後再互相交易，可以提高彼此的福利。……只要存在比較優勢，進行分工合作對於擴大生產就是有利可圖的。^[1]

書中還舉了是否外包生產的決策、和不必事必躬親的例子來詮釋「比較優勢」的觀念。縱使在某一項技能具備「絕對優勢」，但為了降低機會成本來進行更有效益的工作，應該運用「比較優勢」來增進團隊合作效益。

依照以上的觀念來看，依照團隊成員所具有的優勢，來進行分工，然後再將其工作產出加以整合，就能夠擴大團隊合作的效益。當然，在團隊之中，絕對優勢是最容易被看到而加以利用，但考量機會成本的損失，團隊合作應該重視比較優勢更勝於絕對優勢。

就拿技術經理擔任教練角色的例子來說好了。一般來說，技術經理對技術的熟悉程度較高，技術的操作對他們來說，算是比一般人都還要在行的絕對優勢。不過如果因為這樣，就讓技術經理一直從事技術操作的活動，這樣就會減少其他工程師自己動手操作技術的時間，而降低了讓他們的技能透過磨鍊而提昇的機會。另一方面，也會讓技術經理無法脫離技術操作的工作，這樣就沒辦法藉由活動領域的擴展，來得到更高層次的技術或解決問題的全局觀點。

以團隊整體合作效能的角度來看，即使技術經理自己親自動手可以很快就把事情做好，但如此卻喪失了團隊合作的意義；讓能力強的人攬了太多的事在身上，其他人卻無法分擔他的負擔，也沒辦法得到技術資深者的教導與親自演練技術的機會，工作動機與士氣也就無從激勵。所以對於團隊合作而言，這其實並非是好主意。

為什麼技術經理要攬那麼多的事情在身上，而不去把它們交給其他人來完成呢？主要的原因通常是技術經理擔心團隊成員沒有足夠的基本能力，不能把事情做好反而會讓他浪費更多的時間來處理爛攤子。除非技術經理能夠培養團隊成員的能力，讓他們也能夠操作他會的技術，這樣他才有可能抽身去做更有效益的事情。但問題通常是在團隊成員的素質參差不齊，要培養操作技術所需要的基本能力是有困難的，畢竟羅馬不是一天造成的。

不過技術經理也許不用如此多慮，如果成員沒辦法運用一致性的能力來解決問題，其實正代表可用另一種角度，以成員的多樣性來創造團隊合作的效益。有時候，解決問題不一定只限於某種我們熟悉的技術或方法，甚至也不一定要用技術才能解決問題。說不定換一種角度，可以用一些我們不是那麼熟悉或奇特的技術、方法、甚至是觀點來看待問題，然後說不定可能發現有更令人驚喜方法可以解決問題；這類的方式通常更有創造力，可以用較少的代價來達成需要達成的目標。

一個可以充分讓成員發揮比較優勢的團隊，必然是會讓團隊存在各類特長的成員而呈現多樣性，而且能夠讓成員根據他們的專長來發揮特色。對整個團隊而言，存在各種不同的特色正是讓團隊充滿了如朝陽般的生氣，讓大家朝向共同目標而發展出自己的特長。

因此管理者在進行團隊分工除了思考成員具備什麼能力能夠勝任什麼工作的同時，更應該思考成員之間特質如何相互搭配特長。因為後者能夠發揮更多的比較優勢，它讓每個人都能夠追求較大的效益，在產生團隊績效的同時也讓成員一直獲得成長，其實它正是讓個人與團隊能夠共創雙贏的優勢。

1. 董自強（2010），《我不要當負翁！教你如何經濟思維》，p.106 – 107。

當然，如果從言語的暗示當中，聽話者可以聽懂說話者所要表達的意思，有時候可以化解一些尷尬的場面，然而如果聽話者聽不懂、甚至是誤解說話者想要表達的意思，那溝通就會非常的沒有效率。不幸地是，有莫非定律的加持，後者比前者發生的機率然還要大得多，而且容易讓人覺得被操控玩弄而感到的不自在。

溝通不應該玩猜心的遊戲，要別人猜中你的心思，這是很累人的一件事，換做是自己，可能也不見得會猜中對方的心思。有時候，當我們對別人的行為感到失望時，應該用直接的方式表達我們的在意，而不是期待對方想清楚，然後做到符合自己沒有說出來的期待。

如果我們沒有說出對他行為的期待，又要求對方能夠「具體」做到我們的期待，這其實是非常矛盾的，甚至於這只能說是自找麻煩而已；有時候自己都不知道自己在想什麼，又如何要求別人可以猜測出自己的心意呢？

過去同人常常以隨和自居，命盤中命宮在天平座的我，最容易犯一個毛病，那就是通常並不會在事情剛開始，把自己對他人的期待直接清楚說出來，而是提供各種的可能性，要別人猜測我心中的想法。但後來我慢慢發現，以前我不把我心中的想法直接了當地說出來，怕對別人不好意思，其實這不叫替別人想，而是陷別人於不義。

因為當我不把問題說出來，別人不會知道我的介意，只會在別人違反我的原則時感到不舒服。但一開始沒說，在別人的行為在心中產生矛盾後，却更不知道該如何表達，直到最後忍耐不住發作而讓人感到莫明其妙。所以我現在都寧願把壞話說在前頭。這樣勝過別人看不懂的怒氣積壓在心中，而要比事後讓人搞不清楚為什麼要那麼大的反應還來得好。

我們對他人的行為的介意，很多時候讓我們感到失望的並不是行為本身的問題，而是行為所衍生的彼此信任與關係的問題。也就是說他人的行為讓我們發現對方是無法被信任的，因為相同的行為已經重覆好幾次，形成了一種模式，而這種模式讓我們無法信任對方，影響彼此之間的關係。因此，我們面對他人做出我們介意的行為，如果不去表達清楚真正讓我們介意的地方，就會讓對方覺得不能理解，為什麼我們要對一件小事產生那麼大的反應。

其實原因正是如同《關鍵對立》這本書所提到的，因為我們介意的是「模式」和「關係」的問題，而對方對認為我們對他的某種行為的「內容」在做文章，而我們也沒有針對需要解決的問題來進行「關鍵對立」。可想而知，這樣沒有弄清楚溝通的重點，當然會弄得溝通曖昧不明而沒有辦法進行有效的溝通。而最大的混淆，正是沒有直接說清楚自己真正的介意。溝通，真的不要玩猜心的遊戲呀！

去年的莫拉克颱風重創台灣中南部，對此政府高層質疑中央氣象局的播報「就是不準」。籠罩在批評聲浪的低氣壓之中，使得中央氣象局的士氣大受影響。接著在去年底，傳出中央氣象局預報主任吳德榮申請提前退休的消息，準備要離開他一生奉獻的氣象工作。很多人很婉惜中央氣象局留不住這位素有「氣象王子」之稱的專業人才，但在另一方面，吳德榮決定退休也為他引來不小的批評。

其實從新聞報導看吳德榮決定退休所引來的風波，可以看到專業人士在工作上很容易招致不平等的看待。這在專案開發也是常見的情境；辛苦工作的代價，專案工作者經常要承受無端的指責，而影響工作士氣。

當然短期來說，高層管理者所不願承擔的壓力加諸在專業人員身上，他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力，而不懂得適時激勵來增加專業人才的士氣，總有一天將會令專案付出慘痛的代價：損失重要的專業人才。因此，對於專案管理者而言，這是值得關切的問題。

專業的傲慢？

媒體採訪時詢問吳德榮中央氣象局為何不加強氣象宣導，以避免民眾用錯誤認知來責怪氣象局。吳德榮感慨地的回答：「人們普遍理盲又濫情，再如何宣導也沒有用！」，有一位名嘴認為吳德榮這麼說也是「理盲又濫情」。

她說前年的卡玫基颱風，氣象預報不準到離譜本來就應該批評，但去年莫拉克風災氣象局預測兩量的數字比 CNN 的報導要準確，只是不會使用「Huge! Huge!」的形容詞來表示超大豪雨。她說，把氣象預測的結果說得讓一般人都能了解，也是非常重要的專業。她表示想幫氣象局的人員上課，雖然把專業讓一般人能夠了解是很困難的，她不願意苛責氣象局，但如果能做到那不是更好嗎？因此認為吳德榮沒辦法宣導卻決定退休是「理盲又濫情」的行為。

監察院認為中央氣象局雨量預報沒有發揮預警功能，遭到監察委員提案糾正通過。監委指出，有專業卻無作為一樣是嚴重疏失，氣象局應檢討如何把「專業知識」轉為「庶民知識」，並有效傳達。監院反諷氣象局，如果預報準確的話，劉兆玄敢去理髮？薛香川敢去吃稀飯嗎？ 監委余騰芳更說重話，對氣象局預報中心主任吳德榮因為遭約談而退休，毫不客氣的兩度重批說這是「專業的傲慢」。

筆者認為對為台灣氣象專業有重大貢獻的人來說，「理盲又濫情」再加上「專業的傲慢」的批評，實在是相當沉重的指控。或許站在非專業人士的立場，專業知識的通俗化與有效宣導真的很重要，但因此把問題歸因到專業沒有善盡把專業講清楚的責任，甚至當專業人士的人生規劃與人們的期待相衝突時，用一些負面的詞語來加以貶抑，這表現了對專業不尊重的態度。我認為這顯示批評者的「不專業的偏見」。

以專案管理的觀點來看，筆者很擔心這種「不專業的偏見」會導致專業人士不願貢獻他們的能力與熱情，慢慢地將造成使團隊專業能力下降的捨本逐末模式。如果人們傾向於把問題一切過錯都推給做事的人，所謂嘴上的「專業」，逐漸演變成為機構的文化與風氣，自然會使得願意在專業領域專精與學習的人愈來愈少。

因為當機構中彌漫著一種碰到問題責怪做事的人的風氣的時候，只會讓人們以後不再願意做事了。反正不做不錯，事情做好又沒有人會獎勵你，如果管理者對工作者的態度是「有功無賞，打破要賠」，那麼只要能夠不攬事在身上就不要多事，否則就要當心付出心血卻被批評有專業沒作為。

如同筆者常見當專案出現問題時，那些只出一張嘴的人責怪辛苦工作的人，往往是團隊專業能力開始敗壞的前兆。此時專案中最有價值的教訓與經驗，就通常不會有人去關心。慢慢地想藉此磨鍊能力的人愈來愈少，因為工作態度積極的人都不會有好下場，領導者的手下只剩下可以聽命行事的奴才，而沒有在專業領域中精益求精的人才。

那麼身為管理者，該如何在身處壓力下解決這樣的困境呢？解決之道是想辦法增加工作者對工作的熱情，要能夠做到這一點，筆者認為管理者應該激勵工作者來增加他們對工作的熱情。

現實世界並不理想

當然，激勵工作者並非一件容易的事。尤其專業工作者是知識工作者，要適時地激勵他們，以發揮專業工作者的工作熱情，更是身為管理者的一大挑戰。專業人士「不求名、不求利，只求爽」，因此對他們而言，提昇權位、或是增加待遇不見得可以激勵士氣，而是必須讓他們在工作上感到無比的成就感，才會對他們產生激勵作用。但為什麼這對管理者難以做到呢？依筆者的觀察，我認為管理者的難題是，沒辦法在激勵行動前必須弄清楚兩個重要觀念。

第一個觀念是現實世界並不理想，我們並未處在理想世界中。因此不該用理想世界的觀點來簡化專業，而要因應現實世界來調整我們的假設；專業不見得能夠預測以防範未然，因為我們的世界會受到少數難以預料極端事件所影響，而不是運用歷史與統計就可以推測變化的。

就如同一般人都了解天氣不可能完全準確預測的道理一樣，雖然氣侯的變化是隨著前一刻的氣候狀態而改變，其間存在著變化的必然性，但實際上它屬於「混沌現象」而無法預測。也就是長時間受到微小的擾動而偏離原來的發展，就像「蝴蝶效應」的說法：南美洲一隻蝴蝶扇一扇翅膀，就會在佛羅里達引起一場颶風。

預測的原理是掌握機率與統計數字，用來幫助人們做決策。然而，真實世界與由機率與統計數字所化約世界之間的落差，不應該由專業工作者預測不準來承擔責任。事實上，這個責任沒有人承擔得起，而是我們對真實世界的了解仍然有限。我們可能知道颱風大約會帶來多大的兩量，但卻難以知道這些雨量會集中在什麼地方而釀成重大災害。而依據海德堡的「測不準原理」，當我們愈能測得準颱風的風速或兩量，那颱風的位置或是影響時間就愈不可能準確。

或許人們可以憑感覺把某種數字賦予災害的形容詞，但這豈是講求實據的專業工作者所應該表現的專業作為？至於要把「專業知識」轉為「庶民知識」的論點，則更是後見之明。問題是沒有人會知道災害會發生在那裡，人們該如何往那裡逃？例如小林滅村的原因之一就是規劃的避難所恰好是被活埋的區域。

村民要如何撤離，政府是有一套計劃，小林村也演練過。當天也有村民事先警覺，配合村長的勸導進行撤離。問題是，撤離的計劃估算錯誤，而雨量也遠遠超出原先預期的 500 mm，所以土石走山的區域，根本就把原先認為安全的村民安置點小林國小和和小林行政中心也掩埋了。

－from BillPan’s blog，小林滅村的原因：我的觀點

狐狸與刺蝟

管理者要激勵專業工作者，第二個必須弄清楚的觀念是狐狸與刺蝟的差別。「狐狸」與「刺猬」的比喻，是源自柏林（Isaiah Berlin，1909-1997）一篇著名文章〈狐狸與刺猬〉。柏林依據古希臘詩人亞基羅古斯（Archilochus）的話：「狐狸知道很多事，但是刺蝟只知道一件事。」把人分為狐狸與刺蝟兩種。狐狸型的人，總是同時追求很多目標，把世界看得很複雜；而刺蝟型的人總是把複雜的世界簡化成簡單的系統化概念。

《從 A 到 A+》的作者柯林斯（Jim Collins）認為，能推動優秀公司邁向卓越的領導人或多或少都屬於刺蝟型。他們運用刺蝟的天性為公司發展出刺蝟原則。對照公司的領導人則比較像狐狸，從來沒有辦法掌握刺蝟原則的優勢，反而總是一心多用，前後矛盾。

另一方面，塔雷伯在《黑天鵝效應》提倡相對的觀點，他指出許多失敗的預測來自刺蝟，他們對不太可能發生的事下大注；專注於單一重要而不太可能發生的事件，讓人們被單一的出象結果所蒙敝，無法想像其他的可能性。塔雷伯建議任何人都不要成為一隻刺蝟，而是當一個心胸開放的狐狸；歷史會被單一稀有事件所影響，但沒有人會知道那是什麼事件。

刺蝟與狐狸各有所長，刺蝟強調深入了解事物的本質，狐狸則探討神奇世界的複雜細節。這兩者並沒有優劣高下的問題，而是看待問題須以適合的角色來處理它。因此身為管理者，如果你想勸誡專業工作者去做他們不擅長的工作，強調那是他們也必須學會的專業時，那麼筆者會建議你應該好好想一想；刺蝟之所以是剌蝟，就是他並不是狐狸。

讓專精專業的刺蝟嘗試多做點狐狸的工作，或許你會成功，但小心這樣做要付出更大的代價；可能刺蝟最後才會發現他做不好狐狸的工作，這個過程會因為刺蝟沒辦法做自己而顯得不快樂，甚至最後連怎麼成為刺蝟都忘記了。事情變成這樣的局面，不是因為工作者的能力有問題，而是管理者缺乏識人之明，把人才放到錯誤的位置所造成的問題呀。

經過一個月來的使用，這台 FE3000 用起來還蠻順手，直到最近因為無法透過 USB 連接線輸出照片，才發現 USB 的連接埠故障。老婆到總代理元佑實業要求維修，才發現 OLYMPUS 這個世界名牌數位相機的維修服務，竟是如此糟糕而令人失望。

同人聽到老婆告訴我客服要求我們付錢才能維修，這實在令人感到不可思議。老婆轉述客服的話說，連接埠的故障是因為人為操作錯誤造成，因為連接埠上的接頭凹陷下去，他們認為正常操作絕不會出現這樣的狀況。

老婆當然不能接受客服的說法，但客服說完卻忙著處理另一位客戶的大發雷霆；因為他送修的機器沒修好而吵著要找元佑的總經理處理問題。這時候，輪到另一位女性的客服人員來處理老婆的問題，她還是說這是人為操作不當，如果是按照正常的操作，USB 拔插 10 次都不會有問題。

老婆聽到客服人員這樣說，立即反應說：「這是什麼爛照像機，USB 只能使用 10 次，我以前用過其它廠牌的機型都沒有這樣的問題！」客服人員這時表示請老婆不要生氣，但她還是堅持修理 USB 連結埠故障必須要收費，要不然就只能買讀卡機來處理相片的輸出。老婆因為帶著還不到三歲的女兒，沒辦法也不想花太大的精神找對方理論，只好悻悻然地帶著相機回家。

聽到老婆送修數位相機的過程，實在讓同人覺得這個名牌數位相機維修服務真是離譜。在台灣的今天，竟然還有如此缺乏品質意識的公司，真是令人匪夷所思。

OLYMPUS 的 FE3000 並不是我們家所使用的第一台數位相機，過去我們用過很多其它廠牌的數位相機，而且也經常利用數位相機所附的 USB 界面來進行照片的影像輸出，從來也沒發生過 USB 連結埠那麼不堪使用的問題。

如果真如客服說是因為人為操作不當而造成損壞，那麼什麼樣的操作會造成這種問題呢？老婆轉述客服說可能是接頭方向對錯了，我聽到客服人員這樣說倒是想請對方表演如何將 USB 接頭反接給我看！事實上，這台相機的 USB 插槽有防止反接的缺口設計，根本就不可能發生將 USB 傳輸線反接的現象。

如果使用者不可能將 USB 傳輸線接反，再加上我們並非第一次使用 USB 的傳輸界面，對我們而言，連結 USB 傳輸線是那麼單純而簡單的步驟，我們應該不可能會弄錯而導致 USB 連結埠的損壞。如此看來，USB 連結埠的損壞的原因根本就並非人為操作不當，而是機器本身的設計不良或是構件本身的瑕疵。

所謂設計不良是指使用者在正常操作下會造成機件故障的比率。換言之，就像客服人員說得 USB 傳輸線正常拔插 10 次也不會故障。假如她說的沒錯，那麼就代表這台數位相機的 USB 傳輸線拔插的設計，只能保證正常使用拔插 10 次不會導致連結埠的損壞。因此站在使用者的觀點來看，這種設計當然是設計不良。

然而以常理來推論，實在很難讓人相信 OLYMPUS 的 USB 連結埠會設計成只能拔插 10 次而已。這樣看來，如果 USB 連結埠損害的原因不是因為設計不良，那麼就是 USB 連結埠構件本身的瑕疵，才會如此不堪使用。而那位客服人員如此缺乏 common sense 的說辭，不是想掩飾產品品質不良的真相，就是想要推拖維修的責任而刁難顧客。

這種罔顧客戶權益的行為，是客服人員的素質太差，還是因為元佑本身的企業文化所致？有網友告訴同人，在網路上元佑的相機維修，早就劣跡斑斑了。聽過老婆跟元佑接觸的經驗，再看看到網路上的文章、以及一些網友的經驗，讓人相信除了客服人員的問題之外，更嚴重的問題是他們的企業文化根本不重視「服務品質」這回事；對於客戶的維修需求，能夠推掉一件就賺一件，如果推不掉就再來修。換句話說，就是會吵的孩子才有糖吃。

一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣。而是要怪自己沒有看清楚服務條款，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。

因此，相機的保固問題自然有法律來保障我們的權益，但除此之外，我們仍舊可以將不愉快的相機維修經驗，用來降低其他消費者因為資訊不對稱而增加的交易成本，以自然淘汰不良的服務品質。希望透過這篇文章的分享，也能夠讓更多人了解，數位相機除了品牌形象與功能外，不要忽略了售後的維修服務呀。

網路上其它有關元佑維修的討論：

數位相機不防水

戰勝元佑的例子

前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。

雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。

設計不夠好？

戴爾是世界知名的電腦直銷公司，擁有 13 年的網路直銷經驗。對於這種有豐富網路直銷經驗的公司來說，系統連續發生產品標價錯誤的問題，實在是一件令人感到不可思議的事情。在戴爾發生第二次標價錯誤事件之後，筆者聽到有一位工程師出身的朋友指出，戴爾筆記型電腦的標價錯誤，是因為他們的系統設計不良。他依據新聞的報導，對比自己的網站開發經驗，認為可以確定這絕對是設計的問題。研判是促銷資料沒有正確關連產品資料，才會發生這種錯誤。

從戴爾回應外界連續標價錯誤事件的說法，第一次錯誤定位為人為作業疏失，第二次錯誤是因為系統異常。這麼看來朋友的說法似乎有些道理，但從系統開發流程的角度來看，卻讓筆者產生一個疑問。如果是因為設計有問題，應該是可以在系統正式運行前被測試出來，但為什麼要直到錯誤釀成災禍才被使用者發現？朋友表示要做到完整測試系統是很困難的，還不如把系統設計做好，這樣系統自然不會出錯。

在觀念上，我同意朋友的說法，因為好的設計的確可以減少系統發生錯誤的機會。但問題是朋友的想法在實務上卻有操作上的困難。因為設計夠好是很難被清楚定義，尤其是在專案時程及資源有限的情況下，想要設計出可以在各種情況下適用的系統是非常困難的。面對系統運作環境與需求變化無常的情況下，設計通常只是一種權衡與取捨之道；沒有可以解決所有問題的最佳設計，只有針對解決重要問題的最適當設計。

如果我們不能定義出具體明確的系統問題，所謂的較好的設計也只不過對未來可能變化的假設所做的設計，但實際上未來的變化可能會出乎我們的意料之外。當我們對系統的假設不再成立時，就會產生系統可能發生異常的風險。因此，戴爾出現系統異常的原因，問題的關鍵可能並不在設計的好壞，而是沒有掌握好問題的複雜度；今天系統碰上比過去更複雜的問題，是當初設計系統之時所沒有想到的情境。

造成錯誤的原因

從筆者過去系統開發的經驗顯示，過去長期運作正常的系統，經常會因為運作環境發生變化，而使系統在現今發生功能失常。我想戴爾的情況應該也是類似的狀況，否則如果是設計有問題，就很難解釋為什麼過去運作正常的系統，會在今天出問題。如同商業周刊的評論「戴爾烏龍 在於沒換腦袋」所提到的：

戴爾系統無法偵錯的關鍵——戴爾仍以經營企業顧客的思維在做消費者生意，否則怎會沒把消費者異常下單行為納入管理流程？

戴爾成立以來都是以企業市場為重，占營收比重超過八成。直到二○○七年才進入消費市場，這是很大的突破，因為經營企業市場，客戶數量少，強調服務與產品穩定度，但經營消費市場，客戶數倍增，就必須靈活彈性。

但此次事件讓我們看到，即使經歷兩年，戴爾網路系統的「腦袋」還沒轉過來，管理階層也是一般。

從戴爾大中華區中小企業處許肇元的說法，我們也可以了解戴爾系統異常的問題。網路上有一篇 jeremy 寫的專訪中提到許肇元對短短 10 多天連續出了兩次錯誤的解釋：

「因為我們成長的速度太快，而系統並沒有配合我們的成長。像是我們的訂購流程，每個零組件都可以客製化，訂一台筆電的流程換算下來就幾十個關卡，每個關卡都跟價錢有關，牽一髮而動全身。這次事件中，我們真的學到很多，也重新檢視了我們的系統。」

這更讓人相信，問題的關鍵並非單純的系統單一功能失常，而是戴爾忽略了商業模式改變會對系統產生影響，而沒有做好事先預防與事後可以及時因應的準備。

由此可知，造成戴爾系統發生錯誤看起來並非出在各部分功能的問題，而是系統整體整合出現問題而造成系統異常。那麼台北捷運內湖線的系統異常是不是也是相同的問題？從相關新聞報導我們發現，系統發生錯誤的原因也是因為系統沒有整合好，內湖線無法順利整合木柵線舊有系統。這大概從決策當局決定採用規格無法統一的中運量的系統，以及冒險採用無線通訊新技術時就已經註定了這樣的結果。再加上測試時間不足，自然會使品質問題更加雪上加霜而惡化。

造成系統失敗的條件

如果戴爾電腦和台北捷運內湖線的系統異常，種種跡象都顯示是整合出現問題，那麼我們不禁要問：為什麼它們的整合都會出現問題呢？從筆者系統開發的經驗來看，我相信是因為系統整合牽涉的問題太多或是太複雜，使得開發者難以掌握。再加上人們在尚未意識到系統的複雜度之前，常會認為自己有能力解決所有的問題，但實際上他們想要這樣做卻做不到。一言以敝之，系統失敗的根源其實是來自於人性的弱點，雖然這個真相往往被硬體、作業系統或平台的功能失常所掩蔽。

如同著名的軟體工程顧問溫伯格在《第一級評量》提到，造成軟體系統失敗的條件有八個 F，它是分別是弱點（Frailty）、愚蠢（Folly）、執迷不悟（Fatuousness）、好玩（Fun）、欺騙（Fraud）、狂熱（Fanaticism）、硬體功能失常（Failure）與運氣（Fate）。筆者發現這些造成失敗的條件，其實正是表現人性弱點的不同面向。

弱點

弱點是做想做的事卻做不到，它是軟體失敗的終極源頭。因為人不是完美的，他們做不到設計所要求的，不論那是一個程式設計，或是一個過程設計。溫伯格認為管理階層的責任是設計出一個程序以規範程式如何修改，承認自然界的事實，與確保程序本身被執行。而且他認為人們傾向在發生錯誤後懲罰嫌疑犯其實很不好，因為他會讓人隱藏錯誤、浪費時間在找嫌疑犯、以及分散注意力忽略管理階層的責任；建立並執行能及早找出失敗，並預防悲慘後果的程序。

愚蠢

愚蠢是做到想要做的事，但它卻是錯的事。愚蠢的基礎是無知，雖然它在當下沒有發生錯誤，卻會在以後造成錯誤。不過透過學習可以改善無知，進而將愚蠢矯正過來。溫伯格認為建立完整訓練師徒制、技術審查計劃、提供落實計劃的支援，是管理階層可以用來矯正愚蠢的職責。

執迷不悟

執迷不悟是指不肯學習，一直做出蠢事，一次又一次的做。此外，想要管理好一個愚蠢的人，卻不提供他根除愚蠢所需的訓練和經驗，這也算是一種執迷不悟的行為。溫伯格認為在軟體工程機構中，除了把執迷不悟的人送到其它行業去，否則沒有什麼防護措施可以抵擋執迷不悟的人。

好玩

好玩是程式設計師會寫一些奇怪的程式來為自己找樂子，溫伯格認為沒有人能夠預測別人認為好玩的事是什麼，因此好玩的心理是所有失敗的源頭中最危險的一個，因為它防不勝防。但管理者應該提供預防之道：一是開放透明的系統，另一個則是讓單單工作本身具有足夠的趣味。

欺騙

欺騙是用非法的方式從一個系統中獲取個人利益。溫伯格認為好玩是在失敗的源頭中，帶來的最小的損失。因為一個系統找樂子的方法有千百種，但值得一偷的東西卻沒多少。他認為軟體工程經理要好好閱讀以資訊系統詐騙為主題的文章，並採取一切可能的預防措施來防堵它。

狂熱

狂熱是試圖摧毀或瓦解一個系統，而原因不是為了個人利益，而是為了報復。溫伯格認為防範弱點而採取的行動中，多數也可以減少恐怖份子所造成的威脅與影響。

硬體功能失常

溫伯格提到硬體若不能造著當初設計的目的而執行工作，就會造成功能失常的現象，這類問題多半可以用軟體來克服。他認為當人們抱怨硬體造成他所寫的軟體出問題時，我們應該找出它表達的意思，以免遺漏這句話所帶來的重要資訊：

1. 硬體沒什麼大不了的功能失常，但程式設計師需要找藉口來隱瞞一些事實。
2. 硬體功能失常問題都在一般的預期範圍內，可能程式設計師沒有採取正確的防護措施。例如將程式碼或測試腳本做備份。
3. 硬體功能失常，但沒做好硬體供應商關係的管理工作。
4. 硬體功能失常是由人為錯誤所造成的，如使用者做出出乎意料的動作。

運氣

溫伯格指出運氣不好是多數表現不佳的經理愛用藉口，這不是事實。他建議當我們聽到一個經理老愛說運氣不好時，我們應該把運氣兩字換成經理，因為沒有不好的士兵，只有不好的軍官。

系統異常與人性弱點

從以上造成系統失敗的條件我們可以知道，系統發生異常的原因可能是系統的設計不夠好、硬體設備或作業系統出錯或是系統運作的環境太複雜了，但發生問題的真相卻都大部份是因為人性的弱點。因此，要在失敗前發現錯誤，進而採取行動防止系統失敗，重點管理好人性弱點，而非不承認它的存在，卻只在事後責備人們沒有盡到責任，但事實上最大的責任是管理階層沒有盡到管理的責任。

例如在台北捷運內湖線在 7/10 發生系統大當機的事件後，當外界質疑為什麼發生這麼嚴重的當機事件時，筆者注意到有一篇新聞報導提到市府官員有人表示「這個問題，80 % 是因為電腦中毒」言下之意系統異常多半是因為硬體的功能失常所致，而比較不可能是軟體的瑕疵或人為的錯誤。

溫伯格說過「對錯誤的直接觀察，本身並無意義，但是對『人們作何準備來面對錯誤的發生』的統合觀察就很有意義」那位市府官員的說辭，筆者相信只是為了隱瞞了一些事實，以免公布實情而讓損失更加擴大，然而這卻表現反應他們對面對系統錯誤發生的準備並不夠充分。

筆者再舉一位朋友的經驗為例，以前他們公司採用 .Net 開發平台開發新產品。由於他偏好 Java 的程式寫作慣例，加上當時微軟聲稱與 C# 整合不成問題，讓他很想用 J# 程式語言來開發系統。雖然他的同事擔心系統的整合會出現變數而反對，但由於他的堅持，管理階層還是照他的意思，讓他用 J# 開發他的程式，與其他同事以 C# 的程式來進行整合。

後來在整合時，他們發現碰到很多平台上及程式語言本身的問題。為了解決這些問題，他只好修改他的程式以處理這些問題，但也讓系統愈變愈複雜，結果使軟體問題層出不窮。但朋友仍然還是堅持要用他喜歡的方式開發系統，最後在管理階層無法忍受他的執迷不悟，並且在彼此無法達成共識的情況下，要求他離開了那家公司。

從這位朋友的故事中，我們看到他的弱點、愚蠢以及他和管理階層的執迷不悟。他的弱點是想實現他的設計理念並完成不同語言的整合，但後來卻發現這是個艱鉅的任務。在發現了專案時程及市場上的壓力並不允許他實現他的設計理想時，卻一再地堅持做自己想做的事而非應該做的事，這是愚蠢。而與管理階層之間一次又一次想要對方同意自己的觀點，卻又不去理性客觀地評估現實，而只是一廂情願地以為讓對方發現此路不通就會懸崖勒馬，這是他與管理階層的執迷不悟。

朋友的經歷並不是特例，在實際的系統開發專案中，筆者總是看到相同的故事正在持續上演。就像戴爾電腦、台北捷運內湖線發生系統異常的事件一樣，應該發揮效果的程序、流程與方法，在關鍵時刻竟然沒有發揮作用。筆者認為問題的關鍵是在於人性的弱點，我想只有在適當地管理好人性弱點之後，程序、流程與方法才能真正地落實，並且發揮出應有的效果吧。

管理的重要性

如果導致系統異常的關鍵是在於人性的弱點。那麼管理階層就應該負起管理人性弱點的責任，以避免專案因為人性弱點而造成系統異常的意外事件而慘遭失敗。從去年跨年夜發生的台灣大哥大行動電話用戶大當機的事件，又再一次地讓我們看到管理對避免系統異常而造成失敗的重要性。

去年跨年夜，台灣大哥大發生行動電話用戶大當機，經檢調查出是台灣諾基亞西門子公司離職工程師，涉嫌以女友名義登入台灣大資料庫並刪除資料造成大當機，檢方昨天將陳依妨害電腦使用罪嫌起訴。

筆者看到新聞提到那位工程師，否認是遭開除而挾怨報復，只說會這麼做是因為「好玩」。讓我想到溫伯格說的，好玩的心理是所有失敗源頭最危險的一個，因為沒有人可以預測到別人認為好玩的事是什麼。

當然，我想事件的真相應該不是因為那位工程師基於好玩的心理，而是被公司開除而心生報復。造成台灣大哥大系統當機的原因，固然是難以預料到的惡意破壞，但這並不代表這種系統失敗是無法防止的。筆者認為問題在管理上，因為管理階層忽視人性弱點，而沒有盡到管理者應盡的責任。

或許有人會認為筆者這樣說對管理者要求太多了，但如果系統開發團隊沒有紀律來把事情做好，這的確是管理者的問題。管理者設計或制定流程，目的是為了幫工程師把事做好，但如果流程不能落實，那是必然代表管理出現了問題，所以管理者必然難辭其咎。

好比說，為什麼離職員工可以用他離職前的帳號密碼來登入系統，然後做出一些危害系統的行為？又或者，為什麼會讓人興起想要破壞系統的動機，而身為負責系統成敗的高階管理者，為什麼會不去防範可能破壞系統的行為？

因此，即使可能是因為好玩，管理者也要思考如何降低人們為了找樂子而影響系統的動機。如前面所提到過的，讓員工的工作更有趣，同時讓流程更透明。此外，避免員工試圖摧毀或瓦解一個系統，不是為個人利益而是為了報復。管理者應加強防範弱點而採取的行動，因為它們多數也可以減少這種攻擊。

以上這些都是管理者的職責，以避免系統因為人為的疏忽而失敗。總而言之，預防系統失敗，管理最重要的工作就是認清「人的不完美」，才能知道如何管理人性，進而避免發生人為錯誤而造成意外，產生系統的重大損失。

同人看到這則新聞的第一個反應是，總統在救災過程中受到批評，心裡面會產生一些情緒是人之常情。因此透過 email 中將這些情緒發洩出來，跟家人訴訴苦以免情緒積壓而損害身心健康，我認為是很自然的一件事。只不過，馬大姐把這些用來宣洩情緒的對話，在公開場合中公開，似乎只會為她的弟弟帶來麻煩，顯然她又失言了！

不過，除了馬以南的失言之外，同人認為這則新聞更重要的意義是，讓我們看到領導者應該如何面對批評。在現實上，領導者所碰到的難處是，不管領導者碰到問題怎麼做，他都很難做到沒有人批評。因此想要成為優秀的領導者，其實無須太在意外界的批評，而是應該將這些批評轉化成更積極正向的領導作為。

就像在《領導的黃金法則》中，作者約翰‧麥斯威爾提到「當你後面被踢一腳，你知道你已超越在前」。身為領導者，我們應該要有面對批評的準備。那麼領導者應該如何面對批評呢？麥斯威爾認為下面四個步驟可以幫助領導者處理批評：

第一，認識你自己，這是真相問題；

第二，改變你自己，這是責任感問題；

第三，接納你自己，這是成熟度問題；

第四，忘掉你自己，這是安全感問題。

麥斯威爾認為領導者無須理會對領導者職位的批評，但對個人缺點的批評，卻必須要設法改正。要認清人們是基於領導者的職位，或是領導者個人本身，唯一的方法就是認識自己。其次，改進自己的缺點是領導者的職責，但也必須能夠分辨善意批評或是惡意批評，可以問自己下列三個問題：

誰在批評？智者的忠言逆耳勝過愚者的熱情贊助。批評的人是誰很重要！

如何批評？試著分辨對方武斷還是提出疑問、好言相勸。

為何批評？是出自傷害我的動機或是為了我好？會傷害他人的人不會手軟，他們猛烈抨擊他人是想讓自己好過，而非幫助對方。

對於領導者的言行，在一開始人們通常會說你錯了，但後來卻又會說你是對的，而且重點不是你做什麼，而是他們知道你做的事情很重要。面對旁人這種多變的反應，麥斯威爾說領導者應該學會接納自己，並且指出為了做我們理想中最好的人和領導者，我們需要做好我們自己。

可是那並不代表我們不用改變或成長，而是表示必須努力做到最好的自己。真實做自己是邁向更好的自己的第一步，而接納自我是成熟的象徵。如果我們擔心別人怎麼看我們，那是因為我們對他們的意見比對自己更有信心。

有效處理批評的最後一步就是不再把焦點放在自己身上，麥斯威爾認為領導者不需要花太多時間擔心別人怎麼看自己，其實別人並沒有那麼在意我們。

麥斯威爾說有安全感的人忘記自己，所以他們可以把焦點放在別人身上，以面對任何批評，甚至為批評他們的人來服務。他說一個有安全感的領導者永遠不需要為自己辯護。做為領導者應當看重責任，但卻不應該把自己看得太重。

從麥斯威爾的觀點來看總統府對這次風波的回應，同人覺得有信心的領導者實在不應該花時間來為自己辯駁。如果埋怨「好人（心）沒好報」只是為了一時情緒的宣洩，就算不小心被馬大姐把在家裡面說的話公開出來，但只要承認自己的情緒及壓力確實存在，並表示自己會想辦法好好處理它們，讓自己能夠把事情做好。這樣就足以代表領導者在行為上是接納自己與放下自己，也就表現出足夠的成熟度與安全感。

可惜馬總統似乎是太在意旁人對他的觀感，因而太維護自己「被曲解」的形象。其實同人過去在〈新官上任三把火〉及〈當專案一再出現相同錯誤時〉這兩篇文章中，就曾經探討過馬團隊在管理或領導上的問題，從這些文章中似乎可以歸納出來馬總統領導的問題在「完美」兩字上。

或許在理念上，馬總統認為按照他的理想去做，就能夠讓事情達到完美的結果。但事實上，理想上的完美是不存在的，真正的完美是要你認識自己，並接納自己是不完美的，然後你才能改變自己而成就真實的完美。

因此，對外界的批評，如果馬總統一直把焦點放在自己身上，他就很難理解別人為什麼看不到他的辛苦與努力，也就無法體恤別人受到的痛苦。在缺乏安全感及成熟度的反應背後，我們看到根本的原因是領導者不能認識自己並加以改變。例如在報導中看到：

杜勇明則指出，他說「馬總統您來晚了！」這句話是針對馬政府團隊救災一團亂有感而發，總統原本就該承擔政府所有責任，但把這件事拉到個人問題是不對的。

會發生這樣的誤解，顯然馬總統不夠認識自己，才會分不清批評是針對個人或是職務而來。不過，同人這篇文章並不是期望改變，只是藉由對他人領導行為現象的觀察，帶來有助於自我成長的學習。因為生命的學習與成長是無止境的，所以即使在位的領導者未能改變，但或許只是時間還沒到。多點耐心給別人，也希望能讓我們從別人的錯誤中學習成長。

相關文章：

• 領導者的黃金法則~處理批評-領導者需要學習的功課

延伸閱讀：（其它有關領導的文章）

• 領導是信任關係
• 結構性無作為
• 當專案一再出現相同錯誤時
• 新官上任三把火

到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。

在松山機場站，捷運公司的人告訴我們，免費接駁車可以坐到動物園站，但內湖線的接駁公車沒有進入機場的站牌，所以必須坐接駁車到中山國中站，再轉搭內湖線的免費接駁公車。大家等了好一會兒，終於坐接駁車到中山國中站，但內湖線的公車怎麼一直都等不到呢？看到對面往動物園方向的車子一班接一班，而在內湖線接駁公車等待的地方，就只能看到公車一班接一班開走，卻絲亳不見接駁公車的身影。

等了半小時，讓同人的耐心已經將要消耗殆盡了，於是問了在站牌捷運公司的服務小姐。我問：「為什麼對面的接駁車都已經開走三班了，為什麼到內湖線的公車卻一班都還沒來呢？」服務小姐表示因為對面的接駁車是從松山機場發車會比較快，往內湖線的接駁車已由麟光站在 8:30 分發車，開過來要花一點時間，請我們耐心等待。

旁邊有一位小姐聽到服務小姐的說法，覺得很不合理。她說：明明捷運發生系統異常是在晚上 8:00 左右，為什麼直到 8:30 才發車？服務小姐辯稱是因為與公車業者協調需要時間。不過這樣的說法讓在場等接駁車的乘客不能接受。在這段期間，同人又看到往動物園的接駁車又過去一輛了，而且乘坐的人非常少。大家開始質疑，為什麼不從對面的接駁車調度一些過來支援內湖線的接駁車呢？

後來，好不容易看見我們這邊有接駁車開過來，但卻不是往內湖的車子，而是開到松山機場站。可是，看到班班幾乎空車就令人生氣；排隊的人龍那麼長，接駁車卻是開往沒有人要去的地方；讓同人不得不說，捷運公司實在是沒有規劃好接駁車正確的需求。

往內湖線的接駁車終於來了，但坐上車的人只有一位，因為它「客滿」了。這讓在場的乘客愈來愈生氣，服務小姐只能用手中的無線電詢問公車調度的情況，但似乎情況難以掌握而對事情沒有幫助。讓同人最後不想浪費時間，放棄坐免費接駁車回家的計劃，選擇自己花錢坐計程車回家。

對於台北捷運內湖線的系統異常，同人一直都是抱持著同情的態度。我自己也經歷幾次的系統失常的事故，不過看到捷運公司人員，為了處理或解決系統狀況而奔忙，加上自己系統開發的經驗，讓我比較能接受新系統出現不穩定的情況。

然而，看到這次離譜的調度，讓我很懷疑真正的問題是捷運公司面對問題的態度。在處理問題前沒有把腦袋放在正確的位置，不能針對客戶的需要來思考問題，而只是浪費資源在不重要的事情上。顯然捷運公司對解決問題的訓練是不足的，問題不是服務人員盡了力沒有，而是他們在盡力之前，到底有沒有把問題想清楚呀！

這篇文章分享他對寫好使用案例對專案好處的看法，他總結使用案例的好處是族繁不及備載。並提到越大規模的專案，更能感受到開發節奏的順暢度。再加上 "漸進循環 (incremental and iteration)" 的開發模式，會越形容易謀和在系統開發期間，人與事的種種。

不過，Kenming Wang 在文章最後提到以上的論述不能說服那位程式開發人員，因為程式設計人員多半以局部或個別的角度來看系統開發，所以使用案例寫得好不好，對他們沒差。只有像專案經理或軟體架構師以專案整個全局來看時，才會有明顯的感受。

但他認為不需要去說服那位程式開發人員，並引述 Martin Fowler 在《UML Distilled》一書中曾經說過的：「你只能強迫新手們這麼做。過了幾年後，他們會突然恍然大悟，然後腦袋彷彿重生！」這句話來說明他對這位程式開發人員意見的看法。

同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。

因為這些主觀價值如果不能以客觀的方式來表達甚至衡量，這些只會造成實際執行開發工作的人的困擾，不知道所謂的「好」或「對」的作法，到底與他們的工作有什麼直接關係，如此只會使他們工作變得更複雜。如果未來真能讓他們恍然大悟而腦袋重生倒也還好，但如果最後發現期望落空，是否只是浪費開發工作者寶貴的時間和精力呢？

尤其同人很懷疑 Martin Fowler 會說「你只能強迫新手們這麼做」的話。當然，同人對「腦袋重生」有印象，但記得不是出現在使用案例的章節，而是出現在循序圖的章節中，提到集中式或分散式物件設計的不同思維。果然，同人回家翻閱譯者光正兄送我的《UML精華第三版》發現，在循序圖的章節有下面這一段文字。

這種設計風格的改變正是物件導向設計典範革命的核心所在。不過，這也是難教導之處。真正了解物件導向典範唯一方式似乎就是在強烈使用分散設計風格的OO環境工作一陣子。許多人會突然恍然大悟，開始理解到這種設計風格究竟為何。這時候，他們的腦袋將重獲新生，也開始比較容易思考分散控制的設計風格。（趙光正譯，2004，《UML 精華第三版》，「Chapter 4 循序圖」，p4-6）

同人知道 Kenming Wang 是很聰明的顧問，懂得舉一反三引用大師的觀點來強化自己的論點。但用在此處看來有斷章取義之嫌，而且非常危險，我認為這很容易淪為方法論的主觀價值批判。因為不管怎麼說，如果光正兄的翻譯沒有錯誤的話，文句的原意並沒有貶抑不同開發觀點的意味。

同人以為問題的關鍵並不在某種開發典範有何好處，所以應該強迫他們採用、適應、進而熟練方法進而讓專案獲益。而是在於強迫導入任何方法論都會存在風險，我們是否能夠充分理解這些風險對專案產生的影響，以及所付出的代價是否值得。或許你還會有印象，同人在〈簡單，複雜世界的致勝之道〉分享過複雜面向的最主要來源是變革欠缺整合。

高層主管與員工對整合觀點的懸殊態度，對於整合，領導者關心的焦點是管理、控制與協調的工具；而員工關切的重點是有利個人決策的工具，執行工作者的觀點常會受到不平等的對待。

從這裡我們可以很輕易地了解，為什麼很多使用案例方法的導入常使軟體開發人員的工作變得更複雜。可能你會說那是因為誤用使用案例，或是沒有寫好使用案例，但其實依據同人的觀察，造成誤用或使用案例的不良寫作多半是因為不同觀點的差異，進而導致彼此的溝通不良所致。

站在全局觀點的人總是認為沒問題，但實際上他們並不能提供局部或個別觀點足夠的資訊，以利其進行開發上的決策。而往往為了符合全局觀點的架構上的框架，往往要逼著程式開發人員削足以適履。

請不要誤會，同人並非否定寫好使用案例的好處。事實上，從我過去的工作經驗，我很能體會寫好使用案例的好處，只不過我從來不認為好的使用案例可以解決不同觀點的整合問題；其實沒有任何的文件可以做到這點，除非允許各種聲音充分表達，然後進行相互對話以提昇溝通品質。

為什麼沒有任何文件可以解決不同觀點的整合問題呢？因為不管文件所傳達的觀念多麼「好」或是「正確」，而沒有與其他的觀點進行互動與溝通，進而分享意義，很容易讓各種不同的觀點各說各話，而無法促成彼此的思考與反省，進而激發出可以解決問題的智慧。所謂的「好」或是「正確」只是基於已知最佳實務的記憶，而不是為了解決複雜問題的思考，因此不見得可以有效地因應問題反而使問題更加複雜化。

不同觀點的整合，這絕不是「強迫新手這麼做」就可以成功的。你會需要實際執行工作者的回饋，了解他們的問題與期望，才能幫他們更簡單的完成工作，才不會因為忽略程式開發人員觀點的思慮不周，使工作變得更複雜而浪費他們的時間與心力。