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

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

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

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

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

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

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

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

設計能力

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

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

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

交付能力

通俗的說就是不管發(fā)生了什么，都能按時交付。

充分考慮自身技術能力、項目依賴、隊員排期沖突、負面情緒、技術方案風險、未預知的技術障礙、需求變化等。

具備為功能的設計做取舍的能力，但功能取舍并不以犧牲產(chǎn)品的核心愿景為前提。

規(guī)范與協(xié)作

在編碼前能夠完成模塊或特性的清晰架構或設計文檔，并保持在開發(fā)過程以及代碼重構過程中文檔的一致性。

推動及促進團隊的代碼及設計規(guī)范，并確保執(zhí)行過程中與規(guī)范的一致，并能根據(jù)實際情況對流程及規(guī)范提供優(yōu)化建議。

編寫的代碼通常當做團隊的模板或者是最佳實踐的設計模式。

團隊效率貢獻

有改善團隊效率方面的貢獻嗎？比如做一個相似項目為何周期很長？為什么開發(fā)完成之后又花了比開發(fā)周期更長的時間調試或修改bug？

推進代碼復用，你的代碼和工具其他小組或部門愿意用嗎，準備讓他們用嗎？有推動讓他們用嗎？

自動化體系來幫助提高測試、開發(fā)、debug、跟蹤用戶問題的效率

能夠用服務化的方法來解決異構、多版本問題

有優(yōu)化流程貢獻？

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