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

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

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

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

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

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

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

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

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

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

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

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

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

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年），《溫伯格的系統管理學：系統化思考（第一卷）》，經濟新潮社。

當然，系統發生錯誤的原因，也許真的很可能和方法或技術有關。但是否所謂的方法或是技術，就是一般對系統發生錯誤的評論中經常提到的方法或技術；不是開發者的技術觀念有問題，就是沒有遵照正確的流程及方法來做事？筆者覺得這樣的假設似乎把系統開發看的太容易了。

如果系統失敗的真相，真的是技術觀念、流程、或方法論的問題，那麼只要在系統開發過程中，加強這些因素就可以確保系統開發的成功。但從筆者系統開發的經驗顯示，這些因素雖然很重要，但它們並不是系統開發能得以成功的關鍵，而是要等到逐漸適應系統開發的複雜性之後，才能逐漸地改善增加系統成功的機會。

要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。我們應該學習像內行人一樣，從系統失敗的教訓中看到成功的門道，了解到系統開發複雜性本質的真相；不天真地以為技術或方法論可以解決系統失敗，而是深入省思系統開發的複雜性。基於筆者過去對系統失常的觀察及體會，想以這篇文章從公共建設的系統失常看系統開發的複雜性。

從文湖線的系統品質談起

自從捷運文湖線通車之後，筆者就常聽到有人對它的系統品質提出批評的意見。筆者記得以前在上班的途中，在路上遇到同事就曾和他討論到捷運文湖線的系統品質。這位同事林君的看法是以工程技術觀點看待系統失敗的典型，雖然他的觀點並不能夠讓我們看到系統失敗的全貎，但對系統開發的複雜性本質，倒是不失為一個不錯的思考起點。

林君知道筆者平常上下班都是搭捷運文湖線，然後再轉乘公車接駁。當時他問筆者搭乘捷運文湖線的人潮，筆者回答和過去文湖線未通車前搭乘捷運新店線相比，文湖線的人潮似乎並沒有新店線的人那麼多，雖然不見得會有位置坐，但文湖線的擁擠程度確實比不上新店線。林技術長猜測也許是人們對文湖線沒有什麼信心，所以搭乘的人比較少。

林君長年在國外定居和工作，因此以歸國華人的身份看待捷運文湖線的系統品質，會認為人們對捷運文湖線的系統沒信心是很自然的。文湖線在開始營運之初，發生過很多次嚴重的當機事件，因而讓人們覺得系統的品質不佳，這的確是不爭的事實。不過文湖線現在的狀況，確實已經比剛上線的時候要穩定許多。

依據台北捷運公司所提供的資料，文湖線系統可用度與國際穩定度指標 MKBF 的兩項指標，可以客觀地證明，文湖線已是一條符合國際水準的捷運線。以筆者每天親身搭乘的實際體驗，我認為文湖線現在的狀況，其實並沒有像林君說得那麼糟糕。

筆者以過去參與的大型公共建設的系統開發經驗，讓我比較能夠理解文湖線剛開始上線的系統失常，直到後來才逐漸穩定的狀況。以筆者過去的系統開發經驗顯示，很多系統在剛開始上線的時候，總是會碰到一些偶然的意外，讓系統功能無法正常運作。直到專案團隊耗費足夠的時間與心力，找到系統異常的根本原因，才能針對問題對系統改善或調整使其趨於穩定。

因此筆者認為系統從剛開始上線到逐漸穩定，需要足夠的時間。剛開始是由於開發人員經驗不足，以致於不夠了解狀況而難以掌控系統以因應問題。等到開發人員從系統失敗中得到寶貴的經驗及教訓，並努力費心解決問題並改善系統，系統自然就會開始漸入佳境。很多系統並不像捷運文湖線或是高鐵售票系統那樣受到大家的注意，但其實每個系統在上線後，會出現問題的機率都是一樣的。

不過，林君倒是不這樣認為，而是認為由於開發者的觀念錯誤，才導致捷運文湖線的品質不良。以林君長期在國外開發系統的經驗，他很推崇老美做事的方法，按步就班地照著正確的方法來進行開發的工作，不求速成只求「把事情做正確」。反觀在台灣，他認為人人都是為了趕進度而求快速，經常省略了一些不應該省略的作業，為了節省時間，卻得到系統品質不穩定、甚至是系統失敗的代價。

品質就是沒有錯誤？

林君認為開發者為了讓捷運文湖線提早上線，沒有確實地把開發工作做正確，因而使系統品質變得不穩定而不斷發生系統異常的事故，所以應該歸咎於開發過程的觀念錯誤。林君的論點似乎是認為「品質就是沒有錯誤」，但這種觀念必須把系統開發的錯誤當成道德問題，否則它將會造成邏輯推論上的繆誤。

「品質就是沒有錯誤」會造成什麼邏輯推論上的繆誤呢？的確，當系統出現大量的錯誤時，毫無疑問地，不管系統功能如何，人們還是會因為品質缺失而認為它沒有價值可言。但反過來說，即使系統沒有發生任何的錯誤，我們也無法確認它的價值為何。^[1]

事實上，在追求系統不會出錯的完美之外，要讓系統有價值還需要對特定的人有用處。開發者致力於工程技術的完善，開發出不會發生任何錯誤的系統，即使盡到開發沒有瑕疵系統的道德責任，但這並不代表系統能夠為客戶或是使用者產生價值，而能夠贏得他們讚揚的肯定。

這是因為追求系統在工程技術的完美、和系統符合客戶及使用者在問題領域真正的需要，根本就是兩回事。就像系統開發者常會碰到幾種導出使用者需求的障礙。尤其對於大型規模或複雜的系統，客戶和使用者通常要等待較久的時間，才能接觸到實際的系統。經過長時間對環境所產生的變化，加上他們在想法上的蘊釀，讓系統在認知和實際上的差距變大，於是便出現「是的，但是…」症候群的現象。開發者照著客戶或使用者提出的需求來開發系統，但等到系統開發出來之後，他們反而表示「是的，系統功能看起來很酷，但是它不是我想要的功能」。

「是的，但是…」症候群顯示系統開發在導出使用者需求的一種常見障礙；由於系統在被開發出來之前的不可見和不可觸摸性，客戶和使用者在還沒看到和接觸系統之前，根本很難說清楚他們需要什麼，而且有時候連他們都不知道自己要什麼。

除此之外，系開開發在導出系統需求還有兩種常見的障礙，一種是在系統範圍內存在「未發現的廢墟」，當開發者愈深入認識系統，愈會發現很多原來沒有被發現的系統問題；另一種是開發者和客戶或使用者的語言不同，因為彼此背景、專業知識、技能、以及關注的焦點不同，使雙方在溝通上採用不同的方式，增加彼此誤解和衝突的機會。^[2]

由上面幾種導出使用者需求的障礙，我們可以了解僅僅系統開發要把需求弄清楚，就是一項艱鉅的任務。很多時候系統發生錯誤，問題的關鍵並不是開發者開發的系統有錯誤，而是沒有開發客戶或使用者真正需要的系統。因為在具備規模和體制的系統開發專案中，系統不大可能在層層工程驗證和確認過程把關之下，還會發生沒有把事情做正確的繆誤。但倒是很有可能因為系統開發在各種因素交互作用下產生的複雜性，讓人無法在混亂和秩序之間適當地調適而讓情況失去控制。

系統開發的模糊地帶

從工程技術的觀點來看，系統開發應該需要客觀及明確，其中不應該有模稜兩可和高度的不確定因素存在。但實際上在系統開發的過程中，卻讓我們發現要開發被嚴謹定義的系統，處處出現無法具體而明確清楚定義的難題。系統開發顯然存在模糊地帶，只是假設它不存在，更加容易讓人忽略系統的複雜性，而在系統出現混亂的時候無所適從。

系統開發為什麼會存在模糊地帶呢？理論上，只要能夠發展出足夠具體的需求規格，系統應該就不存在任何的模糊地帶才是。然而，即使沒有前面提到導出使用者需求的三大障礙，人也沒辦法藉由發展嚴密的系統規格，讓系統開發過程的模糊地帶因此而消失。

因為雖然定義具體的規格可以用來規範系統的一致性，減少系統發生模稜兩可情況發生的機會，然而，規格所規範的一致性愈高，也就代表系統的完備性愈容易受到限制；在系統規格沒有錯誤的情況下，不可能不出現任何邏輯上的矛盾。

歌德不完備定理已經證明在理性的世界中，沒有任何的公理系統可以表現它的正確性，而在它所涵蓋的範圍中不發生任何的矛盾。只要公理系統所涵蓋的範圍足夠廣大，可以蘊含自然數所定義的成員，那就必然可以找到沒辦法證明也不能夠證否的命題。此外，也沒有任何的公理系統可以證明自己的正確性。

從歌德不完備定理可以讓我們理解系統開發的模糊地帶是必然存在的。對系統運作可能會碰到各種問題，如果開發者對問題領域沒有足夠的經驗，藉由數理公式及邏輯推演，沒有人可以定義出沒有模糊地帶的完備具體系統規格。當規格具有相當的涵蓋範圍，就代表系統存在更多的模糊空間，不然就代表了規格一定存在邏輯上的矛盾。

歌德不完備定理並不是說沒有系統的規格是完備的，而是指只要規格的涵蓋範圍夠廣，就沒辦法透過計算或是推論來證明它的完備性，否則將會以破壞規格的一致性作為代價。當然對於系統運作將來會面臨的某些情境，開發者可以增加規格的細節來擴大規格的完備性，但通常這樣做會影響到系統其它部分的功能，於是還是無法提昇規格整體的完備性，或是因此喪失規格的一致性。

因此，系統開發的模糊地帶是因為人們經驗的侷限，它們讓我們不可能用規格的正確無誤來證明系統對人的用處，也就無法確保系統的價值為何。因為單單要定義什麼是「完全正確無誤」就是個大問題，很多時候人不是不知道應該把事情做對，而是缺乏可以減少或避免犯錯的經驗。

一般而言，系統開發的錯誤包括缺少兩種典型的經驗；第一種錯誤是缺乏問題領域的經驗，使人沒辦法在規格中清楚定義系統，因為不清楚系統未來將面對的情境，沒辦法問正確的問題以做正確的事、第二種經驗則是缺乏工程技術的經驗，使人不了解系統可以採用的技術及方法，沒辦法回答正確的解答來把事情做正確。

工程技術的對策

在工程實務上，面對系統開發的模糊地帶，開發者並非無技可施。要避免沒有問對問題和沒有提供正確解答的缺失，開發者可以透過驗證（Validation）流程來做正確的事情，然後再運用確認（Verification）流程把事情做正確。這是面對系統開發的模糊地帶，工程技術所提供的對策，只是運用工程實務的驗證和確認流程，是否真能有效降低或避免系統開發的模糊空間？

從筆者實際參與系統開發的經驗來看，在系統開發過程中，開發者經常花費很多的心力在系統的驗證和確認上，但實際上它們對降低或避免系統開發的模糊地帶其實非常有限。主要的原因並非開發者的能力或是他們的使用的流程或方法不對，而是開發者終究會發現他們沒辦法完全忽略、或是排除工程技術以外有關人的因素。

筆者再舉另一個著名公共建設發生系統失常的例子。就像在幾年前，通過 CMMI ML3 的神通電腦開發高鐵售票系統，被人們詬病像登機的售票系統是忽視真正的使用者需求。以通過 CMMI ML3 的公司水準來看，人們很難能夠接受他們會開發出這樣的系統，不敢相信他們具有相當的軟體開發能力成熟度。

CMMI 工程領域中的驗證過程，它的目的是為了證實未來的系統，在預期中的環境中運作可以滿足預期的使用者需求，因此如果系統沒有滿足實際使用者真正的需求，很可能是因為開發者並沒有做好需求的驗證，並且以「用廣泛的方式驗證需求」來發展需求。

然而，高鐵售票系統沒有辦法滿足使用者真實需求，原因不盡然是需求驗證的問題。相信有參與過大型軟體系統開發專案經驗的人都會非常清楚，在開發過程中，開發者能夠主導需求方向的能力是很有限的。面對系統的真實情況，開發者並不如其他的利害關係人更能了解需求，可能很難分辨什麼樣的系統擺在預計的環境，才能滿足使用者需求。

當然，開發者可以用各種方法來探索各個候選的系統解決方案，然後運用各種廣泛的方式來確認需求；諸如用展示、雛型、模擬、或概念驗證等技術來驗證使用者需求。然而，除了筆者在前面提到的三大導出使用者需求的三大障礙之外，系統開發還會常碰到其它原因，讓「用廣泛的方式確認需求」也不能獲得使用者的真實需求。

例如負責需求確認的人員，並不是實際操作系統的使用者。他們可能會誤解使用者的需求、或是因為利害關係而忽略使用者的需要，等到系統開發完成後，系統使用者才發現系統不符合他們的需求。

上面的情況在大型的系統開發專案中很常見，開發者經常會碰到提出需求和使用系統並非同一個人的困擾。跟開發者談需求和確認需求的是資訊部門，當開發者把系統開發出來之後，交付使用單位操作以後，使用者卻又表示系統並不符合他們的需求。

為什麼客戶不讓開發者面對使用者直接溝通需求，而要透過資訊部門的中間人的角色？這個問題其實很複雜，很多時候客戶很難找到確切的使用者來讓開發者訪談需求。即使排除像高鐵售票系統的使用者是一般的民眾的狀況，其它企業內部的系統的使用單位，很經常會橫跨多個部門，要找到所有的利害關係人一齊開會，其實是非常不容易的。

其實還有更主要的原因是客戶在策略觀點、和使用者作業觀點的不同調。客戶的決策高層可能不只是希望系統將現行作業自動化提昇效率，他更希望系統能夠運用資訊科技的優勢來改進作業流程，並改變使用者習慣來創造效益。所以並不希望開發者對系統需求的認知，被使用者的作業習慣框住。客戶端高層對系統的看法，經常會與實際操作系統的使用者的需求南轅北轍，很難能夠從當中找到讓每個人都滿意的系統需求，而只能從當中做出某種程度的取捨。

雖然系統開發在驗證和確認流程並不是對人而是應該針對事，可是忽略人的因素就很難能夠得到執行它們應有的成效。記得筆者曾經經歷過系統經過客戶的 Power User 測試需求的系統，最後在系統驗收之前，卻還是被客戶要求變更需求。這對開發者也許是難以理解並接受的情境，但其實這正是系統開發複雜性本質的展現。即使對企業需求更了解的資深使用者也很難發現自己提出的需求是有問題的，更何況有時候需求的變化是來自人力所不能抗力的環境因素所造成的，開發者很難能夠對他們來多加以責難。

社會技術的關鍵因素

因此，從上面工程技術經常碰到的困難我們可以清楚知道，系統開發即使透過嚴謹的工程技術，也不可能忽略人的因素，因為即使工程技術沒有出現錯誤，也不能證明它是對人有用處而展現價值。這正說明了系統開發的複雜性並不是單獨以工程技術的觀點就可以理解，而是更需要正視有關於社會技術的觀點。

社會技術觀點和工程技術觀點最顯著的差異，正是前者並不如後者的客觀，這也代表是非對錯沒有固定不變的標準，常常同一件事在不同的專案或基於人的不同立場而會有不同的結論。其實系統開發的複雜性正是因為無法限定在單一的觀點，而是必須考量各種不同面向的多重觀點。

因此，系統開發需要考量多重觀點，要先從取捨系統需求出發，這代表系統開發者必須做好利害關係人管理，它對系統的成敗具有積極的決定因素。利害關係人管理需要識別出專案的利害關係人，然後挖掘、管理、以及影響他們的需要及期望。專案的利害關係人包括主動參與專案的人員、或是他們所感興趣的事情，會對專案的產出或成敗有影響的個人或組織。

系統開發應該要儘可能地滿足每一位利害關係人的期望和需要，然而，一旦利害關係人之間，彼此意見衝突而且無法協調共識時，那系統就必須要以滿足專案的客戶為主。也就是說要把客戶當成是關鍵的利害關係人，為了滿足他的需要和期望，其他人的需要及期望都可以被放棄。

然而，有些時候系統開發者眼前直接面對的客戶、或是專案的贊助者，他們的意見不見得會讓系統變得更有用處，而且經常還會讓系統變得更不容易使用，反而讓人們沒辦法接受系統。因此，在這種情況下，可能會促使開發者認為應該思考使用者實際的需要，因為可能他們才是最重要的利害關係人，而不以滿足客戶或專案的贊助者的需要和期望為目標。

不過，這種想法的問題是開發者通常沒有能力判斷誰的期望和需要比較重要。當然使用者是直接使用系統的人，他們的期望和需要或許應該優先考慮。但客戶和專案贊助者是真正出錢的人，當他們和使用者的意見不一致、甚至是發生衝突的時候，考量現實的因素，開發者真的很難為了符合使用者的期望和需要，而違逆客戶或專案贊助者的要求。

其實開發者運用他所熟悉的工程技術，通常是不能分辨誰才是真的利害關係人，因為對於客戶所關心的問題領域，有太多他不清楚的事情。有時候，開發者基於工程技術感覺應該是對的事情，往往最後才會發現它可能是錯的。當然，其它像客戶、或專案管理的單方向觀點，可能會受到對解決方案領域的認識有限，也沒辦法分辨誰才是真的利害關係人。當我們聽到有人主張「客戶永遠是對的，所以你應該照我說的這樣做」就會知道這絕對不是真理而是偏見，忽略了系統開發的複雜性來自多重面向。

在混亂中找秩序

既然系統開發的複雜性不能忽略多重面向，那麼我們就不可能在問題領域和解決方案領域之間選擇一邊來強調系統開發的核心思想是什麼，而是應該在各種不同面向觀點的交界之處，去找到適應系統開發複雜性的關鍵所在。換句話說，系統開發必須調合各種陰陽面，從未知和已知之間、混亂和秩序之間、結構和非結構之間，去尋找可以融合各種觀點的最大可能性。

要調合系統開發的各種陰陽面，以融合各種觀點最大的可能性，依複雜適應性系統（complex Adaptive System）的觀念來說，停留在會發生自我組織的混沌邊緣以適應變化，可以從三個方向著手。首先必須要把廣大而無所不包的可能性，限制在一小部分、其次是必須保持允許輕微改變的穩定性、最後是必須要在靜止不動的死寂和過度活動的混亂之間維持平衡。

這三個方向讓我們看到了適應系統開發複雜性的三大重點，那就是系統必須是可測試的、擁有允許改變的彈性、以及必須能夠持續的整合以維持動態的平衡。測試是為了知道系統的邊界在那裡、彈性是為了容納更多需要的變化、整合則是讓演進系統的火光能夠迸現。

於是，面對環境變化的無常，開發者需要自我組織來演化出適應複雜性的能力。筆者認為這種能力才是系統開發品質的關鍵，以工程技術和社會技術之間的調適，來尋求不同領域觀念之間的融合。這樣就能夠使系統在變化的環境中，能夠保持穩定的動態平衡。

就好像《太極拳論》提到「偏沉則隨，雙重則滯」的觀念一樣。工程技術重視規律和秩序，而社會技術則強調適應變化和彈性，兩者各有所長而無法偏廢。在開發過程採用（adopt）、調適（adapt）、並熟練（adept）不同著重點的轉移，是讓人學習在混亂中找秩序的法門與修煉。當然筆者承認這實際做起來真的不大容易，但至少它不會讓人用簡化的思維來看待系統開發。

後記

這篇文章本來是準備投稿 ZDNet Taiwan 的文章，從去年八月和同事的對話引發同人的寫作動機開始，到最近才把整篇文章完成，歷經了將近一年的時間。在寫作過程中，文章經過無數次的修改，希望能夠寫出不同以往談論系統開發複雜性的文章，沒有深澀的術語、也能用非技術專業的觀點來看到我對複雜適應性系統的領會。

這正是同人想突顯和另一篇有關系統開發複雜性的文章〈軟體開發是工藝還是工程〉最大的不同，也算是對我最近兩年在系統開發所行、所思、所得，做一個比較全面的整體論述。系統開發真的需的有效的方法，但沒有任何一套方法可以忽略人的因素而能夠正確無誤地運作。

很多時候，讓人們沒辦法流程把事情做好的原因其實很簡單，但人的情緒卻通常把它變得很複雜。尤其是高階主管的情緒，不去觀察現象來瞭解執行和計劃的落差，以調整計劃來做正確的事情，卻以批評與責難來反應自己的情緒，這正是顯示高階主管在系統開發管理的無能為力。這種無能代表他們除了只會讓人「聽命辦事」之外，其它對管理其實是一無所悉。儘管他們能夠一直用口號來「教育」員工，並藉此檢查工作者的工作態度對不對，但他們的管理能力只能讓他們「簡化」系統開發的複雜性。

這篇文章比〈軟體開發是工藝還是工程〉更擴展它的詮釋領域，系統開發不應該只限制在軟體開發上。雖然軟體的抽象性會增加系統開發的困難度，但系統開發複雜性的本質所在，在於技術和業務觀點相互撞擊而產生各種變化，它不只是存在於軟體開發的系統中，對其它非軟體的系統開發也是相同的狀況。

同人並不想讓這篇淪為整理過去文章的新瓶舊酒，而是以這兩年系統開發實務得到的經驗，融合複雜適應性系統的觀念，內化成系統開發調適變化與紀律的動態平衡之道。雖然這篇文章也許寫了太久，以致於錯過了投稿 ZDNet Taiwan 專欄的時機，但發表在網誌也算是對自己有交待和對喜歡《同人的生活派對》軟體開發和專案管理文章讀者的回饋。讀者的支持是作者寫作最大的動力，不管是在網路專欄或是個人網誌，同人將會持續寫作來分享我在軟體開發和專案管理領域所體會的點點滴滴。

1. 曾昭屏譯（2006），《溫伯格的軟體管理學：第一卷（系統化思考）》，p.294，經濟新潮社
2. Dean Leffingwell & Don Widrig (2003), 《Managing Software Requirements: A Use Case Approach》, Second Edition, Addison Wesley Professional.

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

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

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

專業的傲慢？

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

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

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

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

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

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

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

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

現實世界並不理想

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

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

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

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

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

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

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

狐狸與刺蝟

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

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

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

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

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

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

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

設計不夠好？

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

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

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

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

管理的重要性

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

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

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

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

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

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

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

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

陳鳳馨說許多媒體很奇怪，先前颱風災情嚴重就大肆批評氣象局預報不準，而今天氣象預報的第一把交椅要離開，又一直報導他的好話。這就是理盲又濫情，不像她在這次的莫拉克風災都是幫氣象局說好話，去年的卡玫基颱風，氣象預報不準到離譜本來就應該批評。

她還說這次有人說 CNN 比中央氣象局還要準是搞錯了，中央氣象局的預測比較接近實際的兩量，只是不懂得像 CNN 使用「Huge! Huge!」來表示超大豪雨。她說，把氣象預測的結果說得讓一般人都能了解，也是非常重要的專業，她都很想幫氣象局的人員上課。雖然把專業讓一般人能夠了解是很困難的，她不苛責氣象局，但如果能做到那不是更好嗎？

同人聽來聽去，實在搞不清楚說吳德榮理盲又濫情的道理在那裡？如果社會真的存在理盲又濫情的現象，吳德榮也只是對這樣的社會現象，選擇不再燃燒他的熱情奉獻生命，而是退休專心好好地過自己的生活，如果這樣是理盲又濫情的話，那麼要怎樣才不是理盲又濫情呢？

經過這一番思辨後，同人發現真正理盲又濫情的人不是別人，而是好像什麼都懂，什麼都會的名嘴們呀！從他們的口中，專業好像變得好簡單，只有他們懂得教別人怎麼做事，因為所謂的專家都不夠聰明，一旦不符合他們的價值判斷，就是「理盲又濫情」。這種不重視專業、自以為是的專業實在令人不敢領教！

同人看吳德榮提前退休的新聞，我認為問題不在於中央氣象局的預報有沒有疏失，而在社會上彌漫著一種碰到問題責怪做事的人的風氣。結果只會使得以後再也沒有人願意做事了。反正不做不錯，事情做好又沒有人會獎勵你，所以只要能夠不攬事在身上就不要多事。

這就好像專案失敗時，人們把責任推到執行專案的人身上的道理一樣，不做事的人反而有話說。但專案中最有價值的教訓與經驗，不會有人去關心。慢慢地想藉此磨鍊能力的人愈來愈少，因為做事的人都不會有好下場，手下也只有奴才而沒有人才。

對名嘴的這種批評，Zulu 在河道上提到問題在於惡意的講假話都完全不用負責任。他並提到張大春的文章引用了王夫之的議論，已經點出「批評專業化」是批評虛假的根源。

看了張大春的文章，同人很慶辛為了小孩的成長，我們家沒有接電視。不過，對於廣播節目出現名嘴的這種「批評專業化」，恐怕只會加深我的反感而不去理會那些名嘴到底說什麼了吧！

但沒想到第二天，不到八點半同人和老婆就聽到電鑽和榔頭敲打的聲音了。這個時間出現這些聲音，會干擾女兒的睡眠而影響她的正常發育與成長，這實在令我們十分困擾。

其實早在幾個月前，同人就曾要求裝修承包商，要她請工人在九點前不要使用會發出巨大聲響的機具，以免干擾女兒的睡眠。最近發現在九點前，還是會發現工人使用那些機具發出聲響，本來以為他們就快完工了，所以就沒有向承包商反應噪音問題。但現在噪音的問題很嚴重，於是同人在上班前打電話給承包商，向她反應噪音問題，並得到她的允諾會讓工人遵守及配合。

後來老婆告訴我接下來的故事發展。她和女兒被噪音吵得受不了，倉皇走避時碰到承包商。她質疑承包商為什麼時間還沒到就開始施工，害她連早飯都來不及吃，好像逃難一樣。承包商連忙向她賠不是，但表示是工人沒有按照規定的時間來施工。老婆聽到這理由更生氣，如果承包商不能約束工人照規定施工，那住戶根本不能信任承包商在公告所做的承諾。

大樓管委會主委這時候出現了，老婆藉這機會消遣他。問他說：「不是說保證今後不會有噪音出現了，怎麼今天噪音那麼吵？」主委聽到也不甘示弱的轉向承包商說：「我最倒楣了啦，他們租房子還好（指我的老婆）受不了退租不住了就好。我呢？跑也跑不掉！」老婆看到主委只會抱怨而不想解決問題，而且又戴口罩，所以不想跟他吵，就先離開了。

還好住我們家對面的媽媽這時候經過，在弄清楚大家的爭議之後，想到解決問題的方法。她建議請大樓警衛在施工開始時間之前，阻擋工人不讓他們進入大樓施工，等施工開始時間到了之後才放行。結果這個方法果然得到效果，讓大樓的住戶不用清早就忍受噪音的襲擊。

同人聽完老婆告訴我以上故事的後續，讓我覺得對面的媽媽果然是處理問題的高手，不像主委只會感情用事。如果我聽到主委說那句話，我大概會說：「主委您真是愛說笑，你怎麼可能會倒楣呢？大不了你把房子租給別人，這樣就可以把你的問題變成別人的問題呀！」不過話說回來，我相信承包商有誠意解決問題，但當工人無法配合遵守她訂出的辦法時，問題該如何解決呢？

解決問題的關鍵就是正視「人不是完美的」的事實。同人是工程師出身，我很能體會工人希望早點把事情做完早點走的心態，對擾鄰後果的嚴重性他們可能沒有明顯的感受，而不是故意不去配合。所以以為訂下工作時間的規則就可以讓他們去遵守，其實是太天真的想法。那位媽媽的辦法正是對人性弱點的積極管理，不去假設人們一定會照你的方法去做事，而去思考問題的對策。看在同人的眼中，實在是令人激賞呀。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在 facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果，找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。

舜平學長說求快求彈性，忽略系統文件重要性的後果就是使用者說沒空寫文件，如果這時我們也沒有將系統重要資訊記錄下來，那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊，結果使得系統的維護變得更加困難。

雖然以上的現象在台灣是開發者經常碰到的問題，但那是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。

「彈性－快，是之前老闆說的。常常就是邊想邊做，搞死 IT 人員」舜平學長提到他對彈性的認知。但這種對彈性的定義有沒有問題？我們追本溯源，從教育部國語辭典可以查到「彈性」這個字詞有兩個解釋：

物體受外力作用，會改變其形體，而當外力除去後，即恢復其原狀，此種性質，稱為「彈性」。

比喻事情無固定標準，而可隨機調整。

從這裡可以看到舜平學長提到彈性的定義，是採用彈性的第二個解釋。指系統開發這件事沒有固定標準，必須隨著需求改變而機動調整，以達到讓系統快速適應變化的目標。但事實上正如學長說的，搞死 IT 人員，而系統也不斷發現問題叢生的問題，這樣其實並沒有達到彈性可隨機調整的標準。

開發系統臨機應變，不去根據未來可能的改變而計劃，而是面對當前需求的改變而修正系統，可以讓開發者不把時間浪費在無謂的預測上，迅速地開發出使用者真正需要的系統。但實際上為什麼卻並不是那麼一回事呢？我們可以從與系統開發相關的事、物、人來了解，彈性固然是沒有固定標準，但所謂的擁抱改變卻並不代表任由毫無限制的改變發生，那樣只會造成極度的混亂而使系統崩壞。

從事的角度來看，任何使用者需求都需要時間，而時間是取決於功能的複雜度。對於使用者而言，他們認為他們需要的功能都很簡單。但當許多簡單的功能集合在一起，其相互關聯的交互作用所產生的複雜度與錯誤，可能就會讓開發者很難應付。因此，開發流程的彈性，是用來決定該在什麼時候修改或增加什麼功能，以降低複雜度與錯誤的機會。

從物的角度來看，良好的系統架構有助於快速因應需求的變化。架構良好的系統具有強固性，不會因為系統運作環境的不同而產生功能失常。同時也具備擴充性與延展性，可以隨時依據使用者的需求變化而調整系統的功能。然而，通常在專案時間及成本的壓力之下，很難有時間能夠設計出最佳的系統架構來適應所有的情況，只能因應最主要的問題來設計適當的架構，並在必要的時候可以逐步演進系統功能，這便是系統架構的彈性。

從人的角度來看，專案具備來自不同利害關係人的各種面向。例如使用者通常在意的是他們作業的問題，系統能不能幫他們解決，開發者則在乎使用者提出來的需求是否精確，用來發展出良好的架構以增進開發的效率。這些不同的觀點常因為不同的需要、價值觀、專業、以及所用的語言不同而產生相當的落差。因此，溝通的彈性是在於是否能允許各種正反意見充分表達，進行對話與良性的互動，以建立資訊暢通的溝通管道。

因此，從系統開發相關的事、物、人來看，我們知道彈性的意義是追求快而不亂。這意謂著接受一定範圍的改變，而非任由混亂無秩序，那是一片混沌而非美其名追求彈性。彈性其實也需要計劃與紀律，只是和典型的開發方法有所不同。

如果開發者最早開發出來的系統，是可運作與架構簡明不容易出錯的系統，那麼隨著使用者需求的增加，為什麼會愈變愈複雜呢？這當然是因為時間緊迫與系統沒有足夠的空間可以容納新功能。

時間緊迫意謂開發者沒有時間增添或修改系統功能，原因通常是會干擾他正在進行的開發，而增加開發的複雜度與出錯機率。所以開發者應該延緩會影響現有功能的使用者需求，這才是追求彈性的做法，這樣就不可能邊做邊改；因為戴上修正功能的帽子時，是不應該去增加功能的。

那麼如果沒有足夠的空間呢？這時開發者應該著手改善系統架構而非疊床架屋勉強加入新功能。由於開發者以前可能對需求了解程度有限，所以很難開發出比較具有彈性的架構。等到對問題的了解愈來愈清楚，慢慢看清楚問題的脈絡與解決問題的模式時，這時正是改良設計的最佳時機。就是因為架構的改良，無所不包文件與繁複的流程自然不太需要，而是需要在開發過程有助溝通的基本文件與流程。

然而，開發者為什麼不修正架構以容納新功能呢？或許有些開發者以為架構不改變還是可以容納新功能，所以可以允許複雜度多加了一點。但等到下次，他還是會有同樣的想法，直到這樣的行為結構造成系統問題叢生的弊病才會發現事態嚴重。寫到這裡，讓同人想到《易經坤卦文言》所說的：

積善之家，必有餘慶。積不善之家，必有餘殃。

臣弒其君，子弒其父，非一朝一夕之故，其所由來者漸矣。由辨之不早辨也？

不去順應變化之道，讓系統不斷更新^[1]，這樣並非追求彈性的系統開發。充其量，只能算是擠壓開發者的彈性，這是彈性的另一種解釋；承受壓力後回復原狀的性質，但結果通常是讓開發者彈性疲乏。或許這就是舜平學長說的無言吧。

延伸閱讀：（其它與系統開發彈性相關的文章）
軟體開發是工藝還是工程？
穩定的程式是偶然？
程式碼的結構、迴圈與處理
Time-Boxing 於軟體反覆演進的必要性
資訊服務的適應性觀點
評論「專案假設」的相關討論
軟體開發能力的自我組織

1. 坤卦順承變化趨勢，否則陰疑於陽必戰的結果是坤上六爻變的「龍戰于野，其血玄黃」而產生劇烈變化，最後還是會重新走向乾卦的自強不息。

那麼，用有紀律的思考與行動，以做到簡單，我們該怎麼做呢？前一陣子，同人閱讀了《越簡單越有力量》，我覺得這本書的觀念與方法，剛好可以提供我們複雜世界簡單之道的思考方向與指引。

這本書是作者將自己的公司投入「尋求簡單之道」（search for a simple way）專案的研究心得。這個專案是一項由北伊利諾大學共同贊助的五年計劃，目標是為了研究美國企業資訊時代的規劃與設計工作。研究結果發現企業在改善工作環境、符合客戶與股東期望方面，已有長足顯著的進步；至於如何讓工作各項選擇透明化，進而提供必要的工具與資訊，以提供員工績效，卻相形見絀。

這樣的結果讓我們體會簡單之道的重要性，但什麼是簡單之道呢？本書作者認為簡單就是一種資訊革命，是為了化複雜而明確，也就是製造正確的指令。這些指令照樣鼔勵全面改變、實驗、概念融合、發明、學習；而其背後的大原則，是要為執行工作者釐清問題與真義。

複雜面向的四個主要來源

那麼，為什麼我們的工作總是那麼複雜？本書提到根據「尋求簡單之道」的研究結果顯示，造成複雜面向有四個主要來源，依重要性往下排列依序為：

1. 沉重的資訊負荷：有八成的員工與六成的主管找不到、或無法轉化必要資訊，以做出決定。

2. 沒效率的溝通：每個人都認為他們盡力去努力溝通，但大部分溝通都缺乏原則。

3. 目標宗旨不明：眾多目標欠缺目標整合，整合目標不可缺少領導者的配合。此外，嚴謹的目標設定遮蔽真正授權，掩飾公司內部的缺乏互信。

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

因此，我們應該如何發揮簡單的力量，減少我們工作的複雜性呢？本書提出簡單必須掌握兩個必要前提，首先必須改變對時間的運用方式，讓我們用更有效率的方式來運用時間。其次管理者應當逆向思考，以使用者為中心，也就是依員工的需要來規劃工具、流程與資訊。此外，簡單之所以有效，是因為兼顧人性與常識兩大原則。本書提到任何以企業邏輯主導變革的失敗，是因為違反了簡單的這兩項原則，以致於沒辦法扭轉人們的行為與習慣而功虧一簣。

掌控時間

身為知識工作者，我們該如何更有效率地運用時間呢？書中提到要提高工作效率，必須通過「了解」、「感覺」、「運用」、「執行」、以及「達成任務」這五項基石。針對每一項建立明確性，將強化你對時間的分配運用。

五項基石如何建立明確性呢？我們必須「了解」那些事真正重要，每一個人都必須弄清楚，什麼能帶來最大效益？因為我們可能還沒考慮周詳，就開始要求別人開始著手。我們也必須考慮並準備這項過程能帶來的「感覺」，沒有人做決定絲毫不帶感情。因為考慮怎麼辦的過程，必然有情緒在裡面。「運用」則是我們必須專注在需要派上用場的工具及資源，這是大家完成工作的方法。因為即使大家目標相同，但許多員工卻缺乏必要的工具或訓練。

「執行」是我們必須建立並控制期望，充分了解程序及後續步驟，是最起碼的條件。因為當命令與控制遭到排斥，許多經理人便喪失了澄清目標的能力。所以要讓每一份子知道，誰該在什麼時候擔負什麼責任。「達成任務」則是我們必須對我們想達成的目標，建立可以傳遞的觀點，對於成功的定義，員工與公司看法不同，如果把行為列入考慮，就比較能體會成功的結果。因為人們往往焦頭爛額同時進行多個案子，卻不曉得成功之後又將如何。

規劃

本書提到不論計劃規模的大小，規劃者的角色就是為了塑造成功的對話。換句話說，規劃我們必須整合計劃中的每一個小節，讓討論充分發揮效益，以確保眾人的時間、精力都沒有被浪費。如何做呢？書中運用五項基石發展出兩項工具：

1. 了解，感覺，執行：每個人藉以經過討論，弄清楚自己的角色與行為。

2. 運用以達成任務：進一步完成工作。

這兩項工具，目的是幫我們整理思緒。它們並不是用來做表面文章，而是提供支援，改變我們支配時間的方式；讓我們把想法或計劃為輕重有序，條理分明的對談。

行為溝通模式

本書提到在研究當中，觀察人們在採取行動之前，需要怎樣的資訊。結果研究發現決定採取任何行動的背後，必然隱含下列五個問題：

這和我的工作有何關係？每個人要關切、要注意的事情太多了，如果我們把注意力擺在所有可能有關的事情上，那將一事無成。如果我們能把我們所說的事情，與大家目前利用時間、精力的方式做個聯繫，那就真的值得一提。

我究竟應該採取哪些步驟？這不是命令與控制，而是讓期望透明。我們必須充分傳遞下列問題的答案：緊接著的下一步該做什麼？整個流程包括那些環節？誰該負責這個步驟？如果責任轉移，會採取什麼方式告知？

我的表現將如何評估？結果如何？除了讓員工明確了解自己工作的成效、成功的定義、多久可以得到主管評語等討論之外，還必須了解任務成敗所導致的結果。

有什麼工具與支援可供使用？大多數的人不是缺乏必要的輔助工具，就是不懂得如何利用。如果能夠連接工作目標和可用的工具，不管我們要做什麼，力量將十分可觀。

對我及我們而言，有什麼意義？正式的鎬賞或獎勵不見得是唯一的選擇，其它如減輕壓力、提高樂趣、加強團隊精神、以及有更多時間與家人相處也是可以激勵員工的辦法。

如果我們都能致力回答這五個問題，那麼任何談話都會不費吹灰之力，迅速落實為行動；你將馬上獲得眾人的支持與理解，於是會發現要改變時間運用的方式，其實並不困難。

行為溝通模式還能幫我們聆聽與過濾訊息，刪除不必要的資訊以擷取菁華。依據以上五個問題，任何談話、會議、電子郵件都應明確過濾掉未提及「與我做的事有關」、「後續步驟明細表」、「期望」、「能力」、「回報」的資訊。

以故事來彙整融合

改變對時間的運用方式，我們需要架構嚴謹的思考與溝通，意味著在採取行動之前，必須好好地思考，用來整理與釐清一切問題。然而，如果我們要釐清問題的對象，是在工作團隊以外的廣大對象，這時就很難用五項基石的概念與他們溝通。本書認為此時必須運用說故事的手法將五項基石融入一個引人入勝的大綱。

所有的故事都包括了衝突、轉變、高潮、結尾四個階段。應對到企業的故事則是企業改革前提開始，意味著員工必須對現行方式有所不滿，才會有動機想採用另一種模式。接著表揚成就，檢討失敗，企業的轉捩點就是當企業慶賀成功、檢討教訓時；在這個時刻，讓員工了解目標達成多少，該如何改進。

企業故事的高潮，是企業今年度成功目標達成之時，把故事架構放在策略方案上，有助讓人們窺見其它架構無法呈現的漏洞。最後由使命、願景、價值觀來結尾，讓員工知道為何而忙，不過必須注意不要只顧談高調而忽略提供必要工具、流程與支援，讓員工能順利發揮潛能。

以使用者為中心

本書認為簡單化的公司是以使用者為本，日常決策者的需要才是考量核心。當一切資訊與流程結構，無不以使用者為中心，那麼員工便會深公司誠心幫助他們提高工作效率，而創造出簡單化公司的企業文化。但要如何做呢？本書認為公司要創造讓員工容易了解、感覺比較容易、容易使用、容易執行、容易達成目標的企業環境。

容易了解是讓公司以使用者為中心規劃員工所需的工具、流程、與資訊，以讓員工發揮更大的潛能。感覺比較容易則是建立員工與公司的相互信賴關係，不要把焦點放在科技、數據等事物上。本書提到信賴的起點就是高階主管的承諾，保證為員工準備使用者為中心的工具、資訊、體驗。

容易使用則是員工使用目的為焦點，提供幫助他們整理更簡潔資訊的工具，以避免他們迷失在繁複的細節中。容易執行則是建立利於對話的環境，推動良性辯論，讓正反意見都能充分表達聲音。容易達成目標則是規劃友善的使用環境，容易獲得所需，以提高達成目標的機率。

感想

這本書顯然是站在高階管理者的角度來思考，如何讓員工在簡單的企業環境中更有效率地把事情做好。同人不是高階主管，但這本書讓我在工作的簡單之道上有很大的啟發。

印象中書中一句話深得我心：複雜是無法控制的，你只能建立好成員的關係，讓資訊與溝通通暢無礙，系統會自然演化。同人實際的工作很能體會這一點；任何強調控制與命令，而忽略關係與專業的工作環境，最後只會因為造成管理的困難而失敗。

這本書還沒看完之時，與某位同事討論工作內容，我發現討論主題一再發散而無法聚焦，當時體會到「這個討論怎麼會那麼複雜」，而這種溝通模式卻是技術人員常用的互動模式；談論過多的細節卻未碰觸到問題的重點。可見改善溝通方式會讓我們獲得簡單之道的報酬而讓時間的運用更有效率。

在看完這本書沒多久，剛好聽到朋友提到主管要求他支援某項專案的要求。我知道有些人會認為在台灣的軟體開發生態，對這樣的要求覺得習以為常，但以簡單之道的觀點來看，那位主管以談高調的方式，無法有效地與朋友具體溝通工作內容，同時無法或刻意迴避給朋友必須的工具與支援，讓我可以預見朋友將會陷入複雜的泥淖之中，而浪費青春。

朋友的主管要她加入以 c# 語言開發的專案為例。由於她只會 vb.net，擔心這兩種程式語言有很大的差異，希望主管能夠提供更多協助的承諾。但她的主管卻認為這不成問題，因為同樣是 WinForms，不會有太大的差異。主管表示只要按照 sa 及 sd 開的規格開發就好了，而且到時候發生問題他也不會坐視不管。

朋友並不是不相信 vb.net 和 c# 差別不大，而是希望主管能提供更多學習時間與其它資源或支援的承諾。因為照主管之前的說法，只提供朋友 sample code 讓她參考，而沒有提供額外的指導。主管的「沒有問題」卻難給予具體的保證及方向。

從組織文化的觀察，朋友很難相信那位主管的保證，而且更擔心從專案的問題變成朋友自己的問題。新技術的學習並不是問題，無法充分溝通才是問題複雜面向的主因。

這代表朋友想要明確釐清問題的想法將會被忽視，再加上可以預期專案的不確定性、目標宗旨的不明（主管說按照書面規格開發程式就好，但如果是規格錯誤也要按照錯誤規格來開發，這可能嗎？）等因素，朋友的這項任務的複雜程度，怕只會雪上加霜。看在旁觀者的眼中，也只能把它當成學習簡單之道的負面案例。