我在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的优先级(链接)是：
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月底的时候很可能顺利完成移植。即使没有完成，大家也不会惊讶，因为大家都有心理预期了，都会提前做了准备。
说了这么多，都是软技巧方面的。我想大家都清楚，作为工程师，在技术上一定要过硬。有了坚实的技术背景，加上逐渐丰富的软技巧，大家一定会把这份工程师的工作做得非常出色的！
