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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XDite 在文章中前半段，提到他對做測試的看法：

我個人的看法是認為在大多數的情形下，你需要對你的「軟體」寫 "Test"，而且是要先寫 "Test" 再行撰寫程式，也就是 Test-Driven Development。因為程式碼會逐漸龐雜，沒有人可以 write code without bug，也不可能每次都有辦法用手測出來，加上有時候寫錯程式時的損失不是事後修理就有辦法彌補的，所以我們必須要寫 Test Case，及早抓出問題。

XDite 說這是所謂寫測試的重要性。但他強調這卻不是程式設計師「可以」不合時宜的盲目在「任何類型」的專案強行導入 BDD / TDD 的藉口。XDite 指出寫測試程式來確保程式正確性的解決方案，存在著額外多付成本的代價，亦即：

1. 「 寫測試 + 寫程式」 所花的時間，大概是純寫程式的 1.5 -2 倍時間。
2. 「會寫 Test」、「正確的測到該測的部份」、「寫出好的測試」，都需要學習時間以及功力。

於是 XDite 提出了四點原因，用來當成反對盲目 BDD/TDD 的理由。即使是程式設計師因為厭倦了維護在之前的專案後期的維護，因為修改程式碼而一再發生的問題（無論是小問題，大問題），而決定在下個專案，無論什麼專案類型都要導入 TDD / BDD，XDite 認為這在他眼中認為這是相當不正確的事情。

1. 每個專案類型不盡相同，有的是要求高正確性且牽扯到金流問題且開發時間充裕。有的純粹只是 event，用過極丟。有的是幫人外包，只要求規格正確，開發時間不寬裕。有些則是混合型。有些部分的程式碼則是相當難以寫測試（如 View），C/P 值極低。應該考慮每個專案的類型甚至是 component 去決定哪部分該嚴厲的規定寫測試，而哪些部分可有可無。

2. Startup 前期應不應該導入 TDD/BDD ? 我認為不應該。為什麼，很多人都認為 TDD / BDD 是為了確保「程式的正確性」，所以無論如何我們都應該執行。卻忽略了 Startup 的成功要素是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」。

3. 寫測試只是為了要能自動驗證「程式的正確性」、降低「程式出錯的機率」，但團隊合作開發程式最重要的是團隊中的「溝通」，大家對 function 和架構要有一定程度以上的理解，共同撰寫程式要有一定程度以上的 convention。變更任何重大架構（如 core function, db schema, 底層設計前）都要提醒大家。

如果每個人都只寫自己的，然後想改什麼東西照自己心情，沒有人想舉手之勞通知大家、跟隊友溝通。坦白說，那寫測試有個屁用，可能只是不會爆 production code，development 拉下來還是爛光光，還是要修到死。

完全不溝通、不制定規範，卻期待寫測試能夠解決一切，這樣的想法不是很奇怪嗎？

4. 無論如何，就算寫了再完美的測試，再完美的程式碼。程式還是可能在你完全預期不到的狀況爆掉，所以應該做的是要接受無論如何就是要修 bug 的這件事，然後想辦法把修 bug 的成本儘量壓低，也把因為 bug 會產生的損失也儘量壓低。

不要期待測試是萬靈丹。否則期待越大，失望也大。

到底是評論 TDD、還是做測試？

同人覺得 XDite 這篇文章的論點令人混淆；他到底是在評論盲目導入 TDD 的行為、還是在探討開發者該不該多花時間寫測試程式，以確保「程式的正確性」？這兩者完全是不能相提並論的事情，同人很不能理解在前面提到寫測試程式來確保「程式的正確性」需要花更大的代價，而下一段就拿寫測試程式必然會忽略其它開發活動（如溝通、修正程式 bug 等活動）來否定 TDD/BDD 的價值。

難道 XDite 以為 TDD 就只是在做確保「程式的正確性」之測試而已嗎？假如 XDite 真的是這樣認為，那麼顯然他把 TDD 誤解成是在做測試。不過，對於同人在文章後面留言提出的質疑，XDite 回應否定他把 TDD 誤解成寫測試，而是不喜歡一些沒有把 TDD 搞清楚的人，強行要把「TDD」和「測試」混在一起，綁在一起要求無論如何都要「TDD」。他提出了一種典型把測試跟 TDD 混淆綁在一起的狀況，是遇到下面這種混蛋邏輯：

因為程式會爆炸，或者是以後改來改去又會暴很麻煩 => 所以我們需要寫測試 => 既然要寫測試，也許我們不應該事後補寫 Test Case，而是應該來試著 TDD。

另外，XDite 還提到理想狀況開發者可以用 TDD 來開發產品，先寫測試去制定出規格，然後寫出實際程式通過測試，達到 System Design。接著藉由不斷的寫新測試、新規格，然後寫出更多的程式，邊修邊測到 boundary。但現實狀況是，就算是熟悉 TDD 的開發者，他卻不一定是「規格」、「設計」的主導者。

XDite 說在這樣的「現實狀況」，很多時候， Team 裡面有開發者不能強迫導入 TDD 的環節。強行推動只是互相絆倒和拖垮彼此的時程。XDite 認為 TDD 只在某種「單純」（專案成員素質接近一致，沒有 highly dynamic factor，目標單純）的專案、環境、Component 下適用。

雖然 XDite 對他的觀點，似乎並沒有留下和同人繼續討論的空間；我發現我後來的留言被當成 spam 處理。同人猜想也許他的文章說歡迎指教，但我的留言讓他感到威脅、或是覺得再繼續討論壓力太大，於是想中止和我就這個議題繼續討論。同人不想責怪他對我留言的反應，即使他這樣做只是要表達內心情緒的不滿，但我仍然不會停止對 TDD 的這個討論主題的思辨，並且會透過網誌來表達我的觀點。

評論 XDite 的四點理由

XDite 提到他不喜歡把「測試」和「TDD」綁在一起的混蛋邏輯，但它反對不管怎樣都要導入 TDD/BDD 的原因，卻又以寫測試案例的「極端」現象來反駁 TDD 的價值，顯得不合邏輯。

在 XDite 寫的四點原因中，除了第二點有明白地表達不該在 startup 前期導入 TDD 之外，其它三點看起來都好像是在批評寫測試程式的問題（還不論是不是先寫測試程式）。因此，這樣看來就很令同人費解；如果真如 XDite 所說的他不喜歡人們把測試和 TDD 綁在一起，怎麼會把寫測試程式出的問題都算在盲目導入 TDD/BDD 的頭上？如果連自己在談 TDD 的時候，都會和寫測試程式的問題牽扯不清，那麼又怎麼能責怪別人把「測試」和「TDD」綁在一起呢？

同人認為在 XDite 所提到的四點原因，它們並非錯誤，而是並沒辦法當作反對不管如何都要導入 TDD/BDD 的原因。雖然在第一點原因中 XDite 並沒有說錯，有些程式像是使用者界面程式的測試程式就很難寫，因此的確不大適合強行對他們進行 TDD。然而，當遇到這種情況的時候，使用者還是可以選擇用 Mock Object 把那些沒辦法寫測試程式的物件區隔起來，然後針對最多部分可測試具有演算邏輯的程式來進行 TDD。

因此，使用者界面程式沒辦法建構 TDD 的測試程式對於 TDD 而言，並不是什麼太大的問題。因為基本上 TDD 不是用來當做測試的工具，而是用來設計可以驗證符合使用者真實需要的工具。所以開發者只要針對可測試、或該測試的部分建構測試案例就夠了。TDD 的目的是要確認花費最小的努力來滿足使用者的需求，測試案例所要求的不是全面的完整，而只是確認達到剛好達到滿足需求的邊界，這將會促使開發者先以界面的思維來整合系統各要件。對 TDD 測試案例比較重要的問題，是如何設計可測元件與非可測模組之間的界面。

至於 XDite 提到對於某些程式沒有必要寫 TDD 的測試程式，同人倒會很好奇有什麼客觀標準、或是有誰可以決定什麼程式沒有建構 TDD 測試案例的必要？在同人導入 TDD 的經驗中，就曾經有開發者要求 Business Object 不要寫 TDD 的測試案例，當時他們的理由是它們沒有什麼太複雜的邏輯、而且不大容易會變動，所以應該不需要為它們建構 TDD 的測試程式。

然而，事實證明，接受開發者這個要求的決定，是整個系統發生苦難的開始。因為所有的問題都從 Business Object 的瑕疵開始引爆，直到把 Business Object 也納入 TDD 測試案例的範圍，系統程式的品質才能達到令人接受的水準。

再來，對於 XDite 唯一有討論到導入 TDD 的第二點，他認為 startup 前期不應該導入 TDD，因為 startup 的成功要素是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」。然而，同人對此卻認為恰好相反，TDD 正是「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」的利器。

為什麼？不用 TDD，人們多半傾向會以自己所相信的基本假設來解答問題，也就是以自己的經驗或熟悉的事物，從核心出發來發展解決方案，以期待把事情做正確。在這種情境下，人們通常會想得太多，而容易有過度設計（over engineering）的傾向，而 TDD 則可以讓人回歸到從問題來決定系統的邊界，再以最符合經濟效益的方式來解決問題。所以自然能夠以最省時及省力的方式來做正確的事情，更可以在市場上獲得致勝關鍵。

XDite 說他不同意「快速驗證你的 Idea 的正確性」、「快速應付市場變化調整的速度」、「在市場廝殺中節省成本存活下來」，是「對 TDD 再適合不過」。但同人很清楚這「對於熟悉 TDD 的開發者而言」是很自然的，顯然 XDite 是忽略了我認為這句話成立的前提，在於開發者是否能熟悉使用 TDD 的節奏。

如果開發者熟悉 TDD 的節奏，當他沒辦法寫出測試程式的時候，代表他對系統所要解決的具體問題還不夠清楚。為了要弄清楚他必須更清楚去溝通，而且 TDD 的習慣會促使他傾向以使用者的情境去溝通，而不是拿功能要使用者告訴他該做什麼。只有在開發者瞭解使用者的情境之後，開發者才能具體而正確地寫出驗證程式的測試案例，這說明在 TDD 寫的測試案例不是做測試而是在做設計，而且不可能因為寫 TDD 的測試案例而讓開發者不做溝通。

所以 XDite 提出的第三點和第四點原因，或許對於做測試是可能成立，但在 TDD 的情況下卻是可能性很低。因為除了建構 TDD 的測試案例需要了解使用者情境更需要溝通之外，TDD 的測試案例本身就是有用的溝通工具。TDD 的測試案例是能夠經過驗證的具體規格、同時它也是相關元件、API、或是模組的範例程式。

當然 TDD 更不會有太要求測試程式的完美，而忽略修正 bug 的問題，因為 TDD 的測試案例並不要求完美，而只是夠用就好。而且 TDD 在實際上可以用較低的成本來修正 bug，因為它能夠自動發現錯誤，再加上重構能夠逐漸改善程式碼的品質，TDD 沒辦法確保程式一定不會出現錯誤，但它總是能夠以較低的成本得到較高品質的程式碼。

TDD 必須很「單純」？

XDite 說 TDD 只在某種「單純」（專案成員素質接近一致，沒有 highly dynamic factor，目標單純）的專案、環境、元件下適用。但在同人導入 TDD 的成功經驗中，很不巧就有專案、環境、元件不單純的例子。

在一個國內知名金控公司的銀行外匯系統建置專案，表面上專案的目的是為了建置新一代的外匯系統，而不想受制於舊有系統和廠商的牽制，但實際上客戶高層的想望是要架構能夠整合機構其它系統的基礎建設平台。然而，當詢問客戶高層對系統目標的意見時，他們給的回答竟是「把系統做到令客戶咋舌」這種有說等於沒說的答案。

專案的成員並非來自開發組織的單一部門，而是從各個組織挑選各種經驗和背景的人，雖然有專業能力資深的人，但也有對相關技術不熟悉的成員。可以想見，在專業、技術、能力、背景如此懸殊的情況下，因為「人的問題」而發生團隊衝突是很難避免的，這個專案的團隊衝突的課題，正好提供我碩士論文的研究動機。

當時開發團隊過去沒有接觸過相關問題領域的經驗（事實上是客戶指定不希望找對有金融經驗的人來開發，公司沒有開發過相關領域的專案，而有不錯的系統建置專案，才是客戶會選擇我們的主要原因）、開發環境也是用開發團隊過去完全沒有經驗的技術。

客戶指名這個專案要使用 SOA 架構，由前端 JSF 以 Web service 呼叫到 Application Service，呼叫後端直接存取 POJOs 或是傳送訊息的服務、而中間物件的傳遞則透過 XStream 的序列化以 JAX-RPC 進行遠端傳送、至於元件包括軟體架構也都是從無到有按照系統需求逐漸演化成型。

專案團隊大部分的人都沒做過 TDD，加上這麼多「高度動態的因素」，而導入 TDD 竟然能夠成功，是因為我們運氣好嗎？這麼說必須忽略開發組織守舊勢力對新方法論、架構和技術的反撲，否則就很難解釋公司總經理的質疑和反對。實際的情況是我們不是運氣好，而是用對的方法讓我們做好準備。當公司高層開始質疑的時候，我們早就已經透過 TDD 快速驗證我們的方法沒問題，而讓總經理無法否決我們的設計成果。這讓人目睹 TDD 的真正價值所在，不是確認「程式的正確性」，而是讓人有勇氣並保持簡單的節奏。

同人認為 TDD 的成功並不在 TDD 自動確認「程式的正確性」，而在於TDD 讓人有勇氣把事情做好，讓人遵循良好解決問題的節奏和紀律。那就是：1.確認問題；2.依照問題情境，發展用來驗證方案的標準；3.設計方案並執行驗證，以達符合驗證標準；4.視組織需要改善方案，再次執行驗證以確認符合標準。

依照這樣的節奏和紀律，可以讓人在確認方案做正確之前，已經驗證方案是用來解決正確問題，以避免過度設計和設計不足的兩難。這正是傳統方法很難避免的問題；即使開發者擁有熟練的開發技術，但少了在事情做對之前先做正確事情的紀律，品質問題正是因此而叢生。

現實的真相

XDite 用「理想狀況」來反駁用 TDD 來瞄準、射擊、修正後再射擊的觀念，他說很多時候， Team 裡面有開發者不能強迫導入 TDD 的環節，強行推動只是互相絆倒和拖垮彼此的時程，這是所謂的「現實狀況」。這麼說似乎是意味了 XP 敏捷方法的 TDD 實務無法在「現實狀況」實行，而是「理想狀況」。這種說法對同人其實並不陌生，就像我在〈羅馬不是一天造成的〉這篇文章所提到的情形：

同人偶爾會與 X 君分享我的工作心得，他很羡慕我能夠堅持設計的理想，遵循好的設計原則及開發方法發展出軟體架構，像他就沒有這樣的機會。而和同學分享我的工作成果時，他則認為我堅持設計理念可以成功，是因為我們公司有足夠的資源可以讓我們玩，換成是小公司，就不會有這樣的成功條件。

其實同人在那篇文章所提到的概念、架構和技術的驗證，所用的方法正是 TDD。但同人分享成功經驗看到人們的反應卻發現，除了羡慕和佩服之外，多半是認為我剛好遇到足夠的條件來支持我實踐理想，而他們的「現實狀況」一定不允許他們這樣做。

假如真的是「現實狀況」不允許開發者導入 TDD，那麼面對開發出來的軟體品質不彰，他們採取了什麼行動來面對現實呢？以同人在一家開發軟體產品的 startup 公司看到的「現實狀況」來看，他們只是試著更努力而辛苦地把過去的工作做得更好，可是彷彿都一直不能如願。

同人在那家公司分享過我的 TDD 的經驗，RD 經理認為或許應該要做 TDD，可是因為使用資料庫的關係，會讓 TDD 很難做到或是做了沒有太大的效益。同人並不太瞭解為什麼他會有這種顧慮，因為按照我過去的經驗，資料庫的部分可以用 Mock Object 或是 Hash Map 版本的實作來區隔開來，而且這樣做有優化設計的好處。不過，同人不便公開質疑主管對 TDD 的顧慮，而是選擇尊重他在「現實狀況」下的決定；等到適當的時機再導入 TDD，除了眼下的問題需要被克服之外，還要讓開發者們的步調都能一致。

直到同人離開那家公司之前，TDD 都是一直被人們掛在嘴巴上說，但從來未曾真正去做。然而，隨著需求愈來愈多，程式碼也愈來愈複雜。這時候，關於軟體品質愈來愈殷切的議題便是元件很難被獨立測試，而是必須整塊合在一起才能測試，但這在除錯上很沒有效率。於是各個元件要獨立測試變成一項非常重要的需求，但滿足此項需求最大的問題便是軟體架構需要動大刀，而更緊急的嚴重問題便是有一大堆在客戶端的 P1 和 P2 的 bug 需要解決。

於是在龐大的時程和品質壓力下，常讓 RD 和 QA 沒辦法在時限內產出符合品質要求的軟體。我們用的方法，就是一次又一次的讓 RD 以大規模前置設計（BDUF），然後等程式開發完成之後再 handover 給 QA。雖然表面上公司採用敏捷的開發流程，每天在固定時間召開 Daily Stand-Up Meeting，但是看起來專案管理者的腦袋並沒有換成敏捷的思維，仍然是期待以更精確的預測來改善專案的進展，即使是他們對專案狀況的預估從來沒有準確過。

在這種「現實狀況」下，雖然同人已經提醒 Scrum 偏重管理面而非工程面，但由於 RD 經理對 TDD 仍然有疑慮而不敢貿然採用它來提昇程式的品質。整個開發團隊只是一遍又一遍地用和昨天用過的方法，來試圖解決今天相同的問題，但我發現專案管理者好像不合邏輯地希望得到不一樣的結果。它正符合愛因斯坦對精神錯亂所下的定義：

一遍又一遍做同樣的事，卻期待不同的結果。

同人看到專案管理者對「現實狀況」的理解是，因為開發者在事前（不用心而）想得不夠多，所以不能在一開始就把事情做對，而導致軟體運行發生錯誤。但同人認為「現實狀況」的真相卻是，關鍵在於開發者沒有辦法做正確的事情，在很多時候設想了太多無謂的問題，而把心力分散在處理瑣碎的事情，而無法專注在關鍵問題上思考。

這是因為無法快速驗證方案對解決問題的效果，往往在開發者花費大量心力脫離「焦油坑」之後，才發現真實情況有很多地方是無先無法預料到的。換句話說，這不是開發者做的東西不對或是不好，而是面對適應變化，沒有把握「動作要快、行動要小」^[1]的原則。

當然在「現實狀況」下，導入 TDD 的實務不見得真的能夠有效地解決問題，對於任何一種開發方法論，我們都不應該盲目導入，而是要弄清楚它的適用範圍和限制，TDD 當然也不例子。然而，對於把 TDD 和做測試混為一談，然後藉此推測團隊中「一定」有 TDD 不能強迫導入的環節，強制推行只會互相絆倒和拖垮彼此時程，同人認為這是扭曲 TDD 當成做測試的繆誤。

使用 TDD 來開發軟體，開發者實際花費在測試案例的時間並不會很長。因為程式開發者不可能只寫程式而不驗證自己的程式碼，否則無法確認程式符合規格，就不能認定他已經寫完程式了。既然驗證程式碼是他的責任，那麼測試先行只是確認程式碼符合規格的一種方式，這樣只是把後面應該執行的工作先做好，並不會增加開發者額外的工作量。

因此建構 TDD 的測試案例並不需要額外的工作量、也不大可能會因為執迷於測試而沒有花時間溝通共通架構、或是程式的 debug 時間。又能節省開發者因為想太多而多花費過度設計的時間，而且可以支持驗證程式的重構來加強程式的結構，不會因為增加功能而影響程式碼的品質。

TDD 在開發程式之前先寫測試案例的用意，並不是為了及早自動抓出問題。雖然這通常是採用 TDD 能夠產生的附加價值，但 TDD 先寫測試程式的精神是為了驗證未來方案能夠符合需求，以確認方案是在正確的命題方向上發展。開發者發展解決方案，每前進一小步，都能夠知道這一步離他的目標更接近或是遠離，這讓他可以馬上採取行動來調整方向以減少偏差。於是開發者可以做到真正的面對現實，這正是掌握適應改變行動要快、動作要小的原則。

不理究理者的未嘗知義

採用 TDD 來開發軟體，並不能做到確保程式的正確性、或是降低程式出錯的機率。因為要做到這個目的你就必須「預測」程式會發生問題的一切可能性，並且預先把它們都放到測試案例中，才有可能達到這些目的。然而，事先做預測已經違反了敏捷開發的基本原則，也違反了 TDD 的基本精神，認為 TDD 的目的是為了確保程式的正確性、或是降低程式出錯的機率而把它和做測試混為一談，這只是不明究理的人未嘗知義的偏見。

就像在網路社群中，James O. Coplien 以「宗教信仰」形容 TDD 的迷思算是最典型的代表，它以 TDD 不可能達到測試良好的涵蓋率來批評它的效率不如傳統的軟體工程方法。同人曾經評論過這種觀點的繆誤：

品質的問題並不是測試效率太低；而是開始測試的時間拖得太久，使得分析設計階段的缺陷不斷地擴散而使開發人員窮於應付。例如開發者在設計的過程中有沒有去思考設計驗證的問題，還是把這個責任推給後續的品管作業，例如 code inspection，或是各種形式的審查作業？

這個答案無關乎方法論本身的優劣，而是關乎開發者面對問題的態度，這對品質有著直接而深遠的影響。沒錯，我們需要專注於思考，但思考的重點並不在用那一種檢驗方式比較有效率，因為那樣我們將會落入品質是檢驗出來的迷惘當中。而是應該思考，對這個問題為什麼我會這樣設計？我如何驗證它是可行的？有沒有可能它會無法解決問題或造成其它我沒有想到的問題？

把做測試和 TDD 混為一談的觀點，忽略了 TDD 的價值不在檢驗程式的正確性，而是找出足以解決問題的系統邊界的設計過程、以及面對目標採用有效的節奏把事情做好。對於 TDD 而言，測試不是用來確認程式沒有錯誤的目的，而是定義系統邊界的手段與過程，因為品質的關鍵不在於確認沒有錯誤的程式，而是從程式接口之間發現軟體自然演化的脈絡；學習庖丁解牛的精神，以游刃有餘的技法來體會軟體開發之道。

至於 XDite 在意以「混蛋邏輯」把 TDD 和測試綁在一起，同人覺得根本就是沒有必要地在鑽牛角尖。當程式設計者說他想要寫測試程式來確認程式的品質，並不見得他真的是把測試和 TDD 綁在一起；而且就算是他真的把測試和 TDD 綁在一起，同人也認為無傷大雅。有時候，管理者不見得會瞭解程式開發者所表達 TDD 的正確的觀念，所以開發者必須學會用不太精確但表達到重點的說法對管理者提出需求。

這也就是說，對於程式設計者而言，他所需要的是擁有能夠提昇他程式品質的方案，而 TDD 是他想要可能可以符合需要的候選方案之一。提出測試的附加價值是讓管理者比較能夠接受的說法，當然程式開發者也有可能真的把測試和 TDD 綁在一起，但即使這樣也沒有關係。因為當他實際採用 TDD 開發程式後會發現程式品質的提昇不是測試，而是在系統邊界附近發生自我組織的演化過程。

很多時候，我們真的沒辦法期待人們觀念正確才開始動手執行，因為那樣等於你什麼都不用做，而且軟體開發的重點不是理論怎麼說，而是實務上怎麼做，程式開發者從實務上的執行才能真正瞭解，TDD 不能跟做測試混為一談。

1. 曾昭屏譯（2006年），《溫伯格的系統管理學：系統化思考（第一卷）》，經濟新潮社。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

專業的傲慢？

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

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

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

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

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

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

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

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

現實世界並不理想

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

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

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

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

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

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

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

狐狸與刺蝟

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

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

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

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

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

我常在做的 "教練" 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 "一致性" , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 "教練" 已經離開工程師角色一段時間, 這又是另一個挑戰

同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。

而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。所以是管理能力的不足而非技術，也是我文章著墨於領導觀點重於技術觀點的主要原因。

對於領導，MaoYang 認為最好的領導是當顧問而不是教練；他提到工程師可以自己發現問題，來請教 "顧問" ，當然如果工程師都看不到問題，那麼就另當別論。MaoYang 還提到他很欣賞上次 David Ko 在敏捷開發分享會提到的經驗；團隊主動提出要使用 Scrum，這時候身為經理的 David 只要做順水推舟的工作即可。

不過同人倒是認為，David Ko 的經驗是可遇不可求的。同人的經驗顯示，在台灣的軟體開發機構，是很少經營者有願意改變的胸襟與勇氣，即使有些老闆在口頭上說改革，但骨子裡卻是很畏懼改變而使所謂的改革只是流於表相化。

MaoYang 提到他在職場現實看到的一個現象；他說我在文中提到教練最好可以不給答案，而是提出問題讓工程師去思考。但是他在現實職場看到的是一堆人在揣摩老闆在想什麼？要怎麼做，老闆才會滿意？因此有時候他反而不太喜歡這樣的領導模式。同人覺得 MaoYang 這段說到重點了，但為什麼會形成這樣的企業文化呢？

MaoYang 說他覺得在中國人的企業都會有這種問題，這是為什麼 "雍正王朝" 被列為某些企業的管理教材。在雍正王朝裡面一堆這種範例，沒有正確答案，正確答案在主子的腦袋裡面。 這種文化要改，可能是領導者的腦袋要先改。

然後 MaoYang 還分享後來他想到他說技術經理下來當教練是不得不，意思是說理論上應該不用走到這一步，問題出在當初找人時，沒有嚴格把關，沒有找到對的人。他還提到 《Peopleware》 裡面也有講要如何 interview 工程師，所以《從 A 到 A+》裡面也有講企業要成功，要找到對的人。所以他認為技術經理當教練的徵兆對一家公司其實是不太好的，技術經理應該去看前瞻的東西，而不是當一名 "教練"。

其實同人很同意找到對的人來做事的想法，但事實上這卻是不容易做到的，尤其是軟體開發工作的專案，更難以找到對的人來做事。這種困難包括兩種情境，一種是找不到合適的人才來執行任務，另一種是把真正的人才放到不正確的任務上。

第一種情境雖然很常看到，但經常也可能是技術經理沒辦法慧眼識英雄或因材施教，而使好的人才淪為的犧牲品。在這種情狀下，其實問題不在找不到人才而是經理人本身領導或管理的問題。寫到這裡，我想到溫伯格在《第一級評量》講的一句話：沒有不好的士兵，只有不會帶兵的將領。

所以技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！

技術經理有時候要扮演 "教練" 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來

對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：

在公司內部, 技術經理當 "教練" 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 "教練" , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方

以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。

在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。

技術經理應該要教導他的團隊成員什麼東西呢？MaoYang 的長笛老師朋友說知道什麼才是完美音符，但自己卻不知道怎麼示範，然而如果技術經理知道如何示範他所知道的完美，那麼是否他就能夠傳遞正確的觀念了呢？答案並非如此，因為在這個地方存在一個陷阱；對於藝術而言，或許追求完美是有所意義，但在技術的領域中，完美真的是那麼絕對而必須去追求嗎？

在科技的領域中，我們通常找不到真正的完美。站在解決問題的角度來看，以前被認為是完美的方法，也許在今天會無法解決我們面對的問題。換言之，很多表面上看起來相似的問題，但在問題的本質上卻是全然是完全不同的，而且人們通常沒有辦法一眼認清它們，而是要深入研究後才能知道如何找到適合的方法來解決問題。這其實也是技術開發工作最困難的地方，很多問題很難找到最佳的解法，而只能基於現實用最適解來處理它們。

所以對於逐漸不再接觸技術的管理者而言，他們過去以為的完美是否到了今天還是那麼如此絕對呢？答案未必見得。就像溫伯格評論「成熟度」是偏頗字眼的道理一樣；所謂完美通常是基於個人信仰的價值判斷，這只是基於個人的感情需要，而非專案的真正需要。

因此，技術經理應該要教導他的團隊成員的東西，不應該是他已經知道的東西，而是他還不知道的東西，這樣他的團隊才能不被自己的所知有限而限制住。但如何可以做到呢？同人認為好的教練不會給答案，而是提出關鍵的問題教人們去思考，使人們在困惑產生學習的動機，以及有勇氣質疑權威與傳統上以為的理所當然。這樣才能增進團隊成員解決問題的能力，提供答案不會讓他們得到成長，只會造成依賴而削弱他們的力量。

至於技術經理擔任教練的目的為何，MaoYang 說當團隊的程度良莠不齊的時候，技術經理才不得不帶頭出來當 "教練"。那是否意味著技術經理當教練是為了讓團隊素質可以齊一化呢？但如果答案是肯定的，那代表在團隊的多樣性會慢慢消失而由—致性來取代，那麼喪失一致性的代價是否值得。但如果答案是否定的，那麼技術經理擔任教練的目的終究為何呢？

對同人的這個疑問，通達人認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。通達人說的沒錯，但在實務上，同人經常看見技術經理會犧牲團隊成員的多樣性來增加一致性。

比如說運用制度或規章來抑制團隊成員的行為，不希望成員面對問題採取不一樣的想法與做法，但這通常是因為技術經理的管理彈性不足，才會對團隊成員處處設限。因為依據「必要多樣性法則」，系統的行為會由系統最有彈性的部分來掌控，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他在管理上的困難。因此他必須設法降低多樣性才有辦法管理好他的團隊，但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。

當然團隊合作需要一致性，但技術經理當教練當拿一致性來取代多樣性卻不見得是明智的。就拿所謂的基本動作來說好了，很多人都忽略了基本動作需要以成員背景能力與組織文化為前提。因為如果不考量專案臨時與獨特的特性，你可以找到適合的人依據某種方法來訓練，但專案的特性讓你找不到適合的人來達到目的。

因此對專案而言，基本動作是夠用就好，但何謂夠用，正考驗著經理人面對現實的勇氣與智慧；縱使團隊的一致性可以降低管理的困難度。但一致性不是技術經理當教練的目的，只是用來達成最終目的－提昇團隊績效的手段之一。因此，如果解決專案問題的需要更高的團隊多樣性，恐怕如何提昇管理的彈性，才是技術經理成為好教練的關鍵因素吧！

同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。

但為什麼人們要盲目地做些行不通的事呢？其實以同人這麼多年軟體開發的經驗來看，他們不見得是意識不到這些做法行不通，而是可能因為害怕與恐懼，讓他們不敢嘗試新的方法來解決問題。

縱使無法解決問題的挫折是令人沮喪的，但如果要放棄過去習慣的做法來開發系統，他們更會茫然不知所措，擔心因此對現況失去掌控能力。於是明知過去的做法有問題，但更害怕失去它就會一無所有，於是只好將它緊緊地捉在手上，並期待這一次會有奇蹟出現，改寫過去失敗的命運。

不過如果人們理性一點，都會意識到要改變命運不應該期待奇蹟，而是需要「勇氣」讓我們改變心智模式，然後採用有效的方法來解決問題。在這方面，同人覺得比較幸運的是我常碰到好主管，能夠支持我想要把事情做好的想法。

記得過去的主管 Y.L. Liu 曾經告訴過我的話：「如果過去這樣做行不通，那今天就應該嘗試不一樣的做法」即使改變必然會遭遇到阻礙，然而當我們勇於面對阻礙而因應問題時，才能促使我們打破過去的習慣來進行有紀律地思考與行動，進而更有效地解決問題。

紀律，也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事，而是熟悉了解問題是什麼，並加以解決問題的過程。如同我過去的文章所強調的，軟體開發不只是工程，或是工藝，而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法，而是基於重要價值觀與原則發展出來的實務，而最重要的價值觀就是為了思考如何「解決問題」，至於使用流程方法都只是手段而不是目的。

然而，根據同人的經驗，想要軟體開發過程運用以上的觀念，我認為最困難的是對專案目標的混淆。在這次的分享會之中，同人也發現有些 PMP 背景的朋友，他們很關心如何準確預估專案的範圍、時程與資源，因此希望了解敏捷開發如何來解決這樣的問題。但其實敏捷開發方法根本不需要做精確的預估，因為改變是無法預估的。所以它強調的是反應變化的能力，而不去為預期或抑制變化做太多的努力。

或許有人會把精確的專案預估，看成是專案成功的重要目標之一。但以同人這位 PMP 對專案管理的認知來看，精確預估並非專案的目標，而是達成降低專案風險目標的手段之一。或許用這種手段來蓋房子，或生產看得到、摸得著，可以明確度量的產品可以做得很好，但用它來開發軟體卻不見得可以行得通。

我們應該改變對軟體開發專案的傳統思維；假如軟體開發的本質，就是難以精確預估，那麼我們就不該將力氣浪費在預測上，而是應該用來進行對專案更有效益的事情上。但這不代表敏捷開發方式不做規劃，而是規劃的重點不在精確地預測未來，而是用來定義專案的基準線；利用每一次的反覆過程的回饋，用來改善或調整後續的計劃，以增進我們回應變化的能力。

因此，使用敏捷開發我們不需要具細彌遺地預測未來的改變，只需集中心力面對今天所發生的問題。換句話說，開發者也不需要一份不會變更的功能需求清單，而是了解專案目前所要解決的實際問題，進而運用(adopt)思考及創意、調適(adapt)方法然後再熟練(adept)所需要的技能來解決問題。

那麼，以上敏捷開發的思維是否打破專案管理的基本觀念？同人從不認為如此。依照 PMBOK 的專案管理知識領域與流程本來就支援管理改變的做法，問題只在於管理者是否掌握住變更管理的重要原則並熟練它們：

首先、必須確認改變對專案有正面效益；

其次、必須確認影響變更的因素已發生；

最後、最重要的是管理變更。（PMI，2000）

我們看到這些原則不但並不違背敏捷開發的思維，同時兩者是相通並且相輔相成的。的確，對於軟體專案而言，改變意味著增加軟體開發的風險，但害怕專案風險的心態，也代表你的團隊面對風險只能迴避它們以確保安全，但你所獲取的利潤也相對變得較低（DeMarco & Lister，2007）。於是你必須辛苦地在市場上試圖降低軟體價格來與對手競爭，除非你能夠勇敢地面對挑戰，選擇快速回應變化才會創造機會，為專案產生更大的正面效益。

那麼對於環境或需求的變化，軟體開發團隊要如何快速回應呢？依據同人的經驗，大規模的事先設計（BDUF，Big Design Up-Front）通常無法立即迅速地反應變化，而且常常會造成過度的工程化（over engineering）的問題。而依賴開發組織導入某些流程、工具或方法論其實也並非成功的關鍵。我認為只有增進團隊溝通與合作，讓團隊能為面對問題而共同努力，才能夠快速地回應變化。

或許有人會認為詳盡的文件可以增進溝通，但實際上它的成效不高而且常常要人們花費很多的心力，除非你發現它真的有幫助，否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率，但它們也會讓工作變得艱難。因為無法被替除的工作，它們是更具備知識密集的特性，需要更有才幹的人來完成任務（DeMarco & Lister，2007）。所以在導入任何工具或方法論之前，你應該提醒自己，敏捷開發是以人為基礎，面對的是現實而非理想。

誠如 David Ko 在分享會中說得好，任何方法的導入如果最後變成政令宣導時，那就非常不妙了。同人則以為快速回應的關鍵不在於遵循方法論的做法，而在於面對專案的現實問題，讓團隊共同因應問題而改變。David Ko 提出了很多他的專案所導入的做法，同時分享他感受到團隊成員自動自發的喜悅，也讓同人希望能夠見賢思齊。

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

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

設計不夠好？

戴爾是世界知名的電腦直銷公司，擁有 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# 的程式來進行整合。

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

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

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

管理的重要性

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

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

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

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

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

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

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

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