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

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

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

專業的傲慢？

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

她說前年的卡玫基颱風，氣象預報不準到離譜本來就應該批評，但去年莫拉克風災氣象局預測兩量的數字比 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 讓她參考，而沒有提供額外的指導。主管的「沒有問題」卻難給予具體的保證及方向。

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

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

同人直覺感到不妥，並非因為朋友並不諳 c/c++ 這種程式語言，加上它與 vb 之間，存在根本的程式語言差異。我認為比較嚴重的問題還是溝通過程出現不精確的語言，這代表她們公司的品質文化，對解決專案的問題是沒有效果的。

學習 c++ 當然並不輕鬆，尤其如果沒有 c 語言基礎的話，學起來更是會格外吃力。因為 c++ 語言特性與 vb 的差異很大。比如 c/c++ 特有的指標，就很容易讓初學者混淆，如果觀念不清楚，常會讓程式產生記憶體衝突甚至是當在不明所以的地方。但程式語言或是程式設計的技術，這些都還可以藉由學習成長，對於積極進取、追求自我成長的開發者而言，這些並非是大問題。

誠如我在 facebook 的好友，也是以前在點空間聚會有一面之緣的仁傑兄，看到我對這件事情的分享，他建議：

If you want to encourage her, you can said that. Let her have a confidence to do it.But you have to keep coaching, monitoring and reviewing her codes.

然而，這件事情我覺得讓人擔心的並不是朋友的能力夠不夠。我注意到的是她們公司的品質文化，品質文化的問題並不在技術，它多半不會是專案成敗的關鍵，而是專案管理者的態度。

朋友的分享讓同人看到，她的主管用一些不大精確的語言來讓她感覺問題不大。比如說用「c++、vb 都只是工具而已，不管你用那一種工具來開發系統，其實都不會有太大的差異，所以我們大可不用擔心」的說法，正是用不精確的語言來表達不當的概念，這其實是相當要不得的簡化。

溫伯格認為一個軟體開發組織的「品質文化」，重點在於管理者面對品質的態度。他在《第一級評量》提到對軟體工程師而言，沒有什麼觀察技巧比準確聆聽更重要的。為什麼需要準確聆聽？溫伯格指出軟體是一個講求準確的行業。當不準確潛入軟體之中，失敗和危機也就不遠了。但我們如何聽出朋友主管溝通用詞不精確？溫伯格在書中提到不當的概念會使人做出錯誤推論：

概念會讓人難以應付的原因是，這樣的概括性觀念通常可提供一個便捷的捷徑。所有的科學和工程領域都是以概念為基礎，這些概念是從觀察少數的案例後為多數未經觀察的案例做出總結。但是，概念會讓我們落入過度簡化的陷阱。

如果我們聽到刻意或無意地將概念的使用範圍擴大，那我們就要小心了。好比說朋友主管說「只是」工具，「不管」用那一種工具，「都」不會有問題。如此擴大言語的普遍性，是否朋友的主管想要隱藏什麼資訊呢？實在是值得我們更進一步地深入了解。

事實上，不同程式語言間存在的差異，這些技術細節常會使問題變得複雜，使我們必須花更多的時間來釐清問題。也就是表面上技術似乎是不成問題，但實際上出現的問題，卻會花費許多時間及心力來溝通清楚。尤其是 c++ 和 vb 使用上有很大的差異；程式語言的改變，並不是只要把它們看做是工具的改變那麼簡單。

果然朋友告訴我，她們公司很多 SA 及 SD 都只會開規格，不管程式是否做得到。後來發生問題卻多半找不到原來的設計者，而結果最後都要重新設計。這讓同人一點都不意外，因為從朋友主管把棘手任務視為燙手山芋；只要有人接就不用管朋友能不能勝任，那不是他的問題而是朋友自己的問題來看。這些都是朋友所任職公司的軟體品質文化使然，而最根本的原因是基於管理者無效的管理行為所造就的呀。

延伸閱讀：參考噗浪討論串。

今(09)年初，應中山大學資管系主任鄭炳強教授的邀請，到他們學校做了一場演講。由於筆者與鄭教授原先並不認識，是透過台科大資管系主任李國光教授聯絡到筆者，因此，鄭教授邀請我在演講前先與他碰面、共進午餐，並且藉這個機會交流彼此在軟體工程方面的心得。

在那次午餐約會中，我們聊到了系統分析專業這個議題。鄭教授表示欣賞筆者寫的〈展現系統分析專業的七種能力〉，還曾在課堂上向他的學生推薦這篇文章…與鄭教授交流互動的過程中，也讓筆者得到不少收穫，回到台北後，一直想找機會分享這些收穫。

由於我一直想找機會回應那篇文章的讀者意見，也就是ZDNet讀者對於那篇文章的前半段〈怎樣才是專業的 SA？〉的一些留言，筆者發現這次行程的收穫，正好可以讓這篇文章有一個很好的起點。

軟體專案開發的四個困難

在言談之間，筆者可以感受到鄭炳強教授對台灣軟體產業發展很關心，但他對一般軟體從業人員忽略軟體工程的基本修煉卻很憂心。

他觀察到人們往往熱衷於追求新技術，而總是忽視軟體工程的基本原理。他還指出軟體開發與一般產品開發有著一個根本上的不同；也就是知道開發方法還不夠，更必須了解方法運作背後的原理。因為不了解原理就不能針對問題進行正確的分析與設計，更不用說可以有辦法順利地解決問題。

這也就是軟體專案比其它專案還要困難的地方，他認為軟體專案開發主要有四大困難，也就是溝通的困難、問題本質的困難、整合的困難、以及團隊合作的困難。後來筆者在他寫的書中看到更為清楚的對照；亦即「電腦對人腦、答案對問題、程式對系統、個人對團隊」。

站在資訊系統的企業觀點來看，資訊系統是企業為了因應環境挑戰而發展出來的解決方案^[1]，所以系統分析師必須找到可以解決真實世界的問題的解決方案，這是屬於解決方案的結構化範疇。然而，這意味著系統分析師必須比系統使用者更了解他們的問題，這些問題多半是半結構化，甚至是非結構化的，因此困難的是如何讓結構化的解決方案領域、與非結構化的問題領域進行溝通。

因此，建置一個可解決使用者需求的資訊系統，系統分析師必須要能發現藏在需求背後的真正問題，否則開發出來的系統往往會很難解決系統使用者的問題。正因為如此，系統分析師不能只考慮到技術層面，也不能把問題只是簡化成系統使用者所提及需要的功能，而必須將它們放在一起，統合思考以形成能夠相互協調的系統。如果想要達到上述目標，光靠個人單打獨鬥當然不夠，而是必須藉由團隊合作的力量。

圖1：問題領域與解決方案領域

該相信誰的專業？

所以，從軟體專案開發主要的四大困難的觀點來看，我們就能輕易瞭解專案成敗的關鍵真的不是 know how，而是在 know why。

這從〈怎樣才是專案的 SA？〉的回應中也可以看到。系統分析專業並不在於使用什麼開發方法，而是在於當開發方法碰到了阻礙或挫折時該怎麼辦？如果系統分析師沒有問為什麼的能力，不去弄清楚 know why，將很難克服上述的阻礙或挫折，使他們所熟悉的理論及方法可能無助於解決實際碰上的難題。

例如有位一路走來的 SA，留言提到他很怕遇到一種人，這種人會主張把系統設計得簡單點，但大多數卻習慣先把使用者需求簡化或忽略困難的部分。結果使得系統在後面的開發變得愈來愈困難，或是使得系統效率不彰。

還有一位訪客提到，台灣中小企業老闆普遍的觀念是「資訊系統應該是要配合他的需求而開發，而不是為了配合系統來改變公司」三不五時會表現出他們的官大學問大。遇到這些情境，系統分析師該相信誰的專業呢？

筆者相信以上是許多系統分析師經常碰到的問題。在軟體開發過程中，不同角色的意見常常是分歧的。如果系統分析師無法適時、有效地處理這些衝突，根本就很難施展出可以解決問題的專業。那麼系統分析師該如何有效處理軟體開發過程不同角色的歧見所產生的衝突呢？筆者認為解決衝突的關鍵不在系統分析師的設計才華、或是技術能力如何，也不在他所懂的領域知識有多少。

雖然這些能力確實在軟體開發過程中非常重要，但如果忽略了結構與非結構的隔閡，那麼即使擁有上述才華、能力與知識還是沒有辦法把心思放在對的問題上，而無法發展出適當的解決方案。

筆者曾在〈系統分析專業的七種能力〉提出系統分析師該如何思考與學習的方法以展現其專業。然而，從〈怎樣才是專業的 SA？〉的留言卻可以發現，許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」，使得系統分析師陷入了過度簡化設計與過度工程化，也就是所謂過度設計的兩難情境。

簡單設計並不容易

在觀念上，很多人都知道要把系統設計得簡單點，但實務上設計要做得簡單卻非易事。誠如那位一路走來的 SA 讀者所言的，許多主張把系統設計得簡單點的想法，最後多半變成簡化使用者需求或忽略困難的部分，使得後續開發或系統效能遭遇到瓶頸。

筆者很能夠體會他對主張把系統設計得簡單點的恐懼，事實上，筆者經常看見許多一開始強調設計簡單，到最後卻因為沒辦法適應變化而得修改或重寫，如果上述改變又牽動到系統架構，那更是使得問題變得更複雜。由此可知，簡單設計並不容易，簡化使用者需求或是忽略困難部分的設計，不能算是簡單的設計，而是過度簡化的設計。

筆者認為簡單設計代表設計的簡明與單純，簡明是指設計概念清晰，使人容易理解，同時也是讓系統分析師用來發現，有效解決問題的一致性概念。至於單純則是採用直接而純粹的實作，以避免不必要的複雜度，集中心力解決最重要的問題，不把時間浪費在無關緊要的事情上。

只有做到設計的簡明與單純，才不會因為無法善用設計的彈性來突破系統的限制，或是為了沒有必要的彈性而增添無謂的複雜度，否則將會使開發過程碰到困難甚至是失去控制。簡明和單純就如同天平的兩端，讓問題領域的重視變化與解決方案領域的強調秩序能夠相互激發出智慧的火花，形成穩定的動態平衡，而不是讓一端牽就另一端。

很多系統分析師習慣地以「做的事情很簡單」視作簡單設計的認定標準，大概是因為基於設計解決方案的思考慣性，加上受到「簡單」的刻板印象。

殊不知簡單設計必須以解決問題為前提，忽略或過度簡化問題所做的設計，通常是無法滿足問題領域的現實需要。這種迷思特別是在導入新技術或開發方法時更容易看見。以為新工具或方法會讓開發過程變得更簡單而更有效率，結果反而卻為了遷就新技術或方法，使簡單的問題複雜化。

其實筆者並不是要否定新技術的價值，只是認為簡單設計的關鍵並不在技術、工具或是方法論，而是更需要思考與實踐的紀律，用來跨越結構與非結構的隔閡。透過思考，系統分析師才能弄清楚系統的最主要問題，知道如何將設計變得更簡單；而唯有實踐，才能驗證自己的想法是否正確而且能對解決問題產生效果，以力圖設計的完善。

「本質」的誘惑

雖然說系統分析師需要紀律以思考問題、以及實踐解決方案，但實際上要做到真的很不容易。筆者從實務的觀察中發現，很多系統分析師在設計過程中，都很容易受到本質的誘惑而更加深了結構與非結構的隔閡。

所謂的本質是指不管環境如何改變，但仍然會有不受環境變化衝擊的觀念或方法。筆者並非否定設計本質的價值，只是覺得「本質」這個詞很容易讓人們陷入迷惘。設計能力愈強、或是經驗愈豐害的人，愈容易受到本質的誘惑而迷失方向；一旦你愈堅持你所相信的設計本質，你就會愈容易忽視思考問題的存在。

在軟體設計社群裡，「本質」是個很容易被濫用的名詞，筆者認為系統分析師應該要謹慎地看待這個名詞，以免受到它的誤導而弄錯問題。筆者曾經在 plurk 看到生魚片提到，從 OO 的本質下手的心得，指出搭配重構與設計樣式再行體會，讓他更認識 OO 是什麼。我當時則提醒他當心設計本質很容易讓人弄錯真正存在的問題。

對於我回應生魚片的看法，cloudy 提出他的觀點。他認為設計本質是不會變的，只是在不同問題領域中，設計概念的資料與行為會有所增減。筆者倒是認為問題的存在會決定事物本質的不同，例如訂貨系統中的車子、與租車系統中的車子，在設計上是屬於完全不相同的概念。前者是達成交易的商品，而後者則是用來提供服務以收取租金的生財器具，真正販售的商品是租車服務而非車子本身。

如果同樣以「交易為中心」的設計模型，都存在這種本質的差異，那麼對於其它無法用交易解決的問題領域，更是難以讓系統分析師找到不會因為環境改變而受到影響的設計本質。因為，當存在的問題不同之時，對相同的事物會產生完全不同的意義。換句話說，設計本質並非固定不變的，而是因應系統所要解決的問題而改變。

其實，筆者也很難避免受到本質的誘惑，以自己過去開發過的銀行影像系統為例，一開始按照自己設計的經驗來建立設計模型，很自然地會將資料進行正規化的處理，對影像文件擷取交易的設計觀點。

但問題是這個系統與以往的專案最大的不同是，它並不需要處理交易的部分，而是由工作流程系統處理交易完成後，再通知影像系統以進行影像資料的存取。隨著使用者需求的變化，調整功能時卻發現交易的設計反而讓問題變得很複雜。這時才發現，以交易為主的設計本質並不適用於這個系統，而是重點在於如何讓使用者建立查詢檢索條件，方便讓他們找到需要的資料。

交易在此系統並不代表交易事件實際的發生（有沒有發生對此系統並不重要），而只是代表影像查詢或檢索的某一種條件限制而已。由此可知，想要找到對系統真正有用的設計觀點，並非針對事物的真實情況（本質）來建模，而是因應事物在問題領域中所表現的價值或意義（存在）來建模。

筆者認為，系統分析師應抱持開放的心胸，體認到軟體設計本質的未定論；存在並非由固定不變的本質來所彰顯，而是藉由創造本質的過程來體驗問題的存在，設計其實是「本來無一物，何須染塵埃」。

學而不思則惘，思而不學則殆

開發本質的不同常會導致設計爭論，例如強調以資料與程序為本質的論點，經常會批評用物件導向開發的設計典範。主要批評物件導向要寫更多的程式難以管理、以及開發出來的系統運作效率太差等弊病。

當然，某些以物件導向開發的系統確實會出現以上的問題，但如果改成程序導向的開發方法就沒有問題了嗎？顯然這樣的想法是忽略了「沉默的證據」^[2]之存在，沒有人用不同的開發方法開發同一個系統，所以我們很難確知在某一個專案裡，用程序導向開發是否不會出現更為棘手的問題。

從相反的角度去思考，強調物件封裝、抽象化、繼承就是軟體設計的本質嗎？這些原則是為了降低複雜度，增加元件的彈性與再用性而產生的。不過，如果這些設計原則找不到具體可以解決問題的實踐方式，那它們就毫無用處，只能代表系統分析師還體會不到設計的本質；這個時候，他想解決的問題多半並不是系統真正的問題，所以未來必將付出為了沒有必要的彈性而增加複雜度、以及系統效率不彰等代價。

由此可知，設計典範沒有優劣的問題，我們也很難找到可以因應在各種狀況下最棒的設計，只有是否正視問題而發展出適合的設計。

沒有放諸四海皆準的開發方法，所以系統分析師不該以為他相信的設計本質可以解決所有問題，而是應該開放自己的心胸，停下來思考自己可能忽略的問題，並且與跨領域的知識進行交流與學習，以期將所知學及所知進行組合與內化。

如此一來，代表結構與非結構的兩種領域，將不會因為扞格而產生格格不入的衝突。總之，系統分析師應該調和問題領域的知識與技術領域的應用，使其達成穩定的動態平衡，再加上「系統分析專業的七種能力」，那麼系統分析的工作必然會勝任愉快。

1. 周宣光譯，2000，《管理資訊系統－網路化企業中的組織與科技》，東華書局。
2. 林茂昌譯，2008，《黑天鵝事件》，大塊文化。

某同事甲指著一道菜，跟負責點菜的同事乙說：下次就別再點這道菜了。他說那道菜的肉，咬下去裡面是白的，顯見豬肉並沒有先醃過，吃起來就不夠味。這時候，有些同事表示認同，紛紛也附和同事甲的意見來評論這道菜。

同人對同事甲的看法沒有什麼意見，因為說實在的，我也吃不出這道菜有什麼不好。不過，如果精於美食的同事甲說得是正確的，那麼就代表這家店的這道菜品質有問題。於是我說：這其實代表他們 QA 沒做好。

這時候，大家好奇的眼光看著同事丙，也就是公司 QA Leader。他說 QA 沒有辦法提昇產品的品質，它只能確保有問題的產品不會送到客戶的手中。

顯然同事丙和同人對 QA 的定義有顯著的不同，他所說的 QA 是針對產品本身的控制流程，而非針對產出保證產品品質的執行過程，我認為那是 QC 而非 QA。但同人並不想挑戰對方對 QA 的定義，以免把吃飯的氣氛弄得太嚴肅，於是我用另一種方式來表達我的觀點：

我的意思是作這道菜的流程出了問題，導致產出無法符合顧客對品質的要求。所以他們應該設法改善這道菜的製作流程，讓它更完整並且可以符合客戶的需求。

終於，同事丙沒有再質疑同人的說法。不過，這也讓人看到一個現象，就是在台灣，品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外，以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」，讓開發人員認為品質是品質部門的責任，而品質部門則認為提昇品質不是他們的責任，以為最多只能做到知道產品有問題，而不知道如何改善它們，只能退回到開發人員那邊來解決。

在一個重視品質文化的公司，QA 人員對產品的意見當然可以擲地有聲，善盡到品質管制的責任。然而，在台灣軟體開發的環境，尤其是大部分以專案型態的軟體開發，品質往往是時間或成本不足第一個被犧牲的對象。同人想到我過去在一個大型政府公共建設委外 BOT 專案中，因為業主對文件要求嚴格，使開發團隊要花費相當多的心力來寫文件。想不到上層負責監督的 VP 卻說：沒有時間，品質目標只要設定為達到 30% 就夠了。

同人很清楚那位 VP 的說法是不會 work 的，因為品質不能妥協，否則你必將付出更大的代價。果然那個因為延誤而讓公司損失慘重的專案，在我離開那個專案兩三年後才勉強結案驗收。不幸地，這種不重視品質文化的開發方式，在今天卻還在台灣各地持續上演之中。

因此，與其將品質寄望在強大的 QA 人員或嚴謹的品質流程，還不如在開發過程中織入品質的面向，形成品質保證的全像圖。高品質是全員參與的必然結果，在分析、設計過程就加入如何提昇品質的思維，以達到符合顧客的需求，並且創造他們的價值，這便是執行所謂的 QA，也就是真正的品質保證。

當然，能夠為客戶創造價值的品質流程並非絕對的，就像負責點菜的同事乙後來表示，她不覺得那道菜難吃呀。其實同人也覺得那道菜也還好，品質和你的客戶是誰有很大的關係，事實上，並不是每一個人都對吃很講究，所以那道菜的品質，其實是因人而異呀。

後記：

本篇文章已刊登於 ZDNet Taiwan 部落格文章專區。