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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計不夠好？

戴爾是世界知名的電腦直銷公司，擁有 13 年的網路直銷經驗。對於這種有豐富網路直銷經驗的公司來說，系統連續發生產品標價錯誤的問題，實在是一件令人感到不可思議的事情。在戴爾發生第二次標價錯誤事件之後，筆者聽到有一位工程師出身的朋友指出，戴爾筆記型電腦的標價錯誤，是因為他們的系統設計不良。他依據新聞的報導，對比自己的網站開發經驗，認為可以確定這絕對是設計的問題。研判是促銷資料沒有正確關連產品資料，才會發生這種錯誤。

從戴爾回應外界連續標價錯誤事件的說法，第一次錯誤定位為人為作業疏失，第二次錯誤是因為系統異常。這麼看來朋友的說法似乎有些道理，但從系統開發流程的角度來看，卻讓筆者產生一個疑問。如果是因為設計有問題，應該是可以在系統正式運行前被測試出來，但為什麼要直到錯誤釀成災禍才被使用者發現？朋友表示要做到完整測試系統是很困難的，還不如把系統設計做好，這樣系統自然不會出錯。

在觀念上，我同意朋友的說法，因為好的設計的確可以減少系統發生錯誤的機會。但問題是朋友的想法在實務上卻有操作上的困難。因為設計夠好是很難被清楚定義，尤其是在專案時程及資源有限的情況下，想要設計出可以在各種情況下適用的系統是非常困難的。面對系統運作環境與需求變化無常的情況下，設計通常只是一種權衡與取捨之道；沒有可以解決所有問題的最佳設計，只有針對解決重要問題的最適當設計。

如果我們不能定義出具體明確的系統問題，所謂的較好的設計也只不過對未來可能變化的假設所做的設計，但實際上未來的變化可能會出乎我們的意料之外。當我們對系統的假設不再成立時，就會產生系統可能發生異常的風險。因此，戴爾出現系統異常的原因，問題的關鍵可能並不在設計的好壞，而是沒有掌握好問題的複雜度；今天系統碰上比過去更複雜的問題，是當初設計系統之時所沒有想到的情境。

造成錯誤的原因

從筆者過去系統開發的經驗顯示，過去長期運作正常的系統，經常會因為運作環境發生變化，而使系統在現今發生功能失常。我想戴爾的情況應該也是類似的狀況，否則如果是設計有問題，就很難解釋為什麼過去運作正常的系統，會在今天出問題。如同商業周刊的評論「戴爾烏龍 在於沒換腦袋」所提到的：

戴爾系統無法偵錯的關鍵——戴爾仍以經營企業顧客的思維在做消費者生意，否則怎會沒把消費者異常下單行為納入管理流程？

戴爾成立以來都是以企業市場為重，占營收比重超過八成。直到二○○七年才進入消費市場，這是很大的突破，因為經營企業市場，客戶數量少，強調服務與產品穩定度，但經營消費市場，客戶數倍增，就必須靈活彈性。

但此次事件讓我們看到，即使經歷兩年，戴爾網路系統的「腦袋」還沒轉過來，管理階層也是一般。

從戴爾大中華區中小企業處許肇元的說法，我們也可以了解戴爾系統異常的問題。網路上有一篇 jeremy 寫的專訪中提到許肇元對短短 10 多天連續出了兩次錯誤的解釋：

「因為我們成長的速度太快，而系統並沒有配合我們的成長。像是我們的訂購流程，每個零組件都可以客製化，訂一台筆電的流程換算下來就幾十個關卡，每個關卡都跟價錢有關，牽一髮而動全身。這次事件中，我們真的學到很多，也重新檢視了我們的系統。」

這更讓人相信，問題的關鍵並非單純的系統單一功能失常，而是戴爾忽略了商業模式改變會對系統產生影響，而沒有做好事先預防與事後可以及時因應的準備。

由此可知，造成戴爾系統發生錯誤看起來並非出在各部分功能的問題，而是系統整體整合出現問題而造成系統異常。那麼台北捷運內湖線的系統異常是不是也是相同的問題？從相關新聞報導我們發現，系統發生錯誤的原因也是因為系統沒有整合好，內湖線無法順利整合木柵線舊有系統。這大概從決策當局決定採用規格無法統一的中運量的系統，以及冒險採用無線通訊新技術時就已經註定了這樣的結果。再加上測試時間不足，自然會使品質問題更加雪上加霜而惡化。

造成系統失敗的條件

如果戴爾電腦和台北捷運內湖線的系統異常，種種跡象都顯示是整合出現問題，那麼我們不禁要問：為什麼它們的整合都會出現問題呢？從筆者系統開發的經驗來看，我相信是因為系統整合牽涉的問題太多或是太複雜，使得開發者難以掌握。再加上人們在尚未意識到系統的複雜度之前，常會認為自己有能力解決所有的問題，但實際上他們想要這樣做卻做不到。一言以敝之，系統失敗的根源其實是來自於人性的弱點，雖然這個真相往往被硬體、作業系統或平台的功能失常所掩蔽。

如同著名的軟體工程顧問溫伯格在《第一級評量》提到，造成軟體系統失敗的條件有八個 F，它是分別是弱點（Frailty）、愚蠢（Folly）、執迷不悟（Fatuousness）、好玩（Fun）、欺騙（Fraud）、狂熱（Fanaticism）、硬體功能失常（Failure）與運氣（Fate）。筆者發現這些造成失敗的條件，其實正是表現人性弱點的不同面向。

弱點

弱點是做想做的事卻做不到，它是軟體失敗的終極源頭。因為人不是完美的，他們做不到設計所要求的，不論那是一個程式設計，或是一個過程設計。溫伯格認為管理階層的責任是設計出一個程序以規範程式如何修改，承認自然界的事實，與確保程序本身被執行。而且他認為人們傾向在發生錯誤後懲罰嫌疑犯其實很不好，因為他會讓人隱藏錯誤、浪費時間在找嫌疑犯、以及分散注意力忽略管理階層的責任；建立並執行能及早找出失敗，並預防悲慘後果的程序。

愚蠢

愚蠢是做到想要做的事，但它卻是錯的事。愚蠢的基礎是無知，雖然它在當下沒有發生錯誤，卻會在以後造成錯誤。不過透過學習可以改善無知，進而將愚蠢矯正過來。溫伯格認為建立完整訓練師徒制、技術審查計劃、提供落實計劃的支援，是管理階層可以用來矯正愚蠢的職責。

執迷不悟

執迷不悟是指不肯學習，一直做出蠢事，一次又一次的做。此外，想要管理好一個愚蠢的人，卻不提供他根除愚蠢所需的訓練和經驗，這也算是一種執迷不悟的行為。溫伯格認為在軟體工程機構中，除了把執迷不悟的人送到其它行業去，否則沒有什麼防護措施可以抵擋執迷不悟的人。

好玩

好玩是程式設計師會寫一些奇怪的程式來為自己找樂子，溫伯格認為沒有人能夠預測別人認為好玩的事是什麼，因此好玩的心理是所有失敗的源頭中最危險的一個，因為它防不勝防。但管理者應該提供預防之道：一是開放透明的系統，另一個則是讓單單工作本身具有足夠的趣味。

欺騙

欺騙是用非法的方式從一個系統中獲取個人利益。溫伯格認為好玩是在失敗的源頭中，帶來的最小的損失。因為一個系統找樂子的方法有千百種，但值得一偷的東西卻沒多少。他認為軟體工程經理要好好閱讀以資訊系統詐騙為主題的文章，並採取一切可能的預防措施來防堵它。

狂熱

狂熱是試圖摧毀或瓦解一個系統，而原因不是為了個人利益，而是為了報復。溫伯格認為防範弱點而採取的行動中，多數也可以減少恐怖份子所造成的威脅與影響。

硬體功能失常

溫伯格提到硬體若不能造著當初設計的目的而執行工作，就會造成功能失常的現象，這類問題多半可以用軟體來克服。他認為當人們抱怨硬體造成他所寫的軟體出問題時，我們應該找出它表達的意思，以免遺漏這句話所帶來的重要資訊：

1. 硬體沒什麼大不了的功能失常，但程式設計師需要找藉口來隱瞞一些事實。
2. 硬體功能失常問題都在一般的預期範圍內，可能程式設計師沒有採取正確的防護措施。例如將程式碼或測試腳本做備份。
3. 硬體功能失常，但沒做妳硬體供應商關係的管理工作。
4. 硬體功能失常是由人為錯誤所造成的，如使用者做出出乎意料的動作。

運氣

溫伯格指出運氣不好是多數表現不佳的經理愛用藉口，這不是事實。他建議當我們聽到一個經理老愛說運氣不好時，我們應該把運氣兩字換成經理，因為沒有不好的士兵，只有不好的軍官。

系統異常與人性弱點

從以上造成系統失敗的條件我們可以知道，系統發生異常的原因可能是系統的設計不夠好、硬體設備或作業系統出錯或是系統運作的環境太複雜了，但發生問題的真相卻都大部份是因為人性的弱點。因此，要在失敗前發現錯誤，進而採取行動防止系統失敗，重點管理好人性弱點，而非不承認它的存在，卻只在事後責備人們沒有盡到責任，但事實上最大的責任是管理階層沒有盡到管理的責任。

例如在台北捷運內湖線在 7/10 發生系統大當機的事件後，當外界質疑為什麼發生這麼嚴重的當機事件時，筆者注意到有一篇新聞報導提到市府官員有人表示「這個問題，80 % 是因為電腦中毒」言下之意系統異常多半是因為硬體的功能失常所致，而比較不可能是軟體的瑕疵或人為的錯誤。

溫伯格說過「對錯誤的直接觀察，本身並無意義，但是對『人們作何準備來面對錯誤的發生』的統合觀察就很有意義」那位市府官員的說辭，筆者相信只是為了隱瞞了一些事實，以免公布實情而讓損失更加擴大，然而這卻表現反應他們對面對系統錯誤發生的準備並不夠充分。

筆者再舉一位朋友的經驗為例，以前他們公司採用 .Net 開發平台開發新產品。由於他偏好 Java 的程式寫作慣例，加上當時微軟聲稱與 C# 整合不成問題，讓他很想用 J# 程式語言來開發系統。雖然他的同事擔心系統的整合會出現變數而反對，但由於他的堅持，管理階層還是照他的意思，讓他用 J# 開發他的程式，與其他同事以 C# 的程式來進行整合。

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

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

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

管理的重要性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同人直覺感到不妥，並非因為朋友並不諳 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，《黑天鵝事件》，大塊文化。

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

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

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

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

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

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

依法，或是依人？

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

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

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

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

必要多樣性法則

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

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

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

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

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

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

團隊領導者的力量

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

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

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

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

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

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

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

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

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

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

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

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

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

開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」

同人回答：「沒特別說明就是代表將該欄位填入空白。」

D 君說：「為什麼不是未指定欄位內容呢？」

同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」

D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」

同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」

D 君說：「那規格應該交待這個細節？」

同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」

D 君說：「我知道了，你的意思是說我沒有 common sense！」

同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」

D 君：…

同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。

以同人的觀察來看，許多開發者看規格文件，通常不會站在問題的角度來思考，而是要求別人把答案準備好，然後告訴他們照著把功能做出來。

他們認為文件必須要註明他需要用到的所有資訊，而不要期待他們了解問題，因為他們不想花太多的心力來弄懂它，如果程式照規格開發而出現問題，那必然是規格問題而不是他們的疏失。因此，他們根本不在乎規格記錄語法或是語意，反正有寫就照著做，沒有寫的就不用管它，也不用思考合不合乎他們的 common sense。

同人認為這種心態正是忽略軟體開發的複雜本質，特別是軟體開發常會碰到半結構化、甚至是非結構的問題，使得規格文件難以事先將所有可能遇到的狀況都定義清楚。

舉個常見的例子來說，系統發生某些特別的異常狀態多半不是事前可以預料到的，沒有人能在事前發現問題，但等到發生意外才會發現問題在那裡。而且當我們發現到愈多問題，我們就會發現更多難以預料的未知的問題。

因此，開發者期待文件詳盡到無所不包，在專案現實是不可能做到的。實務上，通常文件規格的重點在於瞭解問題或如何解決問題，而並非得到詳盡的規格。但不明究理的開發者總是不去瞭解問題，只關心規格實做上的細節，當然很難掌握解決問題的要領。同人想到溫伯格說的「沒問題病候群」，他建議碰到這種人還是閃遠一點吧。

其實，表面上 D 君碰到的問題，好像是更改對語法的定義就可以解決問題；客戶認為交易訊息中的欄位不應該是空白的，所以訊息中的欄位空白應該代表該欄位內容未指定。但這樣的想法將會使得語法會受到業務規則的衝擊，而破壞設計概念的整體性與一致性，而影響軟體的設計結構。事實上，語法是不應該受到業務規則的影響，而是用語意來解決業務邏輯的合理性問題。

如果該欄位是必要欄位，那訊息中此欄位出現空白就應該認定資料錯誤；但如果它並不是必要欄位，那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下，我們應該增加一條業務規則來檢核必要欄位不可為空白，否則將拋出異常的回應。如此就非常簡單解決問題，而不該採取自廢武功的作為，因為那只會顯露出開發者缺乏抽象化思考的 common sense 呀。

領導他人是發揮我們的影響力，讓別人去做我們希望他去做的事情。相信很多人會以為自己無法有效領導他人是因為權力太小與位階不夠，無法讓人聽從我們的指揮。但本書的作者麥斯威爾卻認為，領導最大的挑戰就是領導自己。

麥斯威爾認為無論領導者帶領什麼人、或成就什麼事，領導自己一直都是領導者遇到最大挑戰。他指出歷史上功業彪炳的領導者，總以為他們是天之矯子；但如果我們認真檢視他們的生命，不難發現他們自己總需要經過一番掙扎。這就是「自己才是最難領導的人」的原因所在。

麥斯威爾分享他對領導自己的親身體會，他認為領導者應該力行學習服從、培養自律精神、磨鍊堅忍精神、追求負責精神等行為來領導自己。特別是在追求負責精神方面，他指出「領導是信任關係，而非權力關係」，因此領導者必須比別人更早自我「校正」。

儘管絕不自我膨脹是艱難的課題，但無論如何，不管領導者位階多高、掌握多大權力都必須力求做得對。領導者除了為自己負責之外，更得為追隨受自己領導的人負責，這樣的領導才值得受到他人的信任。

看了麥斯威爾上面的觀點，同人想到過去看到那些運用位階或權威的領導者。表面上看起來好像他們是威風八面，但其所表現出來的行為卻是領導無方。當他們動用自己的威權來使他人屈服之際，卻只會讓人發現他們缺乏領導能力，並在不知不覺當中，破壞了領導與被領導之間的信任關係，使得他們更加難以領導他人。

記得兩年前，同人就曾碰過這樣的領導者，當時他是某專案所指定的專案負責人。他對專案應該如何開發有不同的見解，認為專案開發應該照他在二十年前開發軟體的作法，但大部分的開發者認為，這樣做會讓專案失敗而反對他的意見。尤其同人更是擔任烏鴉的角色，基於我的專業，提出很多意見讓這位專案負責人覺得非常頭痛。

後來，在彼此意見分歧達到頂點時，專案負責人運用了位階與權力強迫別人聽命行事。當時他命令同人「不准說話」，結果讓團隊發生了嚴重的關係衝突。當時他可能是想動用權位，來逼走讓他最頭痛的團隊成員，不過此舉卻讓高層注意到他的領導能力出現問題。雖然礙於他在組織及與客戶的關係而無法將他換掉，但也開始削弱他對團隊的影響力，而且最後還是讓同人在此專案受到重用。

當然，這段關係衝突的經驗，讓同人對軟體專案團隊的衝突解決與信任的關係產生興趣，成就我的碩士論文也算是額外的貢獻。而獲益更良多的，大概是雖然沒有見賢思齊，但至少可以見不賢而內自省吧。