記得，以前曾經聽過一個笑話，有個顧問在印名片時，發現印名片的廠商把名片上的頭銜印錯了，印成【專業顧門】
文/黃忠成
我是專業顧門口！
記得，以前曾經聽過一個笑話，有個顧問在印名片時，發現印名片的廠商把名片上的
頭銜印錯了，印成【專業顧門】，於是該顧問打了個電話給廠商。
顧問：喂，你們搞什麼啊，怎麼會把名片上的頭銜給印錯啦？頭銜上的門少了一個口！
廠商：真不好意思，我們會立刻改正重印，明天就能給你送上了。
翌日，顧問收到了廠商重印的名片，該廠商還很貼心的主動多送了一盒，只是顧問看了
一下名片，差點沒昏倒，名片上印的是【專業顧門口】！
我常講這個笑話，起因是許多朋友或是剛認識的人在問及我的職業時，我總是笑著回
答：【我是專業顧門口的！】
有些人聽到會會心一笑，有些則是狐疑以待，這時我就會開始講這個笑話了。
接下來會問的問題倒是統一的很，就是問技術顧問的主要工作內容，這是一個需要花
時間回答的問題，我常以【就是回答客戶所提出的任何軟體技術問題】來搪塞，呃！你
我應該都清楚，這是事實，但不是完整的事實。
踏入技術顧問這行是一個因緣，當年我在結束10多年軟體設計生涯時，曾在思考未
來時掙扎著，我不想繼續過專案開發的生活，但似乎除了寫程式外，我沒有其它的謀生
技能，面試過幾家公司，也被幾家公司錄用，但最後！我還是選擇不繼續這樣的生活！
畢竟10幾年的拼搏，對於寫專案，我早已無力。
因緣際會，朋友任職的公司恰巧需要一個技術顧問，在許多人的幫助下，我得到了一
個面試的機會，直到今日，對於當日面試的情況我仍然念念不忘。
【諸葛亮舌戰群儒】，是我常用來比喻當日情況的用語，當然，我才不及諸葛亮，長
得也沒人家帥，電影赤璧中，諸葛亮是由公認的大帥哥金城 武出演，呃....我連他的一
成都不到。
我依然記得，當日在那個中型會議室中，大概坐著8個人，站了6 個人，每個人都
提出他們的問題來詢問我，就像是被14個面試官交叉詰問般緊湊，很不可思議的，我
10多年的軟體設計生涯，居然讓我對他們提出的問題，應答如流水般順暢，很順利的！
我得到了這個顧問工作，也讓我走進了完全不同的一條資訊路之支流。
我的技術顧問之道
對於一個剛踏入這個行業的我而言，對於技術顧問這個工作的內容仍然不是很了解，
我只記得我所收到的第一個考驗：
公司所開發的程式已經分發到遠在國外的客戶手上，並正常執行，只是偶爾會發生當
機的情況，大致情形是程式在使用一段時間後，就呈現了無回應的狀態，何時會發生並
無規率可循。
依照我過往的經驗，這大概是程式的問題或是記憶體不當配置所致，但我無法確定，
因為程式不是我寫的，我甚至連該程式內部長什麼樣子都不清楚。不過，我很確定一件
事，必然有某種事件發生才導致這樣的結果！
所以，我引入了一個新工具，該工具可以將一段程式碼編入應用程式中，記錄該應用
程式執行時期所引發的例外，在重新編譯並分發後，透過LOG檔，我發現到了該程式偶
爾會出現連不到資料庫的例外。
諸多現象顯示，這是一個網路問題，與程式無關，於是我要求駐點人員重新檢視客戶
的網路配置，順利的解決了這個問題。
之後，我所解決的問題就很少在我記憶中留下太多的痕跡，多半是同事詢問要做到那
件事要怎麼做？某個Function怎麼不正常？某個程式語言能否達到特定功能等等！
我面對這類問題最常見的反應是，當問題夠簡單時，例如只要用某個函式就能做到，
我會回答該函式的名稱，及如何找到函式使用說明，當同事無法由此回答來解決問題
時，我便會挽起袖子，寫一個小範例給他。
當問題涉及面較廣時，我會直接寫個小範例，然後向同事解釋此範例構成要素，協助
他解決問題，最後給幾個參考資料，讓同事更了解這個解決方案
這些便是我技術顧問工作的內容之一。
獲取信任
10多年的軟體設計生涯中，我曾是一個工程師，也曾是一個領導整個專案的管理者，
我清楚的知道，程式設計師是一個具專業技能的工作者，有其傲氣存在，當你想在這個
領域領導他們或反駁他們前，你得先獲取他們的尊敬與信任。
在技術顧問這行，這點更是明顯，我很明白我是一個空降部隊，我極少在專案開始前
就出現，倒是常在專案進行間或接近結尾前現身，在這時！我如何讓這些同事認可我的
能力，並聽從我的決議及解決方案呢？簡單的說，就是如何獲取同事的尊敬及信任？
這不是一蹴可及的工作，因為人的信任不是馬上就能獲得的，即使來的顧問是業界有
名的大師級人物，多數工程師仍然會抱持懷疑的態度，呃！【走著瞧】露骨但非常貼切
的形容詞。
我處理此問題的方法很簡單，在一開始，工程師們必然不會那麼快把問題釋出來給顧
問解決，除了那些顯而易見，無法隱藏在將你找來當顧問的主導者眼前的問題外，多數
問題是隱藏在每個工程師手中的。
除了解決僱我當顧問的主導者提出之問題外，我常常在到現場的期間，踱步於各個工
程師間，看看他們在寫什麼程式，當我發現某個工程師在一個畫面中停留許久時，我會
趨前詢問他現在的工作是什麼，十之八久我會得到一個問題，當我快速的解決他所遇到
的問題後，我就得到了他的一分信任，持續這種模式不久之後，我便得到了他的信任與
尊敬，這不僅來自於解決他的問題，也來自於我設身處地為他分憂。
藉由了解各個工程師的工作內容，我對於專案的掌握度也越來越高，當專案發生大問
題時，我總是能夠由片段資訊知道誰的程式所致，或是那種設計所致，而這些，也是我
技術顧問工作的內容之一。
刁鑽的需求
使用者總是會提出一些刁鑽的需求，而業務也總是為了達成業績而答應該需求，我的
另一個工作便是評估這些刁鑽的需求是否可行，這通常會得罪一部份的工程師。
舉個實景來說，業務在得到需求後，多半會詢問負責的工程師該需求是否可能達到，
而工程師多半只會有兩種回答：1、這可以做到。2、這做不到。當有了技術顧問後，業
務在得到第二個答案後，會轉過來詢問我這是否真的無解？此時我也會有與工程師相同
的兩種回答，只是！我回答做得到的機率高了許多，此時工程師就會不爽我的介入了，
不管他能不能做到，被反駁總是感覺不好。
面對這種情況，我通常會做比平常更多的事，不僅是給一個示意如何解決問題的小範
例，而是給一個易於整合進現有程式的範例，以此來減輕工程師的工作量。這一方面不
會讓工程師有，你三言兩語我就得做個半死的感覺！另一方面則教育了工程師，你後面
有我撐著，放心大膽的衝吧。這些也是我技術顧問工作的內容之一，呃！我忘了提一件
事，我由此獲得了業務的信任。
高樓平地起，系統架構
雖然，多數情況下我總是在專案進行間介入，但偶爾也有機會在專案開始前介入，這
多半是伴隨教育訓練而來的顧問工作，這種模式有些不同。
這兩年，這類工作出現了3次，很有趣的都是同樣的模式開始，然後同樣的模式結束。
一開始，我們只是談一個教育訓練，在上完課後，我很自然的轉為專案開發的技術顧問，
此時這種顧問模式與前述有很大的差異，一來因為學員剛接觸一種技術，生產力低的
很，甚至怎麼開始開發專案都懵懵懂懂，在沒有技術顧問引導的情況下，專案的進行會
非常緩慢，而且走叉路的情況會層出不窮，相信許多專案主導者對這種情況都有深刻體
驗，第一個系統總是無用的，人月神話一書證實了這點。
這時技術顧問的角色就顯得很重要，他必須扮演一座明燈，引導所有人走向正確且不
會失敗的方向，這是一個Key Man，也是一個系統架構師的角色。
舉個實景來說，我有個客戶是要開發一個.NET平台上，WinForm的應用程式，該應用
程式有數百個維護介面及報表，在初期！我提供了一個N-Tier的應用程式骨架，這包含
了Plug-In、Cache、Session、Configuration等機制，並教育專案參與人員熟悉這個骨架，
然後一步步的往外擴散，該專案進行了一年，順利的完成所有功能。
當然，期間有許多旁支，我提供了例如Callback、Transaction、Multi-Server Processing
等做法的實作品，讓專案設計師可以專心在滿足需求，而不需費心研究這些技術。
這是我技術顧問工作內容之一，讓專案順利的進行，必要時，小幅介入實作，提供某種
技術的解決方案實作品。
簡單問題複雜化，人員的持續教育
與一般工程師不同，技術顧問的工作是短暫的，常在專案結束後就離開了，少部份的
工作有持續性，例如我在知名日商的某專案結束後，被要求轉往另一專案任職，不過！
當時我因為時程太滿而沒有答應。
由於技術顧問的工作短暫，我多半會嘗試在任職期間訓練一個分身，這個人通常是該
團隊中最具求知慾，同時也最具有潛力的人，對於他所提出的問題，我多半會花較多的
時間來教育他。
請別誤會，這不是差別待遇，而是工程師分成很多種，一種是將寫程式視為謀生技能
，永遠只學習足夠應付的技術，對於這類人，給了解決方案還要學習該方案的設計及實
作精神，太浪費時間了。
那我如何找尋這個分身呢？很簡單，我常在任職顧問期間提出架構方案，例如可容錯
的Application Server設計、可抽換式的設計、可延伸的架構設計，當這類方案出現時，
會持續詢問裡面細節的人，就有成為我分身的潛力。
許多人曾問我，當我把這些教給了分身後，我的價值優勢就不在了不是嗎？呵，這
或許可以解釋為何我在同一家公司的顧問生涯不會超過兩年，這也可以解釋為何有些顧
問不會將實作品給客戶了。
但對我而言，這是我技術顧問的工作內容之一，教育某人成為專案的領導者，能在我
不在時，持續讓專案進行。我是否未來會沒工作？呵，這我倒不擔心！
面對現實，軟體工廠化
幾年前，我接到了一個顧問工作，工作內容很簡單，他們有一個具龐大用戶端的應用
程式，早期發包到大陸撰寫後拿回台灣，接著分發到數量相當龐大的客戶端，但問題是
該程式運作不正常，偶爾會直接消失在螢幕上，這可不得了！這是一筆千萬的生意，如
果因為這個問題而引發退貨，那真的是吃不完兜著走。
我在到現場的第一天，由LOG檔及原始碼中找到了引發此問題的蛛絲馬跡，提出了一
個解決方案，但很不幸的！這個解決方案必須更改每一隻子程式，而這些子程式的數量
眾多，簡單的說！這是一個開發初期就犯下的錯誤，而因為量產的緣故，使得同樣的問
題不停的被複製，造成今天這步田地。
這就是我們常說的軟體工廠化的後果，其實問題並不在軟體量產，而是在系統架構設
計上，由於缺乏一位極有經驗的主導者、Key Man，使得部份一知半解的工程師完成一
個功能後，其它更為資淺的工程師盲目跟隨，最後軟體量產了，應用程式以很快的速度
完成，但！問題也用很快的速度複製到每一個子功能，SQL Injection便是由此而來。由
此可見，一個專案中，有經驗的人是多麼重要。
那最後我是如何解決這問題的呢？我提出了一個架構，先減少當機次數，爭取到更多
的時間，再與大陸的工程師進行視訊會議，教導他們如何解決現今的問題。
軟體量產雖會把問題量產，但在解決問題上，也是量產的。
技術顧問存在的理由
有些人在我詳述了以上這些工作經歷時，狹義的將我的工作稱為【Trouble Shooting】，
也有些人廣義的將其稱為【系統架構師】，我必須說！這兩者都是正確的，端看我於何
時介入專案的開發。
技術顧問存在的理由，一部份是因為工程師的經驗不足，一部份則是工程師對於新開
發技術的掌握度不足，兩者對於專案的成功率都有關鍵性的影響！
以下四點，是我當技術顧問的道義，寫下這篇文章以警惕自己，別在忙碌時忘了最初的理念！
- 在我的認知中，技術顧問不是一個坐在位子上等人來問，而是一個時時主動接近工程師尋找問題的人。
- 技術顧問更不是一個抱著理論不放，高談闊論某個架構的優秀性，某個技術的先進，而遲遲未提出一個實際解決方案的人。
- 技術顧問更不能是一個抱著技術不放，回答問題時還分階段，等到問題出現時才推說當初回答的並不是這個意思，不教而殺謂之罪。
- 技術顧問不是工程師，不能實際參與專案的開發，所以沒有實際的生產力，但他卻有助於提升所有工程師的生產力。
