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