我在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月底的時候很可能順利完成移植。即使沒有完成，大家也不會驚訝，因爲大家都有心理預期了，都會提前做了準備。
說了這麼多，都是軟技巧方面的。我想大家都清楚，作爲工程師，在技術上一定要過硬。有了堅實的技術背景，加上逐漸豐富的軟技巧，大家一定會把這份工程師的工作做得非常出色的！