經過一個月來的使用，這台 FE3000 用起來還蠻順手，直到最近因為無法透過 USB 連接線輸出照片，才發現 USB 的連接埠故障。老婆到總代理元佑實業要求維修，才發現 OLYMPUS 這個世界名牌數位相機的維修服務，竟是如此糟糕而令人失望。

同人聽到老婆告訴我客服要求我們付錢才能維修，這實在令人感到不可思議。老婆轉述客服的話說，連接埠的故障是因為人為操作錯誤造成，因為連接埠上的接頭凹陷下去，他們認為正常操作絕不會出現這樣的狀況。

老婆當然不能接受客服的說法，但客服說完卻忙著處理另一位客戶的大發雷霆；因為他送修的機器沒修好而吵著要找元佑的總經理處理問題。這時候，輪到另一位女性的客服人員來處理老婆的問題，她還是說這是人為操作不當，如果是按照正常的操作，USB 拔插 10 次都不會有問題。

老婆聽到客服人員這樣說，立即反應說：「這是什麼爛照像機，USB 只能使用 10 次，我以前用過其它廠牌的機型都沒有這樣的問題！」客服人員這時表示請老婆不要生氣，但她還是堅持修理 USB 連結埠故障必須要收費，要不然就只能買讀卡機來處理相片的輸出。老婆因為帶著還不到三歲的女兒，沒辦法也不想花太大的精神找對方理論，只好悻悻然地帶著相機回家。

聽到老婆送修數位相機的過程，實在讓同人覺得這個名牌數位相機維修服務真是離譜。在台灣的今天，竟然還有如此缺乏品質意識的公司，真是令人匪夷所思。

OLYMPUS 的 FE3000 並不是我們家所使用的第一台數位相機，過去我們用過很多其它廠牌的數位相機，而且也經常利用數位相機所附的 USB 界面來進行照片的影像輸出，從來也沒發生過 USB 連結埠那麼不堪使用的問題。

如果真如客服說是因為人為操作不當而造成損壞，那麼什麼樣的操作會造成這種問題呢？老婆轉述客服說可能是接頭方向對錯了，我聽到客服人員這樣說倒是想請對方表演如何將 USB 接頭反接給我看！事實上，這台相機的 USB 插槽有防止反接的缺口設計，根本就不可能發生將 USB 傳輸線反接的現象。

如果使用者不可能將 USB 傳輸線接反，再加上我們並非第一次使用 USB 的傳輸界面，對我們而言，連結 USB 傳輸線是那麼單純而簡單的步驟，我們應該不可能會弄錯而導致 USB 連結埠的損壞。如此看來，USB 連結埠的損壞的原因根本就並非人為操作不當，而是機器本身的設計不良或是構件本身的瑕疵。

所謂設計不良是指使用者在正常操作下會造成機件故障的比率。換言之，就像客服人員說得 USB 傳輸線正常拔插 10 次也不會故障。假如她說的沒錯，那麼就代表這台數位相機的 USB 傳輸線拔插的設計，只能保證正常使用拔插 10 次不會導致連結埠的損壞。因此站在使用者的觀點來看，這種設計當然是設計不良。

然而以常理來推論，實在很難讓人相信 OLYMPUS 的 USB 連結埠會設計成只能拔插 10 次而已。這樣看來，如果 USB 連結埠損害的原因不是因為設計不良，那麼就是 USB 連結埠構件本身的瑕疵，才會如此不堪使用。而那位客服人員如此缺乏 common sense 的說辭，不是想掩飾產品品質不良的真相，就是想要推拖維修的責任而刁難顧客。

這種罔顧客戶權益的行為，是客服人員的素質太差，還是因為元佑本身的企業文化所致？有網友告訴同人，在網路上元佑的相機維修，早就劣跡斑斑了。聽過老婆跟元佑接觸的經驗，再看看到網路上的文章、以及一些網友的經驗，讓人相信除了客服人員的問題之外，更嚴重的問題是他們的企業文化根本不重視「服務品質」這回事；對於客戶的維修需求，能夠推掉一件就賺一件，如果推不掉就再來修。換句話說，就是會吵的孩子才有糖吃。

一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣。而是要怪自己沒有看清楚服務條款，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。

因此，相機的保固問題自然有法律來保障我們的權益，但除此之外，我們仍舊可以將不愉快的相機維修經驗，用來降低其他消費者因為資訊不對稱而增加的交易成本，以自然淘汰不良的服務品質。希望透過這篇文章的分享，也能夠讓更多人了解，數位相機除了品牌形象與功能外，不要忽略了售後的維修服務呀。

網路上其它有關元佑維修的討論：

數位相機不防水

戰勝元佑的例子

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

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

設計不夠好？

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

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

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

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

管理的重要性

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

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

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

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

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

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

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

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

同人看到這則新聞的第一個反應是，總統在救災過程中受到批評，心裡面會產生一些情緒是人之常情。因此透過 email 中將這些情緒發洩出來，跟家人訴訴苦以免情緒積壓而損害身心健康，我認為是很自然的一件事。只不過，馬大姐把這些用來宣洩情緒的對話，在公開場合中公開，似乎只會為她的弟弟帶來麻煩，顯然她又失言了！

不過，除了馬以南的失言之外，同人認為這則新聞更重要的意義是，讓我們看到領導者應該如何面對批評。在現實上，領導者所碰到的難處是，不管領導者碰到問題怎麼做，他都很難做到沒有人批評。因此想要成為優秀的領導者，其實無須太在意外界的批評，而是應該將這些批評轉化成更積極正向的領導作為。

就像在《領導的黃金法則》中，作者約翰‧麥斯威爾提到「當你後面被踢一腳，你知道你已超越在前」。身為領導者，我們應該要有面對批評的準備。那麼領導者應該如何面對批評呢？麥斯威爾認為下面四個步驟可以幫助領導者處理批評：

第一，認識你自己，這是真相問題；

第二，改變你自己，這是責任感問題；

第三，接納你自己，這是成熟度問題；

第四，忘掉你自己，這是安全感問題。

麥斯威爾認為領導者無須理會對領導者職位的批評，但對個人缺點的批評，卻必須要設法改正。要認清人們是基於領導者的職位，或是領導者個人本身，唯一的方法就是認識自己。其次，改進自己的缺點是領導者的職責，但也必須能夠分辨善意批評或是惡意批評，可以問自己下列三個問題：

誰在批評？智者的忠言逆耳勝過愚者的熱情贊助。批評的人是誰很重要！

如何批評？試著分辨對方武斷還是提出疑問、好言相勸。

為何批評？是出自傷害我的動機或是為了我好？會傷害他人的人不會手軟，他們猛烈抨擊他人是想讓自己好過，而非幫助對方。

對於領導者的言行，在一開始人們通常會說你錯了，但後來卻又會說你是對的，而且重點不是你做什麼，而是他們知道你做的事情很重要。面對旁人這種多變的反應，麥斯威爾說領導者應該學會接納自己，並且指出為了做我們理想中最好的人和領導者，我們需要做好我們自己。

可是那並不代表我們不用改變或成長，而是表示必須努力做到最好的自己。真實做自己是邁向更好的自己的第一步，而接納自我是成熟的象徵。如果我們擔心別人怎麼看我們，那是因為我們對他們的意見比對自己更有信心。

有效處理批評的最後一步就是不再把焦點放在自己身上，麥斯威爾認為領導者不需要花太多時間擔心別人怎麼看自己，其實別人並沒有那麼在意我們。

麥斯威爾說有安全感的人忘記自己，所以他們可以把焦點放在別人身上，以面對任何批評，甚至為批評他們的人來服務。他說一個有安全感的領導者永遠不需要為自己辯護。做為領導者應當看重責任，但卻不應該把自己看得太重。

從麥斯威爾的觀點來看總統府對這次風波的回應，同人覺得有信心的領導者實在不應該花時間來為自己辯駁。如果埋怨「好人（心）沒好報」只是為了一時情緒的宣洩，就算不小心被馬大姐把在家裡面說的話公開出來，但只要承認自己的情緒及壓力確實存在，並表示自己會想辦法好好處理它們，讓自己能夠把事情做好。這樣就足以代表領導者在行為上是接納自己與放下自己，也就表現出足夠的成熟度與安全感。

可惜馬總統似乎是太在意旁人對他的觀感，因而太維護自己「被曲解」的形象。其實同人過去在〈新官上任三把火〉及〈當專案一再出現相同錯誤時〉這兩篇文章中，就曾經探討過馬團隊在管理或領導上的問題，從這些文章中似乎可以歸納出來馬總統領導的問題在「完美」兩字上。

或許在理念上，馬總統認為按照他的理想去做，就能夠讓事情達到完美的結果。但事實上，理想上的完美是不存在的，真正的完美是要你認識自己，並接納自己是不完美的，然後你才能改變自己而成就真實的完美。

因此，對外界的批評，如果馬總統一直把焦點放在自己身上，他就很難理解別人為什麼看不到他的辛苦與努力，也就無法體恤別人受到的痛苦。在缺乏安全感及成熟度的反應背後，我們看到根本的原因是領導者不能認識自己並加以改變。例如在報導中看到：

杜勇明則指出，他說「馬總統您來晚了！」這句話是針對馬政府團隊救災一團亂有感而發，總統原本就該承擔政府所有責任，但把這件事拉到個人問題是不對的。

會發生這樣的誤解，顯然馬總統不夠認識自己，才會分不清批評是針對個人或是職務而來。不過，同人這篇文章並不是期望改變，只是藉由對他人領導行為現象的觀察，帶來有助於自我成長的學習。因為生命的學習與成長是無止境的，所以即使在位的領導者未能改變，但或許只是時間還沒到。多點耐心給別人，也希望能讓我們從別人的錯誤中學習成長。

相關文章：

• 領導者的黃金法則~處理批評-領導者需要學習的功課

延伸閱讀：（其它有關領導的文章）

• 領導是信任關係
• 結構性無作為
• 當專案一再出現相同錯誤時
• 新官上任三把火

到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。

在松山機場站，捷運公司的人告訴我們，免費接駁車可以坐到動物園站，但內湖線的接駁公車沒有進入機場的站牌，所以必須坐接駁車到中山國中站，再轉搭內湖線的免費接駁公車。大家等了好一會兒，終於坐接駁車到中山國中站，但內湖線的公車怎麼一直都等不到呢？看到對面往動物園方向的車子一班接一班，而在內湖線接駁公車等待的地方，就只能看到公車一班接一班開走，卻絲亳不見接駁公車的身影。

等了半小時，讓同人的耐心已經將要消耗殆盡了，於是問了在站牌捷運公司的服務小姐。我問：「為什麼對面的接駁車都已經開走三班了，為什麼到內湖線的公車卻一班都還沒來呢？」服務小姐表示因為對面的接駁車是從松山機場發車會比較快，往內湖線的接駁車已由麟光站在 8:30 分發車，開過來要花一點時間，請我們耐心等待。

旁邊有一位小姐聽到服務小姐的說法，覺得很不合理。她說：明明捷運發生系統異常是在晚上 8:00 左右，為什麼直到 8:30 才發車？服務小姐辯稱是因為與公車業者協調需要時間。不過這樣的說法讓在場等接駁車的乘客不能接受。在這段期間，同人又看到往動物園的接駁車又過去一輛了，而且乘坐的人非常少。大家開始質疑，為什麼不從對面的接駁車調度一些過來支援內湖線的接駁車呢？

後來，好不容易看見我們這邊有接駁車開過來，但卻不是往內湖的車子，而是開到松山機場站。可是，看到班班幾乎空車就令人生氣；排隊的人龍那麼長，接駁車卻是開往沒有人要去的地方；讓同人不得不說，捷運公司實在是沒有規劃好接駁車正確的需求。

往內湖線的接駁車終於來了，但坐上車的人只有一位，因為它「客滿」了。這讓在場的乘客愈來愈生氣，服務小姐只能用手中的無線電詢問公車調度的情況，但似乎情況難以掌握而對事情沒有幫助。讓同人最後不想浪費時間，放棄坐免費接駁車回家的計劃，選擇自己花錢坐計程車回家。

對於台北捷運內湖線的系統異常，同人一直都是抱持著同情的態度。我自己也經歷幾次的系統失常的事故，不過看到捷運公司人員，為了處理或解決系統狀況而奔忙，加上自己系統開發的經驗，讓我比較能接受新系統出現不穩定的情況。

然而，看到這次離譜的調度，讓我很懷疑真正的問題是捷運公司面對問題的態度。在處理問題前沒有把腦袋放在正確的位置，不能針對客戶的需要來思考問題，而只是浪費資源在不重要的事情上。顯然捷運公司對解決問題的訓練是不足的，問題不是服務人員盡了力沒有，而是他們在盡力之前，到底有沒有把問題想清楚呀！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

依法，或是依人？

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

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

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

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

必要多樣性法則

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

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

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

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

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

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

團隊領導者的力量

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

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

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

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

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

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

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

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

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

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

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

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

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

很多人都知道溝通對專案的重要性，透過溝通，開發者可以瞭解使用者的需求，並據以實現。然而實際上，專案的溝通卻常會因為種種原因而出現問題，除了無法實現使用者需求之外，還會造成使用者的抱怨以及不愉快的使用經驗。

無論建築或是軟體開發，溝通不良都會造成專案的失敗。如同 ZDNet 副總編鍾翠玲所觀察到的現象，建築師無法了解使用者的需求就相當於軟體系統架構師或專案經理不了解使用者的作業流程或習慣，結果就是建造出不合用的建築或軟體系統。

鍾翠玲從災後學校重建的實例中看到建築師與校方的溝通上出了問題，她認為這是因為校方沒有積極地參與設計的緣故。我們很難知道這是否是實情，但如果在軟體專案碰到同樣的現象時，筆者不一定會認為是因為使用者缺乏積極參與。從筆者的專案經驗顯示，即使使用者積極參與設計，開發者還是會因為與使用者之間存在觀念溝通上的藩離，而聽不見使用者的心聲。

組織邊界的隔閡

傳統的工業經濟，由於講求大量生產，客戶無須與製造者溝通，因此沒有溝通的問題。但知識經濟強調的是可以符合不同客戶差異性的需求，因此開發者必須與客戶溝通以進行客製化的工作，然而組織邊界的藩籬卻經常增加了溝通難度。

軟體開發者與使用者所遭遇的問題常常不一樣，並且受限於環境、背景、專業、能力等因素，對問題往往會有不同的表達方式或認知，這也就常常造就了先天上的溝通障礙。

為了讓彼此的溝通更加順暢，資訊部門常會擔任開發者與使用者之間的溝通橋樑。他們與使用者處於相同的組織，會比開發者更了解使用者的問題；同時資訊部門也比使用者更了解資訊技術的專業，與開發者溝通會比較不會因為技術背景不同而產生認知上的落差。

然而實際上卻不盡然如此，開發者與資訊部門的溝通還是會讓開發者不見得可以正確無誤地聽到使用者的心聲，其中的原因之一是因為組織邊界是相當不容易跨越的。筆者曾經與石頭成、喲哪桑討論過這個議題，提出了我們各自的經驗與看法。

筆者認為開發者與資訊部門之間，存在對專案不同的期待與目的，使得彼此很難建立共同目標，除非彼此之間存在足夠的信任。在沒有足夠的互信基礎下，彼此之間很難達成共識，而造成了交易成本的增加。

石頭成認為開發者與使用者之間，交易成本的增加是因為資訊部門與開發者的專業經理並不是真的系出同門。他提出了資訊部門的出身科系以資管系居多，開發者的專案經理的出身科系以資工系居多的假說。他認為如果此假說成立，正代表了資訊部門與專案經理之間互相不知道彼此在想什麼。也就是說專案經理不敢承諾資訊部門提出的需求；資訊部門不肯為專案經理提出的功能背書，因此產生了龐大的交易成本。

喲哪桑則根據他的觀察提出了另一種可能的觀點，也就是研發人員與資訊部門心中的技術階級制度在作祟。他發現很多人常常覺得系統管理的階級，比做研發人員的來得低。他提到：

如果大家都有這種心態，溝通起來就好像走在地雷區一樣，有的RD會覺得自己為顧客恩賜的五斗米而折斷了腰，有的MIS更成了從自卑感而產生的自大狂，大家都是未爆彈，衝突隨時一觸即發。

其實從筆者與石頭成與喲哪桑的討論來看，不難發現開發者與資訊部門之間的溝通問題大致可分為彼此之間資訊不對稱的現象與利益衝突不相容兩方面來看，而依筆者的觀察，這兩方面的原因彼此之間會相互增長，正如下面的系統思考圖所展現的動態系統模型所示：

如圖所示，資訊不對稱的現象會因為利益衝突而不斷加劇，當甲乙雙方的利害關係是不相容的，那麼就會有一方會想辦法增加資訊不對稱的現象，而另一方則想辦法減少資訊不對稱的現象，因此，資訊不對稱的現象不可能會被消除，而且我們更可以推想得知，雙方鬥法的結果，引發衝突是必然的結果，差別只在於是否浮上枱面。

組織觀點的不同步調

因此對開發者而言，要聽見使用者的心聲，必先縮小組織邊界的隔閡。開發者應該要與客戶建立足夠的互信基礎，讓彼此能夠朝向共同的目標而努力，同時必須善用溝通技巧與問題解決能力來解決衝突。然而，如果這些開發者都做到了，是否就能夠跨越觀念溝通上的藩離呢？其實，這代表考驗才正要開始呢，因為觀念溝通上的藩離還有第二個成因，那就是組織觀點的不同步調，常讓開發者無所適從。

資訊系統的開發往往會牽涉到許多複雜的觀點，資訊系統本身本來就是在各種政治因素妥協下的產物。即使撇開工程技術觀點不談，社會技術觀點就夠讓開發者疲於奔命了。筆者觀察到在軟體開發過程中，業務流程與資訊整合常會因為觀念上的不同，而出現相互競爭的現象。

使用者最清楚業務流程，因此應該讓開發者與他們直接溝通需求，而由資訊部門扮演支援的角色。但這樣做的缺點是容易造成資訊整合的困擾，使用者心目中的理想系統，可能會與現存的系統有些不一致的地方，而造成整合的困難。但如果沒有進行整合，組織將會存在兩種不同的作業方式，而讓管理變得更複雜。

因此，如果考慮到資訊整合的問題，通常會讓資訊部門用策略的角度來看資訊系統開發，由他們來提出系統需求。但這樣做的問題是，資訊部門往往不能體會使用者的實際需要，使得開發出來的系統功能不見得會符合他們的需要，甚至要削足適履才能完成作業。往往為了遷就系統的設計，讓他們在系統操作上倍感不便，因而降低他們使用新系統的意願。

使用者與資訊部門觀點上的矛盾，突顯了在企業組織中，業務流程與資訊整合之間存在著步調上的差異，而這樣的差異往往會升高組織中同步化與非同步化之間的緊張關係^[1]。

開發者的純潔心靈

這種同步化與非同步化的緊張關係，其實在軟體需求者的組織當中是隨處可見的。每個專案關係人對資訊系統總是存在不同的目標與期待，而開發者很容易聽到較有影響力或擅長掌控者的聲音，卻不容易聽到或是容易忽略那些受到壓抑的想法，但這些想法卻可能是專案成敗之關鍵所在。

在組織中，很少人會去質疑主流或具有權威性的想法，但主流想法常常是不合時宜，只是因為受到習慣領域的影響而根生蒂固。即使組織中有少數人會挑戰這些想法，但卻又常常會因為「政治因素」而讓他們受到排擠。然而，開發者可以有機會發現它們，讓組織出現轉變的契機，然而這必須保持開發者的純潔心靈。

如同筆者曾參與過的專案，有一位企業高層的告誡：「你們千萬不要被『業務流程』污染了『純真的心靈』，應該專注思考如何用資訊技術來創新流程」。使用者的心聲並不在業務流程，而是如何找到他們關切的問題，然後為他們創造價值。因此開發者必須用心傾聽那些微弱的聲音，才能聽見使用者的心聲，這個道理我想不管是建築或是軟體開發，應該都是一樣的吧！

1. 托佛勒在《Wealth 3.0 財富革命》一書中提到時間觀的改變已對我們的生活產生一些影響：「許多重要的機構確實步調不一，同步化與非同步化的關係將愈來愈緊張，追求速度的趨勢並未改變，時間的安排愈來愈不規律，生產力與時間的關聯愈來愈小，每一刻都比前一刻更值錢，人類已有能力測量、探究、控制極大或極小的時間單位－這種種現象顯示歷史性的重大改變正在發生。」（張美惠譯，2007，〈新時間觀〉，p70，時報文化出版。）

專業經理人必須具備什麼能力呢？同人認為大致可歸納為兩方面來看，專業經理人必須創造企業的績效。如果企業沒有績效可言，企業就很難在競爭激烈的環境下存續，更不用說達到企業目標了。另一方面，專案經理人也必須經營團隊。因為在專業分工日益精細的今日，企業成功已非單打獨鬥就可以竟其功，而是必需發揮團隊合作的精神，才能得以創造最大的組織績效。

要創造績效，專業經理人必須發揮他的影響力，領導員工做正確的事（do right thing）來追求企業效能（effectiveness），這就是「天行健，君子以自強不息」的處事之道。同時，要經營團隊，專業經理人則必須管理團隊，讓員工能夠把事情做好（do thing right），以追求團隊效率（efficiency），這便是「地勢坤，君子以厚德載物」的待人之道。

而從易經的哲學思維來看，待人與處事的基本精神在於易簡之理，正如同《繫辭傳》中的所說的：

乾以易知，坤以簡能。易則易知，簡則易從。易知則有親，易從而有功。有親則可久，有功則可大。可久則賢人之德，可大則賢人之業。易簡，而天下之理得矣。天下之理得，而成位乎其中矣。

易簡之理的道理其實並不難理解，容易的事物有助於理解，因為它讓人感到親切；簡單的事物容易讓人遵從，因為它可以讓人容易做到。專業經理人運用易簡之理來處事及待人，可以創造可長可久的價值，以成就德業用來領導與管理眾人。

因此，優秀的專業經理人所憑藉的不是官大學問大，而是專業能力與謙虛態度。如果他無法讓人感受到親和的魅力，以行為表率展現出對專業的堅持使人效法，他其實是不懂領導之術的。同樣的道理，如果他在無法樹立可以讓人依循的標準，並讓屬下可以有發揮所長的舞台，以謙虛的態度來尊重彼此的差異性，他其實也是不懂管理之術的。

然而，要如何培養專業堅持與謙虛態度呢？同人認為應該從心開始培養，這可從乾卦九二「見龍在田，利見大人」以及坤卦六二「直方大，不習無不利」的觀念來理解。

君子學以聚之，問以辨之，居以寬之，仁以行之。

直其正，方其義；君子敬以直內，義以方外，敬義立，而德不孤。

－《文言傳》

在培養專業能力方面，平常應當養成多思考問題並與他人多多討論，集合眾人才智以發揮創新精神。而在培養謙虛態度方面，重視紀律應從自己做起，嚴以律己寬以待人，如此才有助於形成一流異質團隊。

如此便能培養出成為優秀專業經理人的能力，達到乾坤九五「飛龍在天，利見大人」以及「黃裳元吉」的境界。

聖人出而萬物賭，本乎天者親上，本乎地者親下，則各從其類也。

君子黃中通理，正位居體，美在其中，而暢於四支，發於事業，美之至也。

－《文言傳》

專業經理人能夠做到專業堅持，使組織的每個角色，都能各安其分，貢獻其所長使企業不斷創新，創新得之於仁的動機，以影響力來領導。同時，他的態度謙虛也可做到禮賢下士，雖然地位崇高待人卻柔順明理，一流的團隊來自於良好的紀律，才能把好的想法轉成行動，使組織能夠突飛猛進。

因此，專業經理人如何吃頭路，道理其實並不困難，困難在於專業經理人的行為能力。依據同人在職場的觀察常發現，多數起因於恐懼的管理哲學，常常無法留住一流人才。很多專業經理人的口才很好，能力很強，但他們的行為卻一再地趕跑優秀的人才，我想這或許和專業經理人的智慧有關吧。

同人在此借用佛法《金剛經》的道理來說明專業經理人的智慧。當專業經理人執著於人我或去來之分時，他會思考如何發揮能力以不斷提昇自身核心競爭力的問題，此為發心菩提的常見。而當他關注於當下並發現不應執著於自身的能力，體會環境是變化無常的，唯有掌握時機才能產生價值時，此為伏心菩提的斷見。

然而，直到專業經理人領略到了「應無所住而生其心」的道理，也就是不執著於企業的有無、來去及現在，而去思考企業存在的意義，建立服務眾人的核心願景，而且不忘初心地以謙卑（慈悲心）與創新（智慧心）來創造價值時，這便是明心菩提的中觀見。專業經理人要如何吃頭路，其實是取決於經理人智慧成長的歷練呀。

照理來說，組織研發能力應該可以藉由組織的專案經驗累積而慢慢培養，因此應該讓研發人員積極參與各項專案，以讓他們從實戰經驗中提昇研發能力。但實際上，當研發人員忙碌於各專案時，組織的凝聚力卻在無形之中被削弱了，長久下來卻對組織研發能力卻有著不良的影響。

近兩年來，同人觀察到身處所服務的部門便有這樣的問題。部門同仁常常會因為專案告急而被抽調人力，所以大家很難有時間可以聚在一起，部門也找不到大家都有空的時間來開部門會議，用來交流最近的工作體會、討論如何解決工作上所遇到的瓶頸與問題、以及聯絡彼此之間的情誼。因此，結果使得部門缺乏向心力與士氣，流失了許多有能力的人才、專業知識也無法在部門中分享及擴散、更不用說組織研發能力可以有效提昇了。

一位經理向同人表示，公司在執行專案採用矩陣式專案組織常會發現很難衡量員工的績效，因此將公司傾向以專案式組織來執行專案，讓專案經理可以直接以員工對專案的貢獻來評定他的工作績效，於是將視專案需要而讓人員調動部門。我其實能夠理解高層會有這樣的想法，但以站在知識工作者的觀點來看，但卻認為這樣的做法對整個部門專業知識的累積與研發能力的成長有不良的影響。

當然，如果用勞力或資源投入工時的角度來看專案開發，公司的這種做法其實是無可厚非的。只要投入足夠的開發人力，就可以產出相對的專案績效以為公司獲取利益，因此，要得到好的專案績效必須讓研發人員貢獻他們的心力與時間在專案上，而將人員調動部門其實可以讓人力的管控更為方便。

但同人認為這種管理思維忽略了研發人員是知識工作者的事實，知識工作者對專案的貢獻是腦力而非勞力。腦力密集工作是需要創新思考與溝通的，所以無法單純地以時間花費來衡量績效。管理者應該塑造一個適合知識分享的工作環境，以促進知識工作者的創新思考與溝通，而不是讓他們陷於專案永無止盡的忙碌之中。因為這樣將讓他們失去對工作的熱情與成就感，並在對工作環境澈底失望後選擇離開公司。

那位經理與同人都很希望組織軟體設計能力能夠提昇，建立起一流的軟體開發團隊。兩年來我們做了很多次的討論、制定了不少的計劃、也進行了許多次的教育訓練。然而，部門卻一次又一次地因為專案事件而無法凝聚向心力，因為專案問題所造成的部門人員流動率實在是太高了。

在這過程中我深切地體認到，如果研發部門凝聚力不足，或是沒有建立起有助於知識分享與擴散的機制，要靠專案的實戰經驗來提昇組織研發能力其實是不切實際的。因為當專案壓力來臨時，專案經理往往很難兼顧到成員知識分享的層面，而等到專案結案之後，才發現很多部門成員卻因專案而耗損。

公司高層不重視知識管理，要提昇組織研發能力實在是非常困難的。只靠上位者的口惠而不實的演說技巧或是偶爾地鼓勵是無法激發潛能、鼓舞士氣。因為大家都明白高層並不關心研發人員的職涯發展，只知視眼前的成本與績效，彼此之間只有利益交換而沒有榮辱與共的伙伴關係，又怎能創造出讓組織可長可久的更大價值呀。

有時候，對同一件事情，人們很習慣會加入個人的情感及主觀的信念而推論出自己對事物的看法，同時對他人的不同聲音，會從他的話語中片面地抽取我們想要的意義，而斷章取義的結果往往是造成雙方在觀念上的無法溝通。

同人所經歷的那幾場辯論正是一直上演著這樣的情境。在許多人的眼中看來，表面上是我藉題發揮，抓住對方論點邏輯上的缺陷不放；但在另一方面，我所看到的卻是這些人在討論事情的時候，沒有認清楚我真正想要談論的重點。

他們以為我正是藉由打擊一方的論點，來突顯對方一定是錯的而堅持我自己的主張，但他們對我個人的批評卻著實令人感到疑惑：他們似乎看不到我的訴求，認定他們所想的就是真理，我發現大家是如此堅信自己的觀點，以致無法深入地思考對方所提出的看法。

在兩性戰國論壇中，網友亞言提到了真理愈辯愈明，她認同我說的「針對誤會解釋清楚就沒問題」的觀點。看了她的評論，透過自我省思，同人回顧與大家爭論問題的過程中發現，我原來希望透過對話而促成共同思考的動機，到最後卻演變成各自捍衛個人立場的辯論大會，顯見在這方面，我要學的還很多。

例如，我並沒有及時明白指出雙方在觀點的歧異，面對對方迴避及言詞上攻擊的行為，沒有清楚明白表達個人的不悅，清楚表達個人沒有受到尊重的感受，卻讓這些不滿的情緒破壞雙方的情感，自然沒有對話的品質可言。可見在對話過程中，我還是會被情緒牽著走，這也是我該學習的地方。

同人相信大家對事情的觀點不一致並不代表彼此是無法對話的，而討論區版主莫齋也提到了在討論過程中，觀點不同不是彼此之間發生衝突的最主要原因，她說：

其實我覺得討論區上的衝突不多是因為論點極大的差異，而是資訊不足，和口氣被誤解和情緒被捲入的問題。

莫齋說的正是實情，當我提出對深林觀點的不認同時，我的目的是希望大家能擴大對問題的思考方向，可以站在不同的角度來思考問題，以免因為個人主觀的價值衡量，而造成認知的偏差。換句話說，我希望深林能為自己的論點提出更嚴謹的論證，或許應該提供更多的證據來支持他的觀點，同時不該只站在單一立場來看事情。

但很可惜的是，從其他網友的回應中看來，我並沒有感受到他們對我的不同看法之尊重，或許只是因為我的意見看起來是與大家所相信的真理不一樣，使他們無法接受我竟然會挑戰他們所認為牢不可破的信念，於是讓討論過程中充斥了攻擊及情緒性的字眼，大家針鋒相對，不願暫緩個人的想法，去聽一聽對方在說什麼。

辯論的結果，當然是我聽不到對方對我的質疑提出正面回應，而是表面上禮貎性地說他希望我是對的，但實際上卻讓我感受不到應有的尊重，直接說我錯了，卻沒有說為什麼他認為我錯了。對這種只有立場而沒有思辨過程的論述，同人當然不能接受，因為我認為對方只是不斷地在迴避我所提出的問題，而沒有正視問題的思辨過程。

同人期望下次的對話會更有品質，但真理真的是愈辯愈明嗎？那倒也不見得的，正如一句諺語所言：「公說公有理，婆說婆有理（There is two sides to every question）」，每一個問題都會有正反兩面看法，各有各的道理，誰也不願意被對方說服呀。

真理雖然是透過對立的意見的爭論而發現真理的藝術，但在充滿了誤解與情緒的辯論中，大家常常都不願意暫緩自己的想法並在態度上尊重對方，這樣如何能進一步從對話中共享意義，並不斷地透過修正個自論點不夠成熟的地方，以對雙方形成更完善而一致的觀點呢？

過於堅持個人觀點的立場是不能動搖的，就很難站在他人立場去思考問題，在這樣的討論氣氛下，彼此的堅持很可能都是對的，但從相互對立的角度而言，也意味著都雙方也是錯的，換句話說，真理並沒有浮現出來，它還只是隱匿在雙方的各持己見當中。

其實，真理不是靠辯出來的，而是辨出來的，前者靠的是說服對方的口舌之爭，後者靠的才是對問題的深入探索與思辨。透過不同的觀點的剌激與撞擊，才能讓真理浮現出來吧，所以真理是愈「辨」愈明，而不是愈辯愈明呀！

Powered by ScribeFire.