技术顾问在做什么?

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

顾问:喂,你们搞什么啊,怎麼会把名片上的头衔给印错啦?头衔上的门少了一个口!

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

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

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

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值