技術顧問在做什么？
記得，以前曾經聽過一個笑話，有個顧問在印名片時，發現印名片的廠商把名片上的頭銜印錯了，印成“專業顧門”，於是該顧問打了個電話給廠商。
顧問：喂，你們搞什么啊，怎麼會把名片上的頭銜給印錯啦？頭銜上的門少了一個口！
廠商：真不好意思，我們會立刻改正重印，明天就能給你送上了。
翌日，顧問收到了廠商重印的名片，該廠商還很貼心的主動多送了一盒，只是顧問看了一下名片，差點沒昏倒，名片上印的是“專業顧門口”！
我常講這個笑話，起因是許多朋友或是剛認識的人在問及我的職業時，我總是笑著回答：“我是專業顧門口的！”
有些人聽到會會心一笑，有些則是狐疑以待，這時我就會開始講這個笑話了。
接下來會問的問題倒是統一的很，就是問技術顧問的主要工作內容，這是一個需要花時間回答的問題，我常以“就是回答客戶所提出的任何軟體技術問題”來搪塞，呃！你我應該都清楚，這是事實，但不是完整的事實。
踏入技術顧問這行是一個因緣，當年我在結束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”，也有些人廣義的將其稱為“系統架構師”，我必須說！這兩者都是正確的，端看我于何時介入專案的開發。 技術顧問存在的理由，一部份是因為工程師的經驗不足，一部份則是工程師對于新開發技術的掌握度不足，兩者對于專案的成功率都有關鍵性的影響！
以下四點，是我當技術顧問的道義，寫下這篇文章以警惕自己，別在忙碌時忘了最初的理念！
在我的認知中，技術顧問不是一個坐在位子上等人來問，而是一個時時主動接近工程師尋找問題的人。
技術顧問更不是一個抱著理論不放，高談闊論某個架構的優秀性，某個技術的先進，而遲遲未提出一個實際解決方案的人。
技術顧問更不能是一個抱著技術不放，回答問題時還分階段，等到問題出現時才推說當初回答的并不是這個意思，不教而殺謂之罪。
技術顧問不是工程師，不能實際參與專案的開發，所以沒有實際的生產力，但他卻有助於提升所有工程師的生產力。
文章鏈接：http://www.cnblogs.com/petermsdn/articles/1353504.html
【編輯推薦】
