曾經有這樣的試驗，隨機選擇一組對象進行工作的自評，幾乎所有對象的自評分都在實際成績的平均分以上。在工程師團隊中也不例外，許多工程師有這樣的困惑，自己覺得工作已經做得不錯，但是上司好像察覺不到，甚至還對自己的工作吹毛求疵。如果有個合適參照標準，工程師或許就可以更好的對自己工作進行自評。

　　管理者也同樣面臨類似困惑，在一個組織中，需要定期對團隊中的成員進行考核及晉升，但是考核的標準是什么？小團隊中主要取決于管理者的意志；大型組織中流程會更規范，但也存在考核者憑感覺來給被評估者打分的情況，或者是考核者心中的衡量標準千差萬別。

　　從工程師自我提升追求及職業規劃的角度，情況會更復雜。每一個工程師都有不同的追求目標，孟巖有一篇很有影響力的《技術路線的選擇重要但不具有決定性》，文中工程師的追求類型被描述成事業目標型、團隊精英型、技術高手型、得過且過或養家糊口型四種。文中將“獨特的個性知識經驗組合”看做是工程師的核心競爭力，不過對于這個經驗的組合不同人會有不同的理解。

　　從團隊或者企業的角度來看，主要從團隊的貢獻角度來評估技術工程師的成績，就如同評估一個科學家的成績看他對人類的貢獻類似。離開了環境，單純評估技術沒有意義。比如一個技術人員對Linux內核看得滾瓜爛熟，單就這一點并不能看到太大直接價值。

　　但是在業界，知識點的重要性通常被放大了，業界也形成了一些非理性的氛圍。工程師會努力學習某個技術(如C++語言)的方方面面，即使大部分場合只用到了其中小部分功能。技術管理者在招聘、考核、晉升等過程中也通常把知識點放在一個很重要的地位，面試題中會出現工作中并不常用的領域的各種知識點。

　　這跟前幾天某條關于大學教育的微博有異曲同工之妙，大學教育經歷了全部是知識點的教育，慢慢意識到需要培養的能力不僅是知識點，而主要應是獨立思考能力。

　　技術人員追求的也不僅是知識點，而是在專業領域正確做事的方法及達成目標的能力。兩個同時入職的員工，一段時間后技術好的那個就發展得好嗎？還是有更好做事方法及能達成目標的人更容易得到認可？

　　我認為一個好的工程師必要的能力 ——

　　設計能力

　　設計能力參見前文技術評審中關于設計的描述，簡要的說就是具備設計簡潔、易于擴展及維護的功能及特性能力。

　　需要補充一個設計方面的anti-pattern，選擇合適的技術及架構，意味著不引入及增加不必要的抽象層或框架，并提供高質量、穩定、高效、安全的代碼。不少能力還不錯的人員有這個缺點，一個簡單的項目，出于追求流行或者對于某項技術的崇拜心理，引入了復雜的技術或框架，對于個人來說確實提高了見識，增加了業內交流的資本，但是對于組織來說這種鍛煉卻是團隊成效的噩夢，對于技術從業人員來說，不盲目引入不必要的高深技術來保證項目進展是一種基本的職業素養。

　　此外，設計中還有一個隱含的條件，就是選擇的方案能相對減少開發周期，加快交付時間。也就是下一點介紹的。

　　交付能力

　　通俗的說就是不管發生了什么，都能按時交付。
　　充分考慮自身技術能力、項目依賴、隊員排期沖突、負面情緒、技術方案風險、未預知的技術障礙、需求變化等。
　　具備為功能的設計做取舍的能力，但功能取舍并不以犧牲產品的核心愿景為前提。

　　規范與協作

　　在編碼前能夠完成模塊或特性的清晰架構或設計文檔，并保持在開發過程以及代碼重構過程中文檔的一致性。
　　推動及促進團隊的代碼及設計規范，并確保執行過程中與規范的一致，并能根據實際情況對流程及規范提供優化建議。
　　編寫的代碼通常當做團隊的模板或者是最佳實踐的設計模式。

　　團隊效率貢獻

　　有改善團隊效率方面的貢獻嗎？比如做一個相似項目為何周期很長？為什么開發完成之后又花了比開發周期更長的時間調試或修改bug？
　　推進代碼復用，你的代碼和工具其他小組或部門愿意用嗎，準備讓他們用嗎？有推動讓他們用嗎？
　　能夠用自動化體系來幫助提高測試、開發、debug、跟蹤用戶問題的效率。
　　能夠用服務化的方法來解決異構、多版本問題。
　　有優化流程貢獻？

　　已經不是那個獨行俠或個人技術英雄的時代了，融入團隊，多考慮對團隊的貢獻，更容易得到成長。

　　后記：職業發展方面話題比較大，不容易寫好，本文也寫得比較辛苦，改了兩個晚上，暫不寫類似話題。這也再次說明，當你有一個非常大的愿景（想當青年導師？），但系統能力還跟不上時，更應從小處著手。

it知識庫：技術工程師的能力與目標，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。