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

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

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

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

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

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

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

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

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

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

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

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

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

溫伯格說官僚是每件事都在掌控中，但是一切全都失控了。他提到：

當專案規模變得相當龐大，通常就會因為專案成員對整體狀況缺乏掌控，不了解本身工作與整個專案的相關性，而導致官僚作風出現。

在這種情況下，大家一定會在不知不覺中做出危害品質的事，甚至會阻礙到專案的完成。這就是官僚－人們不明究裏地在做事。

要評量軟體開發組織的「官僚特性」（bureaucratic nature），溫伯格認為可以藉由有多少事情在不明究裏的情況下完成。他指出在不明究裏的情況下完成事項，占完成事項的百分比就是評量官僚的一種方式。

想要減少團隊的官僚特性，管理者應該要讓團隊成員充分了解專案計劃。溫伯格提醒管理者有計劃還是不夠，應該要讓參與專案的團隊成員了解計劃，並且透過傳達與溝通讓每一個人都了解計劃。他強調只有高層了解的秘密計劃（而且就連高層自己也不太清楚這些計劃），勢必會在大型專案中引發官僚之災。

溫伯格的觀點解釋了在軟體開發團隊常見的官僚特性。在軟體開發過程中，人們不知不覺犯下危害軟體的品質或阻礙專案的進行的錯誤，通常並不是因為計劃不夠完整，而是因為團隊成員缺乏對專案計劃的整體了解。專案成員從專案計劃知道他的任務，但卻不知道他的任務和整體專案的關係。

換句話說，團隊成員知道他應該做什麼、和如何做，可是卻不知道為什麼要這樣做，工作只是由上面丟下來交辦，他只是奉命行事而已。比如說：

• 程式開發者按照系統設計規格開發程式，可是卻不知道為什麼系統要這樣設計。
• 系統設計者按照系統分析規格設計系統，可是卻不知道為什麼系統要這樣分析。
• 系統分析者按照客戶提出的需求來分析系統，可是卻不知道為什麼系統會有這個需求。
• 管理者覺得開發者沒有把事情做對，可是卻總是不早點告訴開發者什麼叫做把事情做對。

為什麼團隊成員在他們不知道為什麼的時候，不先溝通把事情的來龍去脈弄清楚才開始執行任務呢？可能是團隊成員的能力只能知其然，而不能知其所以然；也有可能是因為團隊成員的態度並不想多花心力去了解事情的根源。同人認為不管是成員能力或態度的因素，管理者都應該要為開發團隊的官僚特性負起最大的責任。

因為軟體開發團隊的官僚特性本質上是品質文化的問題，基本上和管理者的態度及核心價值觀有關。如果程式的開發者不能了解程式和設計、需求、乃至於其所要解決的問題，就很難確定他能夠在正確的問題方向上思考，以發展在正確問題下的有效解決方案。也許他做不到的原因是因為尚未培養面對問題獨立思考的技能和習慣，但如果管理者不能在團隊中建立共享語意庫或增進共享意義暢通的管道，要求開發者要有能力知其所以然只是緣木求魚罷了。

從另一種角度來看，團隊成員在態度上不想多花心力去了解事情的根源之真相，很可能是管理者在態度上並沒有鼔勵團隊成員多多參與討論、以及提供成員表達個人意見的管道。即使管理者在言語上聲稱他們願意接受不同的建言，但實際上面對團隊成員提出不同意見的質疑，卻是表現出不能接納建言的行為。慢慢地，團隊當中自然愈來愈沒有人願意表達他們的異議，成員傾向聽命辦事來規避把事情攬在自己身上，於是讓這樣的心態更加深團隊的官僚特性。

當然，管理者因為態度而加深開發團隊的官僚特性，最後必然會「個人造業個人擔」。最後團隊有想法、有抱負的「年輕人」會愈來愈少，只知道制度和規範而忽略思考創新的「老人」愈來愈多；這裡指的年輕人和老人不是基於年齡，而是基於成員面對問題的心態。當團隊的大部份成員都已經心態老化，思考僵化是軟體品質不良的根本原因，不論管理者加深團隊的官僚特性是有意或無意，他都必須為此承擔相對的代價。

「年輕人」比「老人」對事情的「理所當然」更不以為然，因此前者可以透過思考和創意來創造更多的可能性，這正是後者限於官僚特性所看不到的世界。

同人記得聽過某個長官曾經對下屬提的意見表示：「不要只提出問題，要有 solution！」不過接下來聽到另人激賞的反駁：「如果要有 solution 才​能提問題，那誰敢提呀？」表現對官僚特性的反抗，當然反抗的結束是最後反駁者終於離開那位長官的團隊。

同人不知道那位長官心中到底有沒有意識到「如果這麼快就可以有 solution，那根本就不成問題」的真相，但我知道他的管理風格無法適應會對「理所當然」質疑的思考者，他只能「管理」聽命辦事的工作者，也許只有加深團隊的官僚特性才能減輕他對管理彈性不足所反應的焦慮吧！

我看了很多公司，每一家都宣稱絕對支持 QA 啊！

這句話讓同人心中無限感觸。感觸之一是 satomi 原來就認識同人的許多同事，包括同事丙和同事乙，而且和同事丙一樣，satomi 是非常有經驗的 QA。這當然是我在寫完那篇文章之後才知道的事情，然而現在看這篇文章，感覺像是跟很多老朋友在進行有關品質的對話。

其實還有更大的感觸之二，記得我當初在寫這篇文章的時候，我認為公司的品質文化是重視方法來提昇品質，這是公司高層對品質的承諾。因此，當 satomi 留言回應「QA 應該要可以提昇品質，但是公司從來沒有授予這個 QA 團隊做到這件事的權限」時，同人覺得公司一直給予 QA 足夠的權限而並不認為是如 satomi 說的那樣。

然而，兩年後有機會再回頭看到那篇文章之後，才看到 satomi 留言的先見之明。原來同人當初對公司的品質文化的看法並不正確，即使公司高層宣稱絕對支持 QA，但在行為上的表現卻並非如此，而是並沒有實際賦予 QA 足夠的權限來提昇產品的品質。

當然，同人相信同事丙當初不見得有「認為公司表面上表示絕對支持 QA，但骨子裡卻從來沒有授予這個 QA 團隊做到這件事的權限」。不過我很確信他今天不會認為公司高層的行為真的如其所宣稱，在行動上支持 QA。

否則，原先對公司發展遠景抱持希望和品質管理工作懷有熱情的同事丙，應該不會在同人離開公司之後，選擇在同一個時間點也離開公司。以同人在離職之前對他的觀察，我發現他在會議中相較於以前更少表示他的看法，感覺到他似乎已經不像過去對工作懷抱熱情，即使他還是努力工作為減少公司產品的 bug 而奮鬥不懈。

是什麼東西讓同事丙澆熄他的熱情？從同人後來私下和同事丙的聊天之中，可以確知是和公司高層對開發流程的態度有關。公司高層對品質的觀念和態度很有問題，有問題是指因應公司產品的複雜性和解決客戶問題方面，他們採用了不大適當的產品品質模式；以「照章行事」的方式來進行品質的管控而非「把穩方向」來做正確的事情以提昇品質。

在同人和同事丙共識的兩年中，我曾不只一次看到他和公司高層之間在開發流程的溝通中產生火花。對於高層提出新的開發流程，同事丙為了確認「我們真的要以瀑布法來開發產品嗎？」經常會造成和高層不悅的言語交鋒。在同人眼中看到這一切，我覺得使用「瀑布法」也許並沒有什麼不好，但我發現比較大的問題是高層侷限於自己的眼光，而不能用別人的觀點來看到自己觀點的問題。

同人從另外一件事更顯著地看到高層有這種侷限。有一次，在一個公司高層找同事丙、研發經理研究該如何解決客戶端問題的會議中，同事丙提出對公司高層提出的解決方案的意見。公司高層告訴同事丙，他應該先想好解決方法再提出他的意見。同事丙則不以為然地表示，如果要提意見之前都要先想好解決方案，那麼誰敢提呀！

因此，在公司高層這種態度和形成的公司文化氛圍之下，公司產品最後會變成「把做好的東西丟到牆的那一邊去」就不足為奇了。再加上以西方優越感產生文化的價值批判，在這種情況之下，QA 對產品品質的提昇有多少著力點呢？同事丙的離開做出了最好的回答。結果真的讓 satomi 說對了，公司的確是沒有賦予 QA 足夠的權限來提昇產品品質。

當然，產品品質不能提昇其實不能全怪公司高層。同人相信他絕對是有心要把產品做好，絕對也不是只有口頭上說說而已，但只是他的心智能力和行為沒辦法達成一致，非不為也，實乃不能也。從他老是把「把事情做對」掛在嘴裡，就知道他不知道「做正確的事情」可能才是品質不能提昇的最大瓶頸。去年年底，同人才發現他根本不能分辨工程的驗證（validation）流程和確認（verification）流程的差異，還問我「做正確的事情」是什麼意思，不是「把事情做正確」就行了嗎？

因此，我們真的不能怪罪公司高層只知道「照章行事」而不知「把穩方向」。你可以看到那些沒有辦法改變品質文化的高階主管，他們的無能是來自於無知，所以真的不能太苛責他們。

也許在夜闌人靜中，有心而無力改變的高階主管會反省自己白天錯誤的愚蠢行為，然而，一旦相同情境再度聚合，他們就是無法不在別人面前表現出愚蠢的樣子。這代表他們對於提昇軟體的品質這檔事，知道的很有限，可是又不想讓人知道他們知道的有限，也許需要更多失敗的境遇來磨鍊出成熟的心性，才能走出自己穴居的洞穴，而看到不一樣的世界。

對於工作的兩種觀念

內切圓和外接圓的比喻是由過去的一位長官 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。

聽到這位同事這樣說，同人笑著提醒他：「你也是 PMP 呀，而且公司還有其他 PMP 也不見得會同意這種說法呀！」沒錯，同人也是 PMP，聽到同事轉述管理階層的說法，倒是讓我覺得如果管理只要照著做，那問題可就大了。同人這篇文章寫下我對這事件的看法，不過我並不想討論管理階層所制定流程系統的優劣，而是想探討到底對專案管理而言，最重要的事情到底是什麼。

專案管理最重要的事情到底是什麼？這個問題的答案在《PMBOK》說得很清楚，沒有事情會比 team buy in 更重要了。專案經理必須要讓團隊成員對專案計劃與如何達成目標有共識，如果只是管理階層單方面的想法，而團隊成員却沒有認同與買單，專案很難會成功。所以專案管理最重要的事並不是貫徹管理階層個人的意志，而是如何讓團隊朝向共同目標的努力而前進。

管理階層並沒有實際進行專案開發的工作，為什麼他們會認為開發者應該按照他們的方法來進行開發？如果我們相信管理階層的動機是良善的，他們只是希望開發者用更「好」的方式來開發系統。然而，其實「好」這個概念是主觀而抽象的，對於管理階層的「好」或許對實際執行工作的開發者，却可能是一點都「不好」。因為管理階層並不暸解開發實際的問題所在，他們提供的方法不見得可以解決團隊對專案的問題共識，却會為開發者造成許多不必要的麻煩。

我想管理者以為用他們的方法會比較「好」的迷思，這是一種新官上任三把火的現象。認為如果他們不致力進行流程上的改變，開發團隊就好像就沒辦法把工作做得更好，不過他們通常沒有太多時間來弄清楚開發者在做什麼，只相信按照自己的做法下去做，問題就會自然解決了。這時候，我們不要忘了《溫伯格的軟體管理學》對管理者心態的提醒：

有些人對於追求完美有其情感上的需要，而他們會將此情感上的需要加諸在他們所做的每一件事上。他們會做這樣的比較，完全與機構所面臨的問題無關，而只與他們自己的問題有關。

溫伯格說：「追求不必要的完美並不是成熟，而是幼稚。」自以為在管理上做到完美，你所付出的代價很可能是讓開發者多做一些沒有效用或意義的事。因為開發者為了要滿足管理階層所認定的完美，通常必須放棄他們在專業上的堅持，以及付出不做更有效益的事情之機會成本。當然迫於情勢開發者通常不能違背管理階層的心意，但浪費時間做對達成專案目標沒有效益的事，恐怕是管理階層忽略 team buy in 的重要性，只是為了滿足管理者個人的需要而做出傻事吧。

同人可以理解管理階層希望對每一項工作，都能得到更透明的資訊，用來認清專案的狀態並加以有效的管理。然而如果不去認清開發者實際面對的問題，而是期望改變制度或流程就能夠順利掌握一切，那這樣其實只是在緣木求魚罷了。

專案管理者不去公開管理上的問題，和他的團隊面對面針對問題討論問題解決對策，只是用政策宣示或政令宣導，來規定大家只要照著做，同人認為這不是專案有效的管理，而是最差的衝突解決方法－forcing。對專案真正有用的管理，是不應該忽視 team buy in 這麼重要的事情；一旦專案管理者這樣做，他就已經在不知不覺犯了專案管理上的大忌呀。

用人要看三個特質：誠實、智慧、活力。最重要的是「誠實」，沒有誠實，這個人的另外兩項特質會毁了你。

看到這段話，一開始同人覺得很有道理。但也許是個人習慣以占星學來類化生活見聞的一切事物，同人的占星學直覺馬上告訴我，這句話不是有道理而已，還十分深富寓意；表現出股神用人哲學與占星學有著「一致百慮，殊途同歸」的現象。

在占星學中，獅子座代表誠實的特質、人馬座代表智慧的特質、牡羊座代表活力的特質。這三者都是火象星座，代表一個人行為方面的表現，也就是說從人的行為舉止，便可以知道他的做事能力是不是值得擔當重任。

獅子座是火象星座的固定星座，因此具有穩定的特質，代表標準化行為而象徵典範。人馬座是火象星座的變動星座，因此具有適應變化的特質，代表行為的改變而象徵體驗。牡羊座是火象星座的基本星座，因此具有積極行動的特質，代表行為的主動而象徵執行。

這三者以獅子座的誠實最重要，因為這是行為的準則；沒有誠實，人馬座的行為不足會產生不負責任，而一走了之的智慧、及牡羊座的行為太過則會變成暴虎馮河，死而不悔的活力。

所以巴菲特一句用人的哲學，已經點出占星學星座三方與四正的智慧。而在人事占星學的應用，以這三個星座應對的守護星，我們看到員工在工作能力的表現，也就是太陽星座的領導統禦能力（其實隱含水星星座的適應能力，與金星星座的人際協調，親愛的讀者們知道為什麼嗎？），木星星座的臨危處理事情的能力，以及火星星座的技術能力。顯見巴菲特對於人性的認識，其實是洞悉而透徹的。

回顧我們自己的經驗，相信應該不難發現：性格決定命運，但另一方面，命運也一直主宰著我們的個性。因此，性格與命運之間的關係應該不是直接的線性因果關係所能解釋的。

關於性格與命運的關係，同人想到上個月，在公司迎新聚餐就有同事提到一個有趣的故事。有人問織田信長、豐田秀吉、德川家康，如果樹上的杜鵑不叫，而你又希望他叫，這時候你會怎麼辦？

織田信長第一個回答說我會命令牠啼叫，如果牠不啼叫我就殺了牠。豐田秀吉則接著回答說杜鵑不啼叫，我就逗弄牠，等牠高興自然會啼叫。德川家康最後回答說杜鵑不叫的時候，我就坐下來，等牠想啼叫的時候，我自然可以聽到牠的啼叫聲。同事說三個不同的人物，對同樣一件事表現出不同性格，結果命運也就不同，所以說這叫做「性格決定命運」。

但同人一直覺得「性格決定命運」的說法，其實是忽略了個體自由選擇命運的意志，這正是人類與其它動物最大的差別；具有反思與自由選擇的能力。我提到在心理學分為人格心理學、行為心理學、與認知心理學，三種不同心理學派面對個體行為改變的分歧。

人格學派認為個體的行為是由先天特質所決定，後天再如何努力也很難改變性格使個體的行為改變；行為學派則認為個體的行為，乃是外界環境對於個體產生刺激所得到的反應，因此個體的行為改變，需要外界環境提供足夠的誘因；認知學派則認為個體的行為，乃是個體基於某種情境的選擇，因此改善個體的認知有助於個體採取更適當的行為。但在場同事似乎並沒有人對這個話題有興趣，只好讓這個有趣主題的談論就此打住。

不過，在同人心中並未因此結束思考「性格和命運」的問題。在我的印象中，心理學這三種學派的分歧，可以從管理學的應用看到它們的蹤跡，例如領導理論就分為特質論、行為論、以及權變論，代表這三種學派對領導的不同觀點。而且我們也能從此處發現，領導與命運的相似之處，正是兩者都是人們想好好掌握的事物，卻不見得真的能夠如願。

以「因果論」或是「決定論」的觀點來看，「性格決定命運」絕對是牢而不破而難以撼動的信念；人類的行為受到「基因」或是「性格」的影響，想要透過意志力來改變行為習慣，這幾乎是不可能的事情。但同人反對這樣的觀念，因為它是完全忽略人類意志對改變行為的影響。記得以前曾經對深林以為「華崗之狼」應該被永久隔離提出我反對的意見，但太過強調人格心理學派的觀點，忽略人類有自主反思與自由選擇的能力，並且武斷地認為犯錯的人沒有改變行為的能力，讓同人深深地覺得不以為然。

當然，無可否認地，人類和其它的動物一樣，行為必然會受到本能的影響。但我們仍不能忽略人類身為萬物之靈，我們的意志可以介入控制本能，因此可以透過意識來改變自己的行為習慣。

依據榮格心理學的觀點，本能根植於生理，而以衝動、思想、記憶、幻想和情緒進入心靈的領域。但人類有能力選擇、反思，可以順逆本能的衝動而行，因此榮格認為人類行為的本能部分，其決定性遠不如動物，然而人類在某種程度上，會受到心靈不同的生理需求與過程的影響。榮格稱本能為人類存在的「弱項」（partie inferieur)，而意識為人類存在的「強項」（partie superieur）。^[1]所以人類可以意識到改變的需求，並尋求改變的有力行為，設法盡力使自己學習改變行為，然後創造屬於自己的命運。

然而，人的意志力的介入不見得可以完全控制「基因」或「性格」的本能反應。我們經常很難控制我們自己的行為，在理智上知道不應該做或應該做的事情，但實際上我們就是無力反抗或是無法採取行動。似乎心中存在著惡魔，當它出現掌控局面時，自我只能聽命它的決定而行事，使得事件總是遵循著某種既定的模式在發生，於是更讓人根深柢固地認為是「性格決定命運」。

那麼，讓我們受到心中惡魔的驅使，到底這是誰主宰這一切呢？顯然，自我並不想做錯事，它只是無力反抗心中罪惡念頭的驅使。因此這一切或許只能歸咎於命運的造化了，不過命運造化弄人對我們其實是意義的。至少它可以讓我們在無法不犯錯或受到誘惑的情況下，依然能夠堅持決定做自己，並選擇以適當的思想、言語及行為來表現自己。

因此，一個人的性格固然會影響命運，但另一方面，他的個性也會受到命運的造化而調整。每個人都是一個完整而獨立的個體，擁有不同的氣質與秉賦。但當我們表現出這些先天特質時，可能會受到外在環境或是社會文化的衝擊，使我們內心產生創傷或是由意識所排拒的事物，並促使我們改變自我，決定自己如何與外界互動。

依照榮格心理學的觀點，自我意識會以人格面具來代表自己，而創傷及意識所排拒的事物則放在無意識中形成情結與陰影。此外，無意識還包括通往心靈深處的心靈自象（阿尼瑪／阿尼姆斯），而最深層的集體無意識則涵蓋了普遍性的模式及力量，也就是所謂的原型與本能。

自我無法意識到無意識的存在，因為它們是無意識，只能透過投射在其他人或事物上，或是超現實體驗來經驗到它們。潛意識透過各種管道將無意識浮現在意識層面上，目的是為了讓自我可以發現平常所意識所不知道的自己，並從中擴展與提昇意識的層面。

因為我們對無意識的無知，所以認為命運是造化弄人，但實際上這可能是本我體現自己的重大計劃；潛意識創造命運，然後讓「命運主宰性格」。我們可以透過命運來提昇我們意識的層次，與內心的陰影及幻象來進行對話，然後整合無意識朝向個體化的實現，用來發展本我的獨特性，並且超越宿命的限制。

這也是必須認識自己，進而有意識的以思言行來實現我是誰，也就是所謂的「知命造運」。然而，如果我們沒辦法意識到命運正在發生影響，或即將對未來產生影響。在這種情況下，我們只是無意識讓性格帶我們在載浮載沉來到命中註定的地方。

因此「性格決定命運」只是我們在無意識下的一種選擇，是一種對命運茫然的選擇，把命運歸因性格使然並非為自己生命負責的態度。就像同人在〈命運與實相〉中說過的：

如果您無法有意識地察覺並創造您的意圖，只是無意識地生活並重覆生命的某些過程，期望得到某些預期結果的話，那便很難掙脫集體意識對命理所作的迷思，然而不論有意識或無意識地生活，應該或不應該都是不存在的。您的體驗都是自身的選擇與決定，每個人會有不同的選擇，事情並沒有絕對的對與錯，但對於您的人生的進展卻造成了有效與無效的差別。

因此，生命可以積極地從人格學派走向行為學派，這時候我們可以會說「我絕對可以為自己的生命做一些改變，而不是無能為力地讓性格來限制我的未來」當一個人決定為自己生命負責，他將會知道「我是誰」， 並且表現出身為自己的行為，於是他開始表現並體驗自己決定的自己，創造出屬於自己的命運實相。

然而，命運終究是存在著很多複雜的情境，有時候我們對事物的期待，不見得是採取什麼行動就能夠令它改變的，反而對它們不抱持太多的期待反而能夠讓事情有更多轉圜的餘地。因此以認知學派的觀點來看，創造命運的重點是我們能不能對自己具備足夠的信心，不論事物如何轉變，都能夠更有彈性的適應一切的變化。

彈性意味著我們必須有足夠的多樣性來包容事物的變化。所以「命運主宰性格」正是讓我們發展出更成熟而兼容並蓄的人格特質，它不期待決定事物的最後發展，而是創造與環境的雙贏局面。

因此，在文章開頭提到的故事中，我們固然可以用「性格決定命運」來解讀三位人物的答案，但同樣地我們也看到了運用不同心理學派的命運或領導觀點。人格學派強調特質與力量的運用、行為學派強調採取行動促使事物改變、認知學派則是增加彈性來適應生命情境的改變，這同時也正是「命運主宰性格」的寫照。可見命運與性格的影響並非單方向的，而是彼此會產生複雜的作用。

由此可知，當我們從星盤中看到一種性格，它會造就出那一種命運實在是不能輕易下斷語的。因為人們永遠可以選擇他們是否有意識的面對命運，而這點是決定於個人的意志，而並非能從星盤中決定的呀。

1. 朱侃如譯（1999），《榮格心靈地圖》，p.142，立緒文化。

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

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

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

專業的傲慢？

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

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

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

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

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

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

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

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

現實世界並不理想

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

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

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

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

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

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

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

狐狸與刺蝟

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

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

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

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

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

同事好奇重構的決定是否有客觀的標準，同人表示這部分多半還是個人主觀的經驗居多。在同事後來開車載我回台北的路上，我們再次談到決定重構的時機。同事覺得重構的時機似乎不是一件容易掌握的事，同人進一步地解釋，當時我們在應用程式的開發沒有太多重構的機會最主要的原因，是因為在架構上力求簡潔而單純的設計概念，使得應用程式的開發已經變得很簡單，實在不太需要運用重構用來增加設計的彈性。

趁這個機會，同人向同事強調架構的彈性不應該以需求不得改變為前提，而是要能夠因應「有限度」的變化而發展而不斷地調整及演進。也就是好的架構並非從恒久不變的核心來出發，而是要先去識別出問題的輪廓才找得到適用的核心。同人經常在軟體開發的實務中看到，人們花費了太多的心力來堅持不變的核心，到最後才會發現原來問題是出在自己對問題假設錯誤。

那麼，在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。

設計演進的基準

軟體開發與其它的產品開發有一個很大的不同，在於軟體通常很難在一開始就定義出明確的需求規格，取而代之的是軟體的發展方向，是用來解決利害關係人在真實世界所面臨的問題。這也是使用 IPO 傳統目標導向來開發軟體經常遇到的困難，當需求的改變不可能不經常發生的時候，軟體開發在品質文化上就不應該採用「照章行事」的模式，而是應該建立具有回饋機制的開發系統來把穩軟體的開發方向。

可以「把穩方向」的軟體開發系統應該具有什麼樣的回饋機制呢？根據溫伯格在他的軟體管理學的觀點，管理者賴以把穩方向的回饋機制，必須是可以直接及穩定的觀察專案目前的狀況、並且比較專案目標與現況的差異、然後以後續如何減少差異為目標改變或調整計劃、最後再根據計劃採取行動來改善專案狀況。其中有關於直接而穩定的觀察，直接代表肉眼可直接觀察的專案結果，穩定代表不同觀察者每次觀察的結果都相同。

相信從以上的觀點，我們可以清楚看到「把穩方向」的品質文化與敏捷開發調整式規劃的關連。規劃的目的不是為了得到一個巨細彌遺的計劃讓我們照表操課，而是指引一個達到目標的概略方向，然後因應專案實際現狀來調整計劃，來使我們不致迷航。基於這樣的觀念，運用 TDD（測試驅動開發）剛好可以提供對專案進行直接及穩定的觀察。

TDD 改變我們對解決問題的假設，不假設用什麼方法來解決問題，而是假設問題情境來思考各種可能的方法，並發展出最經濟的解決方案。假設方法如何解決問題並不是不好，只是這樣很容易讓開發者把他所熟悉的方法當成黃金錘，但最後所開發出來的軟體卻不見得符合使用者實際的需要，而且通常要花費很長的時間才會發現以上的落差，因此不會有足夠時間和資源來符合使用者的需求。

如果能儘早驗證開發的成果是否符合實際的需要，開發者就可以在早期得到使用者的回饋，進而調整努力方向來改善開發成果。傳統的開發方法沒有辦法做到早期回饋，是因為使用者要等到軟體開發出來才能接觸到系統，而且通常他們缺乏軟體開發的專業知識，所以在這之前他們是很難給予開發者有效的回饋。TDD 的開發思維則是促使開發者從思考軟體的使用情境出發，不要太早接觸繁複而細節的設計或實作，而是因應實際的需要而定義出界面規格，然後依據這些規格來決定該如何驗證問題能夠被解決。

因此，TDD 可以直接而穩定的在早期觀察開發狀態，提供設計演進的基準。這樣的基準可以讓開發者在開發過程中，直接面對目標而開發系統而不致迷航。也就是因應現實問題情境的需要，開發者未必有足夠的時間與心力來把設計做到盡善盡美，而是嘗試定義出最主要的功能需求，先採用最簡單的方式來滿足它們，然後再視使用者回饋的實際需要增添或修正功能，必要的時候甚至可以進行重構來維持設計簡潔與完整。換言之，TDD 是用來使開發者面對目標，讓開發範圍不要無謂擴張的一項有力工具。

延緩設計的決策

然而，當開發者採用了 TDD 的開發模式之後，是否正意味著我們儘快將使用者需要的功能實作出來，並不需要進行太多的設計工作，是否代表設計對使用 XP 實務的開發者來說是不重要的呢。但依照同人自身的經驗來看，對於使用 XP 實務的開發者而言，設計並非不重要，而是留下為實際的問題改進設計的彈性。

TDD 並非不做設計，而是把做更周詳的設計的時間延後到可以得到更佳設計決策的時候。或者更根本地來說，TDD 本身就是一種設計手法；而不是因為它以寫測試案例開始，而就把它當做開發的測試過程，這樣的誤解反而違反 TDD 的基本精神。

就設計的觀念來看，設計概念的完整性會直接影響設計的良窳。因此開發者應該盡全力來找出解決問題最重要的概念，同時隱藏或略除不必要的實作細節，來使設計更容易了解與實作。這也就是設計關鍵在於抽象化的道理，但問題是在對問題認識未盡全面以及成本或時程的限制，開發者通常沒辦法在第一時間找出解決問題最適當的核心概念。

因此，TDD 在還沒寫實際的程式之前，先撰寫測試案例。其所關注的問題並不是有效率的測試，而是務實的設計。先以測試案例的方法來識別出系統的大致輪廓，目的是以解決問題為前提，把問題的範圍限制在開發者可以全局掌控的情況下發展解決方案。而不是為了解決方案的堅持而使問題發散，最後反而使問題失焦而終致失控局面的發生。

如此，縱使軟體開發的變化是難以預測的，但只要每一次的變化都可以將廣大的可能性，限制在某一部份，那麼開發者就可以在系統的穩定與彈性之間維持良好的動態平衡；既不會讓需求的變化造成設計的崩壞，也不會因為技術的限制而造成設計的僵化。

穩定的設計可以在環境改變的情況下，不致使系統失去控制，彈性則是可以適應需求的變化而改進系統的設計。期待設計在一開始一次到位，這通常是不切實際的期待，還不如面對現實，先用簡單的方式滿足需求，然後隨著對問題的更深入理解，自然而然地演進出可以適應變化的設計。

這樣的觀念是把軟體開發的焦點放在系統邊界，然後隨著環境變化而逐步演進核心的設計，與傳統機械觀點的隱喻所不同的是，軟體開發不是努力去製造一些東西，而是運用生物演化觀點的隱喻：軟體開發是為了改變一些事情而努力。TDD 與 Refactoring 的搭配，正是促成軟體開發演化出複雜適應性以適應變化的實務方法。它們可用來避免軟體設計求道之過，所謂「道可致而不可求」不去強求而自然得到，才是真正的致呀。

提早整合的行動

其實軟體開發專案要把穩方向是很困難的，溫伯格認為主要的原因多半是管理者介入無效的管理作為；沒辦法掌握好「動作要小，行動要快」的原則，結果更增加專案的複雜度與風險，使得問題更加難以處理。

因此，如果使用 TDD 與 Refactoring 這兩項實務，可以讓我們具體地用測試案例來直接而穩定地觀察開發成果，運用簡單的設計來解決問題，又可以在必要的時候施重構來改善設計，以增加適應變化的彈性。那這樣還有沒有可能沒辦法掌握好設計演進的節奏呢？同人認為唯一的可能就是開發者沒有提早整合的行動，例如沒有在早期接受回饋以調整測試案例與重構，使得行動太慢，動作太大。

為什麼開發者會沒有提早整合呢？理論上，當開發者開發的程式完成 TDD 的測試程式之後，照理要進行清理程式碼的動作。比如說進行重構來去消除程式碼的重覆性或使程式碼看起來更簡潔而易懂。這樣可以讓程式碼在每一次的修正之後，都還是最乾淨的情況下，所以是不大可能會增加程式碼複雜度而造成未來難以維護的問題。

然而，在考量專案實際的問題下，開發者不見得每一次都會有足夠的時間來整理他的程式碼，使之形成良好的程式寫作風格與結構。而且管理者也很難知道開發者到有沒有力行這樣的原則，除非能夠對每一支程式來進行 Peer Review，否則只有「完成功能之後必須清理程式碼」的說法，而沒有為提昇程式碼品質而在每支程式交付時，提供改善回饋的具體措施，對專案其實並沒有太大的助益。

可能有人會認為搭檔編程的實務，就是讓每一次的程式開發都提供回饋。基本上同人並不反對這樣的說法，但要這樣做必須注意開發團隊的文化是否能夠支持這樣的做法。

同人以前曾有專案成員調動到使用搭檔編程的專案團隊，雖然看起來搭檔編程似乎讓她能力有所成長，但我也發現到她也出現適應不良的現象而心生抗拒，而當同人與他當時的主管當時的關心，也很難讓他願意分享自己的心情。由此看來，似乎還是有人習慣自己一個人寫程式，而不喜歡由兩個人共同開發一支程式，而且開發資源的分配者也不見得能夠支持這樣的觀念。

當然，要針對每一支程式做到 Peer Review，在實務上還是有很大的困難的。同人認為問題並不是 review code 要花費多少時間，而是專案需不需要針對程式碼進行儘早的回饋，以在最適當的時機採取最適當的行動？這其實是取決於專案願意花費多大的代價來提昇軟體的品質，不然當品質不合乎需求時，專案所節省下來的預防與檢驗成本將會為造成更大的失敗成本。

要落實提早整合的行動，專案團隊每天早上的 Daily stand-up 會議與採用 Daily build 持續整合的機制，是讓開發團隊的反應能力可以「與時俱進」的回饋活動。就像同人在分享會所分享的實務，在 Daily stand-up 會議得到開發實際碰到的問題，其實是幫我們識別關鍵設計概念的機會。由於過去問題尚未出現或對它們還不太明瞭，所以我們不需要或沒辦法進行設計的深入考量。而在 Daily stand-up 會議中，我們可以及時得到用來演進設計的資訊，並討論如何在後續的計劃中調整設計。

至於 Daily build，每天都會整合出可以實際運作的軟體。在 build 軟體的過程中，會自動執行 TDD 的自動化測試，以確保系統功能都是正常的。如果在 build 的過程中發生問題，馬上會立即通知相關的開發者立即解決問題。這樣可以在每天都讓每個開發小組都能密切地保持緊密的溝通與整合，發現問題立即處理而不需要等問題擴大之後才動大刀。

Daily stand-up 會議與 Daily build 的活動，讓每天都持續溝通與持續整合，每次都讓專案都朝向目標前進一小步，更重要的是，讓成員與時俱進地掌握設計演進的節奏！