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

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

設計不夠好？

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

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

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

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

管理的重要性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今(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 部落格文章專區。

繼「新官上任三把火」之後，馬政府團隊又在國慶大典發生意外狀況。位置安排出問題、加上安檢嚴格，引發部分參加大典的民眾不滿。例如資深藝人和僑胞發生搶位置狀況，還有一對位置被佔走的僑胞夫婦，居然還被工作人員趕出場外，真是又委屈又生氣。

看到這則新聞，筆者關心的並不是主辦單位碰到這些意外狀況該怎麼辦，而是好奇為什麼座位安排的問題會重覆發生？其實像座位安排並不是什麼困難的問題，不需要動用複雜的技術，只要用簡單的 Excel 試算表就不會有太大的問題。

如此看來，座位重覆的問題不太可能是技術的問題，筆者看到相同的錯誤一再發生，我會懷疑問題不是出在技術上，而是因為管理的關係，使得團隊一再出現相同樣的行為模式造成錯誤。

可能是因為領導者的領導能力不足，使得團隊成員的能力處處受限而無法施展。如果真是如此，那麼與其討論技術細節，還不如討論該如何領導讓團隊充分發揮能力。因為，就算今天我們知道如何可以解決座位安排出現錯誤的問題，領導能力不足，明天團隊還是很有可能在別的地方出現錯誤，造成其它的意外狀況發生。

筆者相信不管是那一種專案，管理上的領導能力不足都會造成相同的錯誤一再發生。就像筆者在軟體專案中所觀察到的情況一樣，專案經理的領導能力不足，使得團隊成員把精力浪費在沒有意義的事情上，以致於對專案目標的達成並無太大的助益。

當然我們並不能否認，團隊成員的能力出現了問題，或是他們不夠盡力，也可能會出現同樣的現象。不過，根據筆者多年軟體專案開發的經驗顯示，團隊成員能力不足或是其心態有問題的情況並不多見，多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時，專案經理應該先思考是不是自己的領導能力出了問題。

依法，或是依人？

筆者從觀察發現，很多團隊領導者認為，只要讓團隊遵循良好的制度、方法，就可以提昇團隊的工作效率與成員素質。因而在團隊制度化與標準化作業流程的導入上，付出相當大的心力，並要求團隊成員用「專業」的方法來解決問題。

表面上，上述提到的標準化與制度化的「專業」看起來似乎不錯，可以讓重複、瑣碎或不重要的工作予以簡化或剔除以增進工作的效率。但就如同筆者在〈新官上任三把火〉這篇文章中所提到的，制度化除了會讓工作更加艱難、人們不願冒險以獲取高利潤之外，更嚴重的還會讓團隊成員依賴制度化而使得思考僵化，降低了運用思考創意解決問題的可能性。

為什麼會這樣呢？如同筆者一再所強調的，專案本身具有臨時性與特殊性的特質，必須視專案實際環境來調整開發方法與流程，也就是我們通常找不到「放諸四海皆準」的開發方法來一體適用所有的專案，用來事先難以預料的各種問題。

其實「依法不依人」並不是不可行，而是受限於專案現實環境與限制，根本不允許團隊規劃出適用於各種專案情況的最佳開發方法，就算團隊真能規劃出這樣的方法，專案可能會更需要能力更強的團隊來執行這樣的方法。而且，用組織制度來取代成員的思考與創造力，那更是促成團隊「自廢武功」的領導作為，而最後只會把事情弄得更加難以收拾。

必要多樣性法則

因此，「制度是死的，人是活的」專案的問題通常很複雜，團隊領導者不應該用僵化的制度來限制團隊成員的思考與創意，而是應該將重點放在人身上，而方法、制度、與規範只是站在支援與輔助的角色，而不能用來限制團隊成員的行為，如此團隊成員的思考與創意才能透過流程方法的幫助而獲得到加成的效果。

如果團隊領導者想要做到依人，讓團隊成員充分發揮專長，那麼他必須能夠做到充分授權；讓他們感到自己是團隊的一份子，才會願意主動提出建言，以作為團隊領導者決策的參考。不過實際上，這對團隊領導者而言，這卻是個艱鉅的任務。

因為對於複雜專案而言，團隊通常會具有多樣性的特質，要讓背景、專長、以及文化有顯著差異的成員採取一致的步調，這對專案經理來說其實是相當大的挑戰。但如果團隊領導者沒辦法整合各種不同的意見，將會引發團隊衝突而衝擊專案績效。

正如同《專案領導》這本書中提到的觀念，James P. Lewis提到用「必要多樣性法則」來解釋專案經理需要具備足夠的彈性與靈活度才能掌控團隊。所謂的「必要多樣性法則」是指在任何人類或機械系統中，彈性最大的份子會控制整個系統。換句話說，領導者對團隊所做的行為，必須比整體行為的多樣性還要更靈活、更有彈性，否則他將難以掌控團隊。

但實際上，領導者很難具備足夠的靈活度與彈性來掌控團隊的行為，因為每個人都會受限於根深柢固的行為模式而難以改變。所以，最好的做法就是降低團隊的多樣性，這可藉由制定規則與法令來規範團隊成員的行為而達到目的。

不過，對於不認同團隊規範的成員而言，再多的規則也是英雄無用武之地；所謂「上有政策，下有對策」他們必然會想盡辦法來規避規範。因此，James 認為降低團隊多樣性應該要制定完善的專案計劃，找出團隊成員的共同目標，然後必須考量團隊成員的個人因素，並且邀請負責執行計劃的人參與計劃的制定，才能訂出大家都能認同的專案計劃。

團隊領導者的力量

不過，雖然專案計劃是專案管理的「根本大法」，其中的願景與目標可以讓團隊的多樣性自然而然地降低，以減輕領導專案的困難度。然而，如果團隊領導者卻無法有效地影響團隊成員為專案努力貢獻心力，仍然還是很難有效地帶領團隊達到專案目標。

尤其是像軟體專案這種充滿不確定性的複雜專案而言，常會面臨企業環境變化的衝擊，加上問題領域與各種資訊技術領域整合常會產生新問題，當「計劃總是趕不上變化」時，團隊領導者除了專案計劃的「法」之外，還必須懂得如何讓團隊成員心甘情願地為專案付出心力的領導「術」，這樣才能勝任專案領導的任務。

換句話說，團隊領導者必須擁有影響團隊成員改變的力量，但如何才能得到這樣的力量呢？或許有些人會認為團隊領導者的力量來自於專案開發組織賦予權力與資源，但實際上，權力或資源並不見得能夠賦予足以領導團隊的力量。

筆者的一位老師曾經說過：「強將手下無弱兵，但強將手底下，也不會有強將」有能力的人並不懼怕領導者的權威，他不會因為恐懼而聽從領導者的指揮；至於能力不足的專案成員，雖然他會依賴或屈從領導者的指令行事，但唯唯諾諾聽命行事的結果，很難能夠期待他們能夠發揮創造力與獨立思考的能力。

關於領導者的力量，溫伯格在《領導的技術》中提到「力量是一種關係」的觀點，他認為力量奠基於團隊領導者與團隊成員之間的關係，權力、技術或是專業是否能為團隊領導者產生力量，完全視團隊成員認為這些事物對他們是否重要而定。

由此可知，所謂專案的範疇、時間、成本、品質、風險等硬技術，不見得能夠為團隊領導者產生力量，如果團隊領導者想要提昇領導能力，應該增進與團隊成員的關係。所以他應該在溝通、協調、衝突管理等軟技術上多下功夫，才能讓自己的領導能力有所提昇。

筆者常在實際的專案開發的工作中，看到一些在過去表現不凡的團隊領導者，卻在另一個組織高層予以托負重任的專案中失敗了。就像有一位專案領導者，曾經在某一個甲專案中為公司立下大功，深受客戶好評並得到公司的獎勵。但他卻在一個公司傾全力挹注資源的乙專案中失敗了，使得陣前換將讓別人來接收他的爛攤子。

很多人會覺得很奇怪，為什麼這位專案領導者不能接續過去在其它專案的優異表現，在新的專案中，領導團隊邁向成功呢？問題就出在許多專案領導者都以為過去的成功模式可以確保專案成功，但卻忽略了他們熟悉的成功模式不見得會滿足新專案的成功條件。

組織所賦予的權力或資源，或是領導者過去所知的經驗、專業、或是技術不見得會為領導者產生足以影響團隊的力量，除非團隊成員認同這些東西對他們的重要性。

如果專案經理不去關心團隊成員、也就不會瞭解他們需要什麼，自然也就難以激勵屬下貢獻所長，以達成專案目標。相信實際從事軟體開發工作的人都能理解，工程師不求名、不求利，只求爽。想要讓他們戮力求取專案成功，考驗著專案經理的領導能力。

有一位專案計劃主持人曾經沾沾自喜地告訴我，他認為某個專案能夠成功，是因為他鼓勵大家犧牲假期加班的結果。但其它瞭解專案狀況的多數團隊成員都知道，專案能夠成功是因為另外一位專案經理以柔軟身段，進行溝通與協調的結果。他並不會要求團隊成員依規定辦事，而是理解並接納團隊成員，才能激勵大家共同面對難關而解決問題。

因此，力量的決定關鍵在領導者掌握與團隊成員的關係的緊密性，而非技術或專業能力、權力的大小或掌握資源的多寡。換句話說，領導者要具備柔軟的身段與協調能力才能把團隊帶到專案成功的境地。

於是我們可以說，領導者要有效的領導團隊，必須先贏得團隊成員信任，才會讓他們願意為專案的共同目標而努力。再加上適時適地的激勵團隊成員，以激發團隊的熱情，以及增進團隊成員榮辱與共的參與感。讓每一個團隊成員都能為專案成功而努力，同時也讓他們的能力，能夠從做中學的過程中得到啟發與成長。

以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。

為什麼程式語言一直再改變是個迷思？那篇文章就有讀者質疑這個迷思，他說：

關於這部份，我覺得不如講＂只有XXX語言才能作某件事情＂
我不覺得＂程式語言的改變＂是迷思

不過，同人認為所謂「程式語言一直在改變」的迷思，作者的意思不單單只是說程式語言沒有一直在改變的意思，而是還有更深層的涵義沒有表達出來。事實上，程式語言一直再改變是個事實，我們不該說它們沒有一直改變。而是這些改變並不會讓我們先前對程式語言學習的投資白費。

同人認為，作者提到「電腦程式語言的演進，就像人類的語言演進一樣，有其一定的過程」是正確的。但對程式語言的學習而言，重點並不在於「程式語言不會一直在改變」，而是在於改變通常不會影響程式語言舊版本的語法，就算存在一些新舊版本不相容的影響，但只要掌握基本觀念，新的改變是不需要重新學起，而且我們經常還能在不同的程式語言之間，發現彼此相通的地方。

其實程式語言會不斷演化是必然的，「成熟」的程式語言反而是象徵衰退的開始。因為隨著時代的進步，程式設計的問題只會愈變愈複雜，造就了新的程式設計概念。如果程式語言太成熟，以致無法改變來加入新的程式設計概念，那麼它們將被時代所淘汰。所以，問題不在於程式語言是不是臻於成熟，因為改變是必然的，重點在於你投資在程式語言的學習並不會白費。

再來，作者提到「千萬不要認為電腦已經跑得很快了，就不注意演算方法的選擇。」同人認為是正確的。但他舉例指出遞迴函式效率較不佳、比非遞迴寫法的程式容易做重複計算，建議大家儘量避免用非遞迴的寫法來進行程式寫作的說法，同人就完全不能夠認同作者的看法。

沒有錯，遞迴函式的確比非遞迴的寫法會佔去更多的記憶體，但以空間換取時間的角度來看，說遞迴函式比非遞迴寫法更沒有效率，則是過份簡化的說法。即使以作者舉計算費式數列的遞迴函式的例子來看，遞迴函數可能有重複計算的問題，但到底費式數列的 n 值要多大，遞迴函數的執行速度才會發生顯著的影響，這卻是值得探討的問題。

如果在一般解決領域問題的條件限制上，都不見某種演算法的缺點，會產生顯著的影響，但卻能享受到該種演算法的優點，那麼我們是不是應該選用這樣的演算法來設計程式呢？答案想必是肯定的。這不是把問題推到硬體速度夠不夠快的問題，而是演算法的選擇應該透過客觀的分析與理性的思考，才能找到最適當的選擇。

這讓人也發現到程式設計常見的迷思，很容易誤導我們對程式開發的看法；太過相信經驗法則而缺乏對問題的深入思考，容易人云亦云地以為該用什麼演算法或避免什麼演算法，而那些都是程式設計師自以為是的偏見。

我想到哈米尼斯對同人分享永續物件設計所提出的意見，他提到：

就現實問題而言，一家公司裡，可能許多套系統都是由不同的廠商開發，若以這樣的角度來看，這一個架構似乎有點問題。

再來則是效能考量的問題，我認同這一個架構下，可以讓開發和維護變得簡潔，但若是遇到某些特定的系統，如下單系統，它強調的重點會在反應時間及大量資料處理，若是以此為考量，這樣的架構似乎又繞了太多層？

哈米尼斯的意見正是同人在工作上常面臨的質疑，但實際上我所提出來的設計是經過驗證過的架構，運用服務導向的觀念、以及物件導向設計的設計手法，已成功整合銀行各種不同廠商開發的子系統。它實際應用在銀行的付款系統，所以對績效的要求是非常嚴苛的，然而實際上它的效能卻未見如哈米尼斯所顧慮到的問題。

受限於自己的經驗，很多程式設計師傾向於認定太多「系統間接層」不好，但那只是一己想法，而未經證實的猜測。如果真的擔心發生這樣的問題，應該採取行動進行驗證，而不是停留在想法的猜測，這才是程式設計者應有的積極態度。

事實上，間接層的設計只是把原來放在一起的程式碼區分好責任，去掉重覆性而已，我們對系統繞太多層的理解不一定是系統運作的真相。除非我們做了設計概念驗證，讓事實或數據說話，而不是經驗的推論，後者往往來自於個人徧見所致。

同人無意在這裡討論那一種程式開發典範比較好，因為那是不會有結果的爭論，只有在了解程式想要解決的問題之後，討論用什麼方式來開發程式才會有意義。

演算法的選擇也是同樣的道理，每一種演算法都有它的優缺點，我們應當針對問題的目標與限制來「思考」最適當的演算法，而非慣性地「記憶」那一種方法用在每一種情況都比較好、或比較不好。因此作者建議儘量避免用非遞迴的寫法，進行程式的開發，同人對此實在是感到不能認同。

更何況透過思考，遞迴函式重覆計算的問題並不難解決。例如我們可以在遞迴函數中，將已經計算過的數列項次值儲存下來，當過程中發現某個項次已經計算過了，我們可直接取值而避免再計算一次，這樣就可以增進遞迴函式的執行效能。而運用程式設計者的智慧，遞迴耗費大量記憶空間的限制，也並非不能克服。

同人一位朋友就分享他在繪圖程式設計的經驗，他曾改進過填色的遞迴函式。原來一個點向四面擴散填滿顏色要用到大量的遞迴空間，但只要改變以線或區域為單位向四面擴散，就能大幅減少填色所需之遞迴空間，克服遞迴函式的先天限制。

所以問題並不是遞迴可不可以用，而是程式設計者懂不懂得用思考來創新設計技巧；不懂得在解決問題上尋求挑戰與突破，那才是讓程式設計能力停滯不前的最可怕迷思呀。

例如同人過去在〈畫龍要點晴〉中，就指出兩篇很有價值的文章，因為缺少了「概括性論點」而使文章失色不少，讓人覺得非常可惜。今天，我在 ZDNet 的名家專欄中，又看到〈必須面對的真相─五大程式設計迷思〉也同樣少了「概括性論點」，讓人覺得該篇文章不知要表達什麼重點。同人從空洞的論點背後，看到作者的思考似乎還沒有完成。

為什麼同人這麼說呢？我們看到這篇文章的主題是「必須面對的真相」，但文章並沒有指出作者想要訴求的讀者對象是誰。即使從文章內容看來，這篇文章似乎是要寫給程式設計的初學者看，但仍舊沒有告訴我們這些必須面對的真相，其背後真正的目的或代表的意義。

只告訴我們有五大程式迷思，這令人很難了解這「五大迷思」為什麼要擺在一起，因為有人可能會問，程式設計只有這五大迷思嗎？讀者並不能知道不會有第六、甚至第七大迷思了，因為我們對於作者要誰來面對這些迷思、為什麼要面對這些迷思無一知悉。

顯然這篇文章只告訴我們「一些迷思」，卻不知道這些迷思為什麼要放一起。根據明托女士的「金字塔原理」，這樣文章無法形成 MECE，也就是「全無遺漏、互相補充」的結構。

文章以「迷思」，將這五項要點關聯在一起，但「迷思」本身卻是相當空泛的概念，不夠具體了解這五項要點關聯在一起的原因。如果作者能再進一步思考列舉要點的具體關係，指出彼此的相依性，他應該就能發現被它忽略的概括性論點，讀者也比較容易知道他在說什麼。

從一些讀者留言無情的批判可知，不少人認為這篇文章的內容不夠深入，但如果作者在文章結構上，力求「概括性論點」的思考以呈現其觀點的脈絡的話，相信就會讀者看到更有意義而深入的內容，這樣的文章也才不會只是表達作者「所知道的東西」，而是透過探索、思維、及內化出這些知識所產生的「體會與啟發」，這才是文章的真正重點精華所在。

它們與文章內容沒什麼關係，卻混淆文章訴求的重點，而大部分這種留言多半是匿名者的批評。回應這樣的留言很辛苦，但為了清楚表達自己的想法，過去同人還是會設法回應這些留言。

然而，最近看到同人在 ZDNet 發表的文章，又出現了與文章主題無關的匿名者批評。我突然發現自己不想再浪費青春在那上面，於是表達無法和匿名者討論下去的想法，結果匿名者居然回應了下面這一段話：

你想針對人討論嗎？還是想針對內容討論？如果是人，那就可以免了。既然留下名字，也不見的是本人，那為什麼那麼在乎是誰？

同人不想和匿名者討論就是在乎說話的是誰、是對人不對事嗎？非也，問題並不是我們在意留言者的姓名，而是躲在匿名後面隨便放話，顯露出對他人的不尊重，我們當然不需要浪費時間，與匿名者做沒有意義的爭論。

再和匿名者扯下去，討論的失焦勢必沒完沒了，因此，對他的質疑同人也不必要去加以反駁。因為接下來可能會進行辯論「他沒有不尊重他人」、「尊重他人不需要留下名號」等諸如此類的問題。這些問題跟文章更加無關，所以沒有必要配合他演出失焦及離題的戲碼。

然而，為什麼同人會認為在匿名後面隨便放話，就是不尊重作者呢？這可從匿名留言者、留言內容、及個人成長三方面來看。

對匿名留言者而言

匿名留言者不能對他的留言負責，因為我們不知道留言者是誰，總不能像《哈利波特》的故事所說的一樣，用「那個人」來代表隱藏在暗處的佛地魔吧！

雖然在羅琳筆下的故事中，人們是因為心生畏懼，而不敢直呼魔王的名字，但在真實世界中，匿名者不願意留下名號的可能原因之一，是不想讓別人發現他的行蹤。這對用匿名來進行批評的人而言，實在是和躲在暗處的魔王很像，隱藏自己以用來打擊敵人或使人難堪。

匿名者不願意留下名號可能還有另一個原因，就是嫌留下名號很麻煩。但留言如果連個最起碼識別留言者的標誌都不願意留下，匿名者說的話又有幾分可信度可言呢？更何況，對文章作者、或是其他具名留言者的批評、甚至是攻訐，匿名留言者可是不需要負任何責任。

因為從留言的互動，我們並不能知道正在和那個特定的對象在討論，而是跟不知那位不能對留言負責的「任何人」在爭辯，這樣的過程又有何意義可言呢？

對留言內容而言

匿名留言的內容多半是扭曲他人論點、或混淆焦點的言論，讓人很難就事論事。同人想到曾維瑜的觀察，躲在暱稱背後批評人的實情是這樣子的：

躲在暱稱後面批評人的人，很少是認真看過、看完你寫的東西的，

躲在暱稱後面批評人的人，很少是努力想要去看懂你的觀點的，

躲在暱稱後面批評人的人，通常口吻都帶著酸味（真不知道是為什麼），

這些人很少能夠清楚直接說出自己的想法，他往往只是把你這個人胡亂罵一頓而已，

注意喔，他甚至不是想談你的觀點，他只是想羞辱你這個人本身而已。

最有趣的是，躲在暱稱後面批評人的人，這個舉動於他，其實沒有太大意義，

他可能也不記得自己什麼時候在什麼地方用什麼暱稱對什麼人，說了什麼話。

當然，曾維瑜是指那些常常變換暱稱的人，但如果常換暱稱發言是這樣，那連暱稱都不留的言論想必更沒有什麼參考價值了。

依據同人回應匿名留言的經驗，匿名者很少有人是要就事論事，就文章的主題進行理性的討論。他們多半只是要找機會來證明比你更行，辯論的目的只是想要讓你難堪而非知識的討論與交流。

然而喋喋不休的背後，讓你看到的卻是看到三兩句話疊來疊去，看不到什麼重點。然而，就算你的指出對方邏輯或觀念的謬誤，他們也只會用沒有根據的言論來掩飾自己的錯誤， 真理是不會愈辯愈明呀。

對個人成長而言

同人不否認匿名留言還是會帶給個人一些成長，例如我可以改進引言的部分，用直接而清楚的詮釋引言，以降低讀者對文章主題誤解的機會。然而，看到匿名留言不斷地以觀念偷換來對文章的觀點進行扭曲，讓人覺得已經沒有討論下去的必要了。

澄清文章的觀點，是身為作者的責任，但對於沒有認真閱讀或是不願意弄懂我文章觀點的讀者而言，我是不用浪費時間與他們多費唇舌的。相同的時間，我應該用來回應其他更有建設性的意見，它們是很少是需要躲在匿名背後發言的。因為不懂尊重的人，我們很難期待他會有什麼建設性的見解。

因此，基於上述這三大原因，對於隱藏在匿名、或奇怪的暱稱後面，刻意扭曲文章觀點、或進行離題辯論意圖的批評者，同人還需要理會它們嗎？子曰：「可與言而不與之言，失人；不可與言而與言，失言。知者不失人，亦不失言。」實在是沒有必要為不尊重別人的不禮貌發言而失人呀！

專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化，變化總是比不上老闆的一句話」之時，許多專案經理總是會擔心專案無法如期完成或害怕資源不足，而拒絕或延後專案變更的要求。但這樣的行為，卻往往造成工作成果無法符合專案實際需要的結構性因素，而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言，當然並不會樂見專案發生這樣的事情。

筆者前一陣子看到喲哪桑在〈換了屁股，我也換了腦袋〉的分享，提到他在時間緊迫的情形下，接受了專案的功能變更要求。那個變更要求原來是由他所提出，當時前任專案經理以時程緊迫為由而答應延後處理，而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生，於是決定不要再讓這個專案變更要求再次拖延下去，並在當下對專案進行變更。

筆者認為喲哪桑的作為令人激賞，並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定，而是欣賞他在決策過程中，展現出面對自己的勇氣與解決問題的思考。不過，卻有其他讀者對那篇文章抱持相反的意見。

某位網友對喲哪桑的分享，批評他是靠感情衝動來管理專案，甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念，實在有不可思議的謬誤，並且擔心那篇文章會透過 ZDNet 的報導，將不正確的知識與觀念誤導一般社會大眾。

然而，他對這篇文章的批評卻使人感到困惑，那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤，但看在專業人士眼裡，這樣的觀點又何嘗不是相當嚴重的偏頗呢？筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感，進而對改變的抗拒而產生無知的迷惘。

專案變更的基本原則

身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中，但在對專案缺乏可供客觀評論資訊的情況下，只憑專案經理接受專案變更的決定，就加以批判其決策感情衝動是否真的恰當？專案管理並不是神學或是玄學，而是屬於管理科學的範疇。因此，如果有人要批評某個專案經理是用感情衝動來管理專案，必須提出具體的事實根據，否則那只是無憑無據的推論而已，而這樣的推論多半只是源自於自我的偏見與扭曲。

以專案變更管理的原則來看，依據《PMBOK》的說明，專案經理在管理專案變更的時候，必須注意三件事。首先他必須確定變更對專案的影響有其正面的價值；其次，他必須確認造成專案變更的因素已經發生；最後，他必須對變更加以管理。

從以上的原則我們可以發現，專案經理決定接不接受專案變更的要求，不應該源自於個人的主觀認定，而是必須經過客觀的評估。只有在蒐集了專案變更的各種相關資料，並加以評估之後，我們才能確知在專案現狀下，變更的正面效益或負面影響為何、到底值不值得立即採取行動來進行變更。而在未經評估之前，沒有人可以作出專案是否應該接受、拒絕或延後變更要求的決定。

喲哪桑的文章並沒有提到他所進行的專案變更並未經過事前的評估。相反地，他在對該位網友情緒漫罵性的言辭感到莫明其妙的文章中提到，在部落格發表的文章中，他不能揭露太多工作細節，並且提到了在重提該項專案功能變更要求之前，提出者已經評估過變更對專案的影響。因此，依據我們可以觀察到的事實來看，認為喲哪桑用感情衝動來管理專案，本來就是沒有根據的偏見。

個人信仰的偏見

既然沒有證據可以證明喲哪桑在未經事先評估的情形下，就逕行進行專案變更，那麼為什麼那位網友卻堅稱喲哪桑是用「感情衝動」來管理專案，並且說他並不適任專案經理的工作該離開呢？他提到每個人相信自己所相信的，本來就是人生信仰的一環。而他的信仰是「PM 不該因為個人情感的因素等非理智的理由，而貿然做出提升專案風險的決策」，因此根據這樣的信仰，他認為貿然接受了專案變更要求會增加專案的風險，這只是出於一時的感情衝動。

如果以上的理由是可以成立的，那麼一個人的確不應該用個人情感因素，來進行非理性的決策。但當我們真的這樣說時，我們卻忽略了這句話在邏輯上將會出現必然的謬誤；個人信仰本身也是出自個人情感因素，那麼為什麼別人的情感不理智，而我們的情感卻是理智了呢？

這種出自個人信仰的偏見，正讓我想到在〈新官上任三把火〉與對不同軟體文化的情緒化貶抑正有著異曲同工之妙：

如果主導改革者的心態不是基於解決問題或客戶要求，而是基於自己情感的訴求，所謂的改革也只不過為了遂行其願的私心，卻讓專案與團隊成為無辜的陪葬品。

就像上述主導改革者的心態一樣，在專案面臨變更要求的時候，許多專案管理者會傾向用一己的偏好或私心來決定是否接受變更的要求。尤其是他們常會以開發資源不足或進度落後來當做理由，拒絕或延後專案變更的要求，以減輕他們的工作負擔。但如此一來，接受、拒絕或延後專案變更要求卻變成無法理性討論的議題，也很少人可以正視它們對專案所產生正面的助益或負面的影響。

專案風險的迷思

那麼這種無法正視專案變更要求的信仰從何而來呢？依據筆者對許多專案經理的觀察，我發現許多人會為了減輕對未來不確定的恐懼所產生的焦慮，以為不去正視專案變更要求就可以降低風險，但實際上卻反而對專案風險造成迷思。

當專案經理接受專案變更要求時，增加開發工作當然會影響專案時間表，這得確會為專案帶來一些風險。因為如果時間表的最後期限改變，會增加對完工時間與預算的不確定性或衝擊而造成風險、即使最後期限不改變，時間表的調整卻有可能造成要徑（其內的任務一旦延誤，就會影響專案完工日的工作）數增加的風險、或是為了趕工或因為作業重疊、省略品質流程等作業而產生重工率增加的風險等、這些都是接受專案變更可能帶來的風險。

既然接受專案變更要求會增加專案風險，那麼拒絕或延後專案變更要求是否意味著就不會增加風險了呢？當著眼點處於整個專案成敗的高度與視野時，我們將會發現答案是否定的。如同《專案管理之美學》提到的專案應該兼顧並協調各種觀點的平衡，這些觀點包括了技術面、客戶面與營運面。技術開發對於專案很重要，但除此之外，客戶需求與營運策略更是不可偏廢。

換句話說，因為技術觀點而拒絕或延後專案變更要求，很可能會影響客戶的滿意度或信任度、或是因為產品推出時效的問題而影響競爭力，這些風險的影響可能會比技術所造成的風險還來得嚴重而深遠的。

拿過去筆者曾經參與大型軟體專案的例子來說明，那是一個規模數億的政府部門的公共建設 BOT 計劃，包含了十幾個子專案。在各個專案設計開發告一段落的時候，筆者負責與業主及顧問商討該如何制定軟體程式設計規格的標準。

由於我們開發的系統很多，彼此又有相當的差異性，這使得我們在制定出一致性的標準的過程面臨相當大的挑戰。雖然這些問題很複雜，但整合起來其實並不困難，然而真正困難的地方是業主對我們的不信任，經常使得筆者藉著技術專業，很難說服他們可以接受我們的建議。

當時筆者就經常聽到業主對我說：「我當然瞭解你們提到的開發觀念，但問題卻發生在每次你們都說這個問題是什麼時候或什麼人會處理，但最後總是沒有人會處理這樣的問題」這總是令人無言以對，我們對客戶的要求經常拖延與事後相應不理，客戶當然也就學會了對峙之道。結果最後是誰吃虧呢？答案很明顯，即使他們的考績會因此受到影響，但對專案開發組織而言，專案一直遲遲無法驗收的結果，卻是讓我們損失慘重！

應生無所住之心

既然拒絕接受改變的信仰會使我們因為無知，而處在專案風險的迷思當中，那麼身為專案經理對待專案變更要求，到底該不該「換了屁股，也要換了腦袋」呢？筆者認同其他人主張的「換了屁股，也要換了腦袋」說法，但卻想提出一個思考重點。

那就是不管專案經理決定要不要換腦袋，關鍵還是在於他面對問題的本質性思考。所以我認為對於專案經理而言，如何坐在他的位置上並不重要，重要的是他決定怎麼坐上位置之前的思考是什麼。

其實不同立場與觀點的衝突只是提昇其高度及視野的契機，專案經理應該好好利用這樣的機會，去反思為什麼換屁股，就必須換腦袋？或是如何換屁股而不換腦袋？想通了，就會讓自己的思慮變得更成熟而完整，使自己可以勇敢地面對無知而得到智慧。這也就是為什麼筆者會認為喲哪桑的作為令人激賞的主要原因，重點在面對自己的理性，而非對結論的情緒化反應。

筆者很喜歡用《金剛經》的「應生無所住之心」來類比專案管理的智慧，若專案經理太偏重於技術、客戶、業務任何一個觀點，都會造成執著而無法針對問題真相來進行思考，因為我們的心有所染著；但如果為了不去染著任何的觀點，無心讓自己變得冷漠卻也什麼事都做不成。換句話說，專案經理對專案展現熱情是必要的，它將會使得專案經理展現出慈悲與智慧的作為。

慈悲作為需要專案經理的情感，否則無從激勵專案團隊，也就很難產生出良好的專案績效。同時專案經理也必須搭配智慧作為，運用客觀評估與思考能力使得專案範疇、時間、成本等三重限制（triple constraint）能夠達到平衡。

總而言之，專案管理的智慧正是「若菩薩心住於法而行布施，如人入暗，則無所見；若菩薩心不住法而行布施，如人有目，日光明照，見種種色。」的道理，當人們偏執專案特定觀點時，專案問題對於當事者而言，也只是視而不見呀。

新政府能否為台灣開創新局還有待觀察。但從馬蕭辦公室與府院籌辦五二○就職典禮，卻出現許多的問題，加上當天的慶典南北奔波，被稱為有史來最複雜的就職典禮看來；新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。

許多主導專案改變的領導者總是新官上任三把火，認為專案應該要進行改變以展現出自己的決心與魄力，因此要求團隊改變開發流程。然而，專案時間與資源的限制多半很難讓團隊有足夠的時間來調適或熟悉改變後的開發流程，結果總是令專案團隊倍感艱辛。

改革的困難正是考驗著領導者的領導能力，他更需要懂得如何讓團隊發揮創意與執行力來實現改革的目標。領導者應該如何領導團隊來進行成功的改革呢？筆者認為從領導者的價值觀、流程方法的改變、以及團隊的創新文化這三方面來看，我們可以從中體會到專案成功改變的箇中三昧，以助於掌握改革重點，有效地組織資源來幫助團隊實現改革目標。

領導者的價值觀

多數的開發者都希望能夠盡其所能地追求完美，然而，受限於許多因素，他們必須有所取捨。例如，專案時程及資源的限制總是讓他們不可能採用最佳的開發流程來發展解決方案，往往只能針對解決特定問題來選用最適當的開發流程。

因此，主導改變的領導者必須要了解沒有最完美的開發流程，而只有適用於解決某些問題的開發流程。這是領導者必須建立的價值觀，才能確保專案在正確的方向進行改革。

然而，許多領導者希望專案改變開發流程，並不是基於專案的實際需要，而是基於個人在情感上的需要，希望團隊能用更成熟的方式來開發系統。知名的軟體顧問溫伯格卻提醒我們，追求不必要的完美並不是成熟，而是幼稚。他在《溫伯格的軟體管理學：系統化思考（第1卷）》中表示：

正如我們所親眼看到的，文化的模式無所謂較成熟或不成熟，而只有合適或不合適。當然啦，有些人對於追求完美有其情感上的需要，而他們會將此情感上的需要加諸在他們所做的每一件事上。他們會做這樣的比較，完全與機構所面臨的問題無關，而只與他們自己的問題有關。

溫伯格提到在軟體工程界有許多所謂的改革者，其改革工作的第一步是要求他們要改革的「對象」先承認自己從前是低劣的，結果這些改革者皆未能遂行其願。他認為如果我們的目標是為了改變一個機構，一開始就不應該用有比較優劣意味的用語，例如「成熟」這類偏頗的字眼。^[1]

筆者發現，確實有些人會用「成熟」與否來對流程模式進行價值比較。例如，當年神通在高鐵售票系統出現紕漏時，在網路上筆者曾看到有人認為 CMMI 要達到 ML4 才算品質達到改善的水準，而 ML3 也只是了解流程的情況而已，因此算不上是品質有達到改善。筆者認為這樣的說法是有問題的。

其實任何流程模式所產出的品質應該都是相同的，它們都必須能夠解決組織與專案的問題、以及符合客戶的要求。因此，如果主導改革者的心態不是基於解決的問題或客戶的要求，而是基於自己情感的訴求，所謂的改革也只不過為了遂行其願的私心，卻讓專案與團隊成為無辜的陪葬品。這都是因為領導者沒有建立起正確的價值觀。

流程方法的改變

在軟體產業中，或許是受到用工程來隱喻開發過程的影響，許多人都希望能夠發展出放諸四海皆準的開發方法，以增進開發的效率及降低溝通成本。如果可以用標準化的方式來主導開發流程的變革，進而讓團隊落實良好的開發制度，似乎就意味著可以增進開發的效率並確保品質，但事實上真的是如此嗎？

《Peopleware：腦力密集產業的人才管理之道》提到基層的流程改善乃是知識工作者的基本作為，但是，正式的流程改善卻是把責任從個人向上轉移至組織。個人還有可能會勤訓苦練，並且提昇良好的技能，但組織就只會把東西制度化，而危機就在制度化當中。

制度化會讓組織不願意去冒險，也不會尋求真正的挑戰。而且當工作流程獲得了實質改善，工作就會愈艱難。因為把比較瑣碎的工作交由機器去做，或把不重要的事情從專案中剔除之後，剩下的沒有被替除的工作將會變得更知識密集，需要更多技術與經驗。也就需要更有天份，更有經驗的人來做事。

另外，經過改善的方法，讓人們可以從事更艱難的挑戰。如果我們不敢面對這些挑戰，我們就會採取穩紮穩打的行為以規避風險，但如此一來，這些專案也只能帶來低利潤。^[2]

由此可知，流程方法的改變其實並不意味著可以提昇專案的績效。如果團隊的能力不足，再有效率的流程方法也只能讓團隊只能勝任簡單而低利潤的專案。而依照筆者的觀察，愈依賴組織開發制度的團隊，其創新能力愈難以發揮。因為團隊成員的想法多半會受到制式的標準或規範所限制，難以對解決問題產生新的創見。因此，要讓團隊的創意得以發揮，應該重視成員對問題的見解，而不是用組織的制度來僵化他們的思考。

團隊的創新文化

不管開發方法多麼創新，達成專案目標的最後關鍵終究還是在於執行層面，否則最後必然發生如「誰來幫貓掛鈴鐺」的困窘局面。筆者的一個朋友曾經分享過他對共通性開發方法的看法：

方法論都是要讓問題簡化以適用大部分的情況；可是就如同郭台銘說過的一句話：「魔鬼就藏在細節中」。

因此，與其相信存在終極流程可以保證解決所有問題，還不如發揮團隊的效能，讓成員們可以在細節中展現他們的專業與創意。如同《專案管理之美學》這本書所提到的，不要把焦點擺在流程及方法上，專案經理應該把焦點放在團隊上，規劃和追踪系統必須符合專案的複雜度，以及團隊的文化。

這本書提醒我們，每個團隊和專案都不同，對過去的判斷有所質疑，通常都有很好的理由。因此如果只是因為有本書或某位執行長說要做某事，或者上個月或去年採用了某項技術，並不表示今天也適用。^[3]

筆者常看到許多具有優秀人才的團隊，常常無法發揮整體效能，其主要的原因多半是團隊缺乏創新的文化。尤其位於組織高階的管理者或自視甚高的顧問經常以為他們所主導的流程有必然成功的原因，無法容忍別人有不一樣的意見，於是破壞了團隊的創新文化與創意思考。

其實，軟體開發是知識與腦力密集的行業，有效地溝通比流程與規範的遵循還來得重要。換句話說，如果我們沒有因應專案的複雜度與團隊文化來調適與熟悉開發方法，堅持按照開發方法照章行事很容易讓我們對專案問題產生迷惘。這正是新官上任三把火最大的問題呀。

1. 曾昭屏譯（2006），《溫伯格的軟體管理學：系統化思考（第1卷）》，經濟新潮社。
2. 方亞瀾、錢一一譯（2007），《Peopleware： 腦力密集產業的人才管理之道》，經濟新潮社。
3. 陳建勳、劉漢山譯（2006），《專案管理之美學》，歐萊禮。