生活感言点滴

一直嚷嚷着要成立的自动化团队，终于有些具体的动作了，芬兰的专家赶过来，开始做一些他们的自动化测试框架软件的培训。说是培训，我想也可以叫做是推销吧，呵呵~谁叫他们的目的是让我们学习使用它，并推广到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的方向，甚至协调以确保这样的工作不会影响到技术人员处理其他的工作，又或者确保一些相互沟通的策略，比如在需要沟通的时候，他们能够毫不费力的找到负责人进行交流。

 

说了如此之多，看来并不太是点滴了，呵呵~~

夜深了，也许零下的温度冻结了我的思维，反应的速度也变得缓慢，头越发的发涨，这已经不是一天两天的事情，都不清楚它为什么痛，也就随它去吧。。。

晚安，希望到访的朋友可以留下你宝贵的意见，留过言的朋友，我确实都仔细地读过你们的留言，很感谢你们，或许我没有回复你们的发言，请相信，我很感激你的光临！