如何做一名成功的IT工程师？
进入到 IT这个圈子，很多人是从工程师开始做起的，那么如何成长为一名成功的工程师呢？或者是如何成功地转换为下一个角色呢？你需要做哪些准备呢？作为 MDE（Market Development Engineering）的工程师和产品开发的工程师，还是有些不同的，我下面重点想说的是比较通用的，关于MDE的工程师，或者类似的做技术支持的工程师，我想后面再单独写一篇。
让我们先来看看成功的工程师是什么样子。在Sun公司里，工程师分为4个级别，从低到高依次是工程师（Engineer），高级工程师（Staff Engineer），杰出工程师（Distinguish Engineer），科学家（Fellow）。在工程师这个级别里又分为MTS1-4，也是依次从低到高的。Fellow，SUN公司总共没有几个，James Gosling是其中的一个，Bill Joy也是，最近离开SUN了，去开startup了。Sun的中国工程研究院（ERI）原来有DE，就是宫力，现在已经他离开了，暂时还没有。 Staff Engineer，ERI有几个rotation过来的。不知道大家是否还记得James Liu，在MDE week上给大家烧烤的那个，他是Staff Engineer, 但我记不清楚他是否Senior Staff了。
那么这些不同的级别的定义是什么样子呢？要求是什么样子呢？我们分别来看看。一名MTS3的工程师应该可以独立地设计和实现一个解决复杂问题的解决方案，制订项目计划，并确定短期战略目标。对于MDE的工程师，应该可以独立地支持一个ISV，从技术评估，技术培训，移植的技术支持，性能调优，选型测试等。当然，并不是说MDE的工程师可以自己把所有这些全部完成，但是他/她在遇到阻碍的时候知道通过什么渠道来解决问题。MTS4的工程师，可以解决更复杂的问题，通过领导一个团队，独立地设计和实现一个复杂的项目，这样的一个项目通常都需要和其他的团队进行协调和沟通，并利用或组合其他团队的工作。一个MTS4工程师要有能力给其他低级别的工程师提供技术建议和指导。从MTS4到Staff Engineer是一个大的台阶，作为Staff Engineer，应该是在组内和组外都公认的专家，拥有解决复杂问题所必须的技术知识和商务知识。Staff Engineer和Engineering Manager是在同一个级别上的。
从一个MTS1或MTS2工程师做起，怎么准备自己走到下一步呢？一个很重要的概念就是管理自己：管理自己的目标，管理自己的时间，管理自己与其他人的沟通。
第一，要给自己设定一个目标，可以和自己的经理聊聊，自己的下一步在哪里，自己的优势在什么地方，通常他们会给出比较诚恳的建议的。我建议在制订这个长期的目标的时候也不要太长，比如说10年，那就太长了，说老实话，在20-30岁的这个阶段，3年后发生什么事情我们很难预测。所以我建议这个目标可以订的短些，比如2-3年。
第二，结合长期目标，给自己制定短期目标，比如说一年的，半年的，一个季度的，等等。制订目标的时候，有个 SMART方法，想必大家都知道：s（specific，具体的，不能说空话，要用数据和时间说话）、m（measurable，可衡量的）、 a（agreed，双方都同意的）、r（realistic，可实现的，可以达到的）、t（timebonded，有时间性的，可以考核）。
第三，在设定的时间，回顾自己的目标，检查完成的情况，如果没有完成，要总结是什么原因，并适当调整目标。
第四，管理好自己的时间，检查自己的大部分时间都在做什么，是不是在做最重要的事情，是不是大部分时间做了些不重要的事情，可是最重要的时间却没有时间做。管理时间需要对自己的工作进行优先级的评估，优先处理最重要的工作。发现了问题之后就要调整自己的习惯或方式，节约时间。随着你的级别越来越高，你会发现你的时间越来越少。可是你的加班不能无限延长，你还需要时间陪伴你的家人，你也需要时间休息。
第五，积极地学习。活到老，学到老，这句话没有错。有的工程师发现了一个正在进行BETA测试的新产品，认为对自己以后的工作有帮助，就马上拿来装上使用一番。有的工程师经常阅读和自己工作相关的各种标准和规范，对提高自己起了很大的作用。学习的范围要逐渐的宽一些，不要总是局限在纯粹的技术上，可以适当地学习些软技巧或商务等方面的知识。
第六，能够做决定。一个级别高的工程师，有责任做相应的决定。你的老板不会为你做所有的决定，你需要和你的老板商量，哪些是你应该做决定的，自己要把这些责任承担起来。最重要的决定是决定要做什么，如果这个决定没有做，那么尽管工作得再漂亮，到最后可能发现原来根本就是浪费时间。为了做正确的决定，你需要搜集相关的信息，没有足够的相关信息，可能做出的决定也是错误的。
第七，积极地沟通。谁是你最重要的客户？或者最重要的stakeholder？你的工作对谁影响最大？不要被动地等他们来找你，而是主动地去找他们，询问他们最关心的是什么，利用你的知识和经验，向他们建议哪些对他们最重要，提前和他们沟通项目计划，等等。工作展开后，要有定期的状态更新，碰到计划为的状况的时候，要立即和相关人员进行沟通。另外，找机会多和一些比你级别高的人或更有经验的人聊聊，有时候他们给你的一个建议，或无意中说的一句话，都会给你很大的启发。和他们的聊天，也经常能够给你些激励。
第八，认真地写报告。很多人不重视写报告或技术文档，这不利于工程师的成长。写报告是沟通的重要的环节。写报告的时候，首先要确定你的报告是写给谁的，谁在关心这个报告，关心的内容是什么。可以把自己想象成看报告的人，最想通过这个报告了解什么。报告也不仅仅是给你的老板看的，对于MTS4或者更高级别的晋升，是需要跨部门的讨论的。在一个10-20人的团队里，大家可以容易互相了解，在一个100人的团队里呢？就无法做到这点了。怎么让其他的团队里的人了解你的优点和技术专长呢？如果他们看到过你的报告，是很容易判断的。
总而言之，首先要定义自己的目标，然后学习和实践，通过证明自己的能力，最后的成功是水到渠成的。
我在MDE这个团队做了4年了，基于过去的经验，谈谈做MDE工作的感受吧。做MDE的工程师，和售前，售后，服务的工程师的工作有一定的相似性。MDE 的全名是Market Development Engineering，所做的工作是帮助ISV在Sun的平台上进行开发，为他们进行移植，性能调优，测试提供技术支持，目标就是让ISV的产品在 Sun的平台上运行得最好。MDE的工程师和服务部门的工程师是有区别的，服务部门的工程师按照合同为客户提供所需要的服务，比如帮助客户进行架构设计，进行系统开发等等，是工程项目的主体，而MDE的工程师是在项目中提供支持，支持客户（ISV）的工程师完成工作。MDE的工程师和做产品研发的工程师更是有区别了，不说大家也都明白。
目标和计划
MDE的工作需要我们积极主动地开展，而不是被动地等待。如何能作到积极主动呢？态度非常关键，我们需要用积极主动的态度，来驱动我们制订目标和计划，用目标和计划来保证积极主动的行动。我们每个财年都要做制订目标，这个目标里其实包括了三部分内容：为部门的目标所做的贡献；个人的目标；还有就是我们的客户计划。为部门的目标做贡献，很容易理解，但是怎么和个人的目标结合在一起呢？自己的兴趣在什么地方？自己需要在什么地方得到发展？能达到什么样的水平？举个例子，我们今年的重点是推动Solaris，我的强项是Java，我就希望自己今年在 Solaris方面的技术水平得到提高，这就是我今年的目标。具体些，我会希望自己参加一个有深度的培训，学习1-2本经典的书，比如Solaris Internal；研究并掌握一项关键技术，比如Dtrace；发表一篇技术文章，比如如何使用Dtrace分析和解决I/O瓶径。客户的计划也是很重要的，我们的ISV最需要什么样的支持？困扰他们的是什么？他们今年的产品计划是什么样子？比如我有个ISV，他们打算把应用从某平台转到UNIX平台，我会了解他们计划在什么时候开始做移植工作，他们的应用是用C开发的还是Java，他们的客户对性能的要求是什么样子，他们要测试的硬件需求是什么样子，需要多少颗CPU的机器，多大的存贮等等。这些内容都是客户计划中的重要内容。
有的时候目标和计划的制订比较容易，但是完成计划会碰到困难。有人制订了发表3篇文章的计划，可是到Q3的时候还没有一个出来，问问情况，肯定会有很多理由，仔细分析，有些是真正的理由，有些则似乎是找的理由。我和一个同事聊过，我问他还有四个月，文章还没写，也没有具体的实施计划，所以说这个3篇文章的计划，倒象是一个愿望。这里有个关键的问题是行动没有和目标结合起来，也就是说没有具体行动的计划。怎么样才能够有具体的行动计划呢？可以给大家举两个人写文章的例子。一个是王昱，他在工作中感觉到很多人对 J2EE的集群特性并不了解，于是就计划写这样的一篇文章，先是阅读一些文章，包括J2EE的规范等，然后把自己的思路写成幻灯片，感觉可以把幻灯片讲给听众了，再把内容填进去，写成最后的文章，最后发给相关的编辑进行审核，很快就发表了（链接）。另外的一个例子是张欢，她帮一个ISV解决了设置应用服务器SSL的问题，感觉这个问题很可能也会被其他的用户碰到，于是就把自己所碰到的问题，解决的方法，理出一个思路，然后整理成文章，最后是和编辑联系审核，发表得也很快（链接）。
管理时间
管理时间的概念里很重要的一点是，对于承诺的事情，要在规定的时间里提交结果。很多人都有这样的体会，原本计划做一件事情，在查资料的时候，发现里面有很多自己不熟悉的，于是顺着线索一路搜索下去，又是查资料，又是写测试程序，结果到了规定的时间，被问到为什么该提交的报告还没出来的时候，才发现自己在研究一个离原来的目标很远的题目，而且这个题目和自己原本的任务的关联性并不是很大。
另外一点是读邮件，相信大多数人都订阅了很多邮件列表，每天早上来的时候，会收到几十甚至是上百封邮件，怎么去看？如果按顺序从头看到尾，每封邮件都看，可能这一天都看不完邮件，那就什么都别做了。我也曾经有过这样的阶段，感觉自己一天都是邮件的奴隶了。我现在的做法是，针对技术邮件列表做过滤器，把和技术相关的放在一个特别的目录里，这样在看的时候，已经有很多都被过滤了，那些邮件基本上都不是紧急的，是作为信息来使用的，如果有时间我就会去看，如果没有就算了。处理收件夹中的邮件时，可以快速扫描标题和发件人，首先看紧急的，然后看其它的。对于能够在1分钟内就可以回的，马上回掉。如果需要等的时间比较长，比如几天，可以先给对放回个邮件，告知已经收到邮件，正在处理，可能会在几天后有结果。
做决定
做为 MDE的工程师，每个人都是需要独立地和ISV工作的，每天都和ISV接触，可能做许多决定。那么怎么做这些决定呢？是不是都需要请示上级呢？如果没有规定好的流程或策略，我们自己怎么来做决定呢？首先要清楚自己能做决定的范围，以及规定好的流程和策略。如果是在自己的范围内，但是没有可依据的流程和策略，怎么办？playbook是一个帮助我们做决策的很好的工具。很多公司有会设置这样的playbook，而且还会逐级向下，在各个部门也建立 playbook，playbook里会简明扼要地阐明公司或部门的发展目标或者优先级等。例如我们公司的playbook里确定了FY06的优先级(链接)是：
1. Make Money
2. Grow
3. Capitalize on Our Acquisitions
4. Leverage Our Partners
5. Re-enlisting Champions
6. Simplify Our Business
当我们遇到不知道该如何做决定的时候，就让playbook来帮助我们做决定。我们要做的事情和部门的目标是否一致？和公司的优先级是否吻合？playbook会告诉我们答案。
做决定还要及时。我们的工作中肯定会碰到些棘手的事情，难于做决定。有时，如果我们追求完美，一定要等待各个方面都充分准备好，或者是等待自己准备好，可能要过一年半载了。学会取舍，懂得“鱼和熊掌不可兼得”，用必要的丧失来（上大学的时候读过一本书，叫必要的丧失，是美国作家维尔斯特写的，当时感觉还是比较晦涩难懂）磨练心智，是成长过程中不可缺少的部分。
积极地沟通
有人说成功的职业人士有75%来自有效的沟通。沟通对于每个人都是重要的，尤其是对于MDE的工程师，因为我们要面临很多需要沟通的方面，而他们的角色还完全不同：内部的人员包括客户销售代表，合作伙伴销售，硬件销售，软件销售，产品开发工程师，产品维护工程师，外部的包括总代，集成商，ISV等各方面的商务和技术人员。和这些人的有效的沟通对我们的工作很关键。
我们在工作当中总会遇到这样那样的问题，如果问题是别人引起的，如何去提出（或解决）这些问题呢？有的人选择抱怨，或者强调客观理由，或者简单提出问题然后请对方解决。这些手段在大多数情况下都不能解决问题。比较有效的办法是首先确立一个比较好的心态，明白这个问题不是针对某个人的，就不会带着个人的情绪进来。然后客观地提出问题，还有，很重要的是能够提出建议，建议出一个解决该问题的方案。这样，非常有帮助于解决问题。
在我们和其他人沟通的过程中，有一点是需要我们特别注意的，就是避免产生让人吃惊的负面结果。比如说我在做一个移植的项目，ISV，我们的销售经理，我的老板，都知道这个项目，我也把SOW发给大家了，按计划在5月底完成。这里有个关键是某第三方软件目前还不支持Solaris，解决办法是联系这个第三方让他们移植，同时也劝说ISV采用一个开源的替代产品。我同时做这两方面的工作，但是不幸的是在5 月30日的时候得知，第三方不同意移植，ISV也不愿意采用开源的产品。我只好写个邮件向大家汇报这个不幸的消息。其他的人可能都不知道其中的细节，销售可能还等着移植完成后在6月中旬投个标，这下全泡汤了。这就是让人吃惊的负面结果。如何避免呢？在开始的时候就通知所有相关的人，存在这样一个关键点，并说明其重要性，这样还可以发动大家一起来帮助我的工作，销售可能会申请经费帮助第三方移植，也可能会劝说ISV采用开源的产品，在5月底的时候很可能顺利完成移植。即使没有完成，大家也不会惊讶，因为大家都有心理预期了，都会提前做了准备。
说了这么多，都是软技巧方面的。我想大家都清楚，作为工程师，在技术上一定要过硬。有了坚实的技术背景，加上逐渐丰富的软技巧，大家一定会把这份工程师的工作做得非常出色的！
评论