一直嚷嚷着要成立的自动化团队,终于有些具体的动作了,芬兰的专家赶过来,开始做一些他们的自动化测试框架软件的培训。说是培训,我想也可以叫做是推销吧,呵呵~谁叫他们的目的是让我们学习使用它,并推广到Regression Testing中去,不就是在向我们推销这个工具和他们贯彻其中的自动化的理念么~
不过,这也意味着我们TA组也可以真正的转化成一个支持性的部门,从以前号称的virtual团队,浮出水面,为RT的工作提供支持。虽然目前是由我们负责,等到这个TA的要求逐渐实施下去,应用的面越来越广,那么我们的角色势必要转化为背后的支持部门,提供技术支持。心里还是蛮激动的~
培训过程中,Bjorn更想传达给我们的,是他们设计这个工具的理念,确保我们理解他们的设计初衷后,再才是更深入传授使用的方法,而具体的编程技术,似乎他们并不会cover,就如他时常说到的一样,I will not go to the details..
如果将自己的位置定位在做一个TA的专家级人物,那么象Bjorn这样负责一个工具的设计开发,负责策略的制订,我想应该相当高,且需要相当程度的奋斗吧?只是他所做的事情,和我现在所做的工作又多少的关联呢?我一直在考虑,是否每一个fresh都需要经历迟缓漫长的发展道路,才能够成长为一个技术专家、管理者,或者其他什么从公司结构上来说更高端的职位呢?
让我来想象一下Bjorn这一级别人物所要做的事情。首先有数不清的会议要参加,作为一个支持性的部门,更需要沟通。还要为TA商量策略,制订一些框架,如何做才是合适的,也要不停的沟通,协调。也许还有其他的任务,但是我想,真正的编码却是最最次的一项,它绝对不再是一项需要投入相当多精力的活动。
建立在这样的猜想之下,我想,应该这也是目前真实的现状,我觉得无法理解coding的经验对于提升到这样的职位有多大的帮助。我相信提升更需要的是证明你可以胜任它,你可以持续不变的提供稳定的可保证的工作质量,也许你技术能力很强,工作很努力,可是没有人知晓,又或者你不能提供满足要求的工作质量,或者你无法持续稳定的展示高标准的工作表现,那你可以预见,你的升职之路不会那么的平坦。而最重要的,是沟通。
沟通,英语中对应的单词是communication。事实上,说是communication对应的中文词是沟通也许更加贴切。在中国人的思想中,并不太在意沟通,更多的将它看作是无须重视,很自然对方应该理解, 不重视沟通。中国人其实有着很强的自信,以及自尊,只是他们可以压抑和控制强烈自信的能力不同。中国的情况相当复杂,有着庞大的民族体系,却有着比例巨大人口也很多的汉族人口,至少从语言的角度来看,交流是流畅的。而外国人,印度是一个种族更加复杂,方言也更多的国家,其他国家或是国家大小,或是历史原因(比如美国吸收了如此多的移民),或者各个行政区划的不同,导致一种现象,那就是他们的交流通常会失败,如果他们不注意沟通的话。谈话的基准点不一样,交流就会出现困难,西方人也许由于地域的原因,与不同文化的人交流机会多,或者因为周遭环境使然,要求进行大量沟通,典型的就是美国,它吸纳来自世界各地的移民,他们带来不同的文化、语言、生活习惯、交流方式等等等等。任何事物的成败都离不开一个基础,交流也不例外。没有统一的基准,交流就会偏离方向,如果每个人都在对牛弹琴,它最后的结果只能是无疾而终。
举一个很简单的例子,看见一个女孩子,一个人说“好漂亮”,另一个人看看,说“啊,这也叫漂亮,一点都不行嘛”,甚至可能发生激烈的争吵。他们错了吗?没错,他们都坚持着自己的判断,从他们各自的标准来看,都没错。只是他们都忘记了一点,那就是:对方的标准和我一样吗?他清楚我的标准如何吗?如果他们曾经想到去了解彼此的评判标准,就不存在这样的争论。A喜欢高鼻梁,单眼皮,身材丰满点的女孩,也许B却更欣赏嘴唇丰满,双眼皮,身材修长,瘦瘦的女孩,那么同样的一个女孩子,他们就会有不同的评价。或许他们唯一互相赞同的时刻,就是一个不具备他们所喜欢的任何一样标准的女孩出现时。。。
回到前面的话题,沟通的重要,就是确保从公司高层商讨决定的具体决策,或者公司的宗旨,能够一直传递到企业职位链的最低端,就是每个具体的低层职员。他们要确认领悟的做事的准则,从而确保大家所努力的都是同一个方向。人,有不同的个体,不同的理解思维,能够确保你的属下达成同样的认识,这也是一项十分艰巨的任务。企业的航船,重要的是方向,越是大的企业,越害怕方向错误,因为调头太难太缓慢。
还有一种技能,也是高端职位所要求的,那就是大局观,它体现在制订策略方面。可笑的就是,它要求在位者可以跳出具体技术的框框架架,去省视更加high level(相当多manager级别人物的口头禅)的事物。正如相当多的architector所言,我不care具体的实现技术,是C或者是Java,使用了DB2或者是Oracle的数据库等等,并不是我关心的重点,真正的核心,在于实现需求,我需要达到什么样的性能,所实现的系统具有什么样的特性。实现的系统可控制,可预知,这更加重要。你可以实现一个程序,它提供文件阅读,可是它应该是可控制的,它所能阅读的文件类型可控制,它应对错误出现的措施应该可预知,等等。甚至是,它和外部的接口应该是已知的,要从整体来考虑问题,知道它可以实现某个功能,能实现到某个程度,对于已知的错误有处理,处理到何等程度,对未知的程度可以做出什么样的处理,这需要经验,这是一种难以获得的经验,也是高端人士最主要的区别之处。你所考虑到的方面更多,相对而言,你的思考也更加成熟,因为你可以处理更多的可能情况,当然,我也要排除一些杞人忧天的情况,他们无益于决策,反而是增加负担,这取决于决策的策略取舍,呵呵~~
一个很疑惑,甚至持续许久的疑问,我究竟需要专注于技术的细节么?让我自己给自己一个答案,也希望大家来帮着我评判,看看大家的看法。
一种看法是,专注于技术是一种发展方向,它要求精通某项具体技术的细节,底层特性,成为领域的专家,或许他丝毫不了解任何的项目管理的思想,但是当项目管理者需要征求他对于此技术的实现细节,或者以他的经验来为项目管理提供某些参数的估计值时,他可以以他深入的理解来提供信息,毫无疑问,这就是顶尖级的技术专家,也就是那些与Gosling、Eckel一类的人物。
另一类,他们有相当的专业技术实践经验,也有建立在此基础上的丰富项目管理经验,他们将精力集中在某两级实施的中间交接部位,主要指那些各个领域的专业顾问们。他们有着或具体技术,或管理或其他领域的专业知识,同时具备一定程度的其他知识,他们专注于这两方面之间的结合部位,提供平滑过渡的建议、指导。举个例子,SAP的顾问,他们负责将管理的观念灌输给项目的技术人员,并确保他们在这样的思想下实现技术细节;又或者Mark,他是一个Testing顾问公司的雇员,拥有丰富的编程及测试和测试自动化经验,也作为一个项目管理者具有充足的工作实践,而今他致力于提供给客户专业的指导来实现测试自动化,不止是那种思维,包括一些细节的实现,他都可以提供咨询。
还有一类呢,则更加的特殊。他需要更少的实际技术实践经验,更多的是管理方面的知识。也许,作为一个IT行业,计算机专业的产品,我不应该期待着这样一个并不合适的职位,对吗?他大致的知道某些技术可以做到或者无法做到,能够或者不能实现他所需要的功能,具体的需要和一些技术人员进行确认,但是他可以决定一些更high level的方向,甚至协调以确保这样的工作不会影响到技术人员处理其他的工作,又或者确保一些相互沟通的策略,比如在需要沟通的时候,他们能够毫不费力的找到负责人进行交流。
说了如此之多,看来并不太是点滴了,呵呵~~
夜深了,也许零下的温度冻结了我的思维,反应的速度也变得缓慢,头越发的发涨,这已经不是一天两天的事情,都不清楚它为什么痛,也就随它去吧。。。
晚安,希望到访的朋友可以留下你宝贵的意见,留过言的朋友,我确实都仔细地读过你们的留言,很感谢你们,或许我没有回复你们的发言,请相信,我很感激你的光临!
确实很难想象我会想要做一个技术专家。。但是未来地事情谁说得准呢
你觉得自己的优势是什么呢,扬长避短嘛,我感觉你不会希望自己成为技术专家。