技术顾问在做什么？

记得，以前曾经听过一个笑话，有个顾问在印名片时，发现印名片的厂商把名片上的头衔印错了，印成“专业顾门”，於是该顾问打了个电话给厂商。

顾问：喂，你们搞什么啊，怎麼会把名片上的头衔给印错啦？头衔上的门少了一个口！

厂商：真不好意思，我们会立刻改正重印，明天就能给你送上了。

翌日，顾问收到了厂商重印的名片，该厂商还很贴心的主动多送了一盒，只是顾问看了一下名片，差点没昏倒，名片上印的是“专业顾门口”！  

我常讲这个笑话，起因是许多朋友或是刚认识的人在问及我的职业时，我总是笑著回答：“我是专业顾门口的！”

有些人听到会会心一笑，有些则是狐疑以待，这时我就会开始讲这个笑话了。  

接下来会问的问题倒是统一的很，就是问技术顾问的主要工作内容，这是一个需要花时间回答的问题，我常以“就是回答客户所提出的任何软体技术问题”来搪塞，呃！你我应该都清楚，这是事实，但不是完整的事实。 

踏入技术顾问这行是一个因缘，当年我在结束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