|
曾經(jīng)有這樣試驗，隨機選擇一組對象進(jìn)行工作的自評，幾乎所有對象的自評分都在實(shí)際成績(jì)的平均分以上。在工程師團隊中也不例外，許多工程師有這樣的困惑，自己覺(jué)得工作已經(jīng)做得不錯，但是上司好像察覺(jué)不到，甚至還對自己的工作吹毛求疵。如果有個(gè)合適參照標準，工程師或許就可以更好的對自己工作進(jìn)行自評。管理者也同樣面臨類(lèi)似困惑，在一個(gè)組織中，需要定期對團隊中的成員進(jìn)行考核及晉升，但是考核的標準是什么？小團隊中主要取決于管理者的意志；大型組織中l流程會(huì )更規范，但也存在考核者憑感覺(jué)來(lái)給被評估者打分的情況，或者是考核者心中的衡量標準千差萬(wàn)別。 從工程師自我提升追求及職業(yè)規劃的角度，情況會(huì )更復雜。每一個(gè)工程師都有不同的追求目標，孟巖有一篇很有影響力的《技術(shù)路線(xiàn)的選擇重要但不具有決定性》，文中工程師的追求類(lèi)型被描述成事業(yè)目標型、團隊精英型、技術(shù)高手型、得過(guò)且過(guò)或養家糊口型四種。文中將“獨特的個(gè)性知識經(jīng)驗組合”看做是工程師的核心競爭力，不過(guò)對于這個(gè)經(jīng)驗的組合不同人會(huì )有不同的理解。 從團隊或者企業(yè)的角度來(lái)看，主要從團隊的貢獻角度來(lái)評估技術(shù)工程師的成績(jì)，就如同評估一個(gè)科學(xué)家的成看他看對人類(lèi)的貢獻類(lèi)似。離開(kāi)了環(huán)境，單純評估技術(shù)沒(méi)有意義。比如一個(gè)技術(shù)人員對Linux內核看得滾瓜爛熟，單就這一點(diǎn)并不能看到太大直接價(jià)值。 但是在業(yè)界，知識點(diǎn)的重要性通常被放大了，業(yè)界也形成了一些非理性的氛圍。工程師會(huì )努力學(xué)習某個(gè)技術(shù)(如C++語(yǔ)言)的方方面面，即使大部分場(chǎng)合只用到了其中小部分功能。技術(shù)管理者在招聘、考核、晉升等過(guò)程中也通常把知識點(diǎn)放在一個(gè)很重要的地位，面試題中會(huì )出現工作中并不常用的領(lǐng)域的各種知識點(diǎn)。 這跟前幾天某條關(guān)于大學(xué)教育的微博有異曲同工之妙，大學(xué)教育經(jīng)歷了全部是知識點(diǎn)的教育，慢慢意識到需要培養的能力不僅是知識點(diǎn)，而主要應是獨立思考能力。 技術(shù)人員追求的也不僅是知識點(diǎn)，而是在專(zhuān)業(yè)領(lǐng)域正確做事的方法及達成目標的能力。兩個(gè)同時(shí)入職的員工，一段時(shí)間后技術(shù)好的那個(gè)就發(fā)展得好嗎？還是有更好做事方法及能達成目標的人更容易得到認可？ 我認為一個(gè)好的工程師必要的能力 設計能力 設計能力參見(jiàn)前文技術(shù)評審中關(guān)于設計的描述，簡(jiǎn)要的說(shuō)就是具備設計簡(jiǎn)潔、易于擴展及維護的功能及特性能力。 需要補充一個(gè)設計方面的anti pattern，選擇合適的技術(shù)及架構，意味著(zhù)不引入及增加不必要的抽象層或框架，并提供高質(zhì)量、穩定、高效、安全的代碼。不少能力還不錯的人員有這個(gè)缺點(diǎn)，一個(gè)簡(jiǎn)單的項目，出于追求流行或者對于某項技術(shù)的崇拜心理，引入了復雜的技術(shù)或框架，對于個(gè)人來(lái)說(shuō)確實(shí)提高了見(jiàn)識，增加了業(yè)內交流的資本，但是對于組織來(lái)說(shuō)這種鍛煉卻是團隊成效的噩夢(mèng)，對于技術(shù)從業(yè)人員來(lái)說(shuō)，不盲目引入不必要的高深技術(shù)來(lái)保證項目進(jìn)展是一種基本的職業(yè)素養。 此外設計中還有一個(gè)隱含的條件，就是選擇的方案能相對減少開(kāi)發(fā)周期，加快交付時(shí)間。也就是下一點(diǎn)介紹的。 交付能力 通俗的說(shuō)就是不管發(fā)生了什么，都能按時(shí)交付。 充分考慮自身技術(shù)能力、項目依賴(lài)、隊員排期沖突、負面情緒、技術(shù)方案風(fēng)險、未預知的技術(shù)障礙、需求變化等。 具備為功能的設計做取舍的能力，但功能取舍并不以犧牲產(chǎn)品的核心愿景為前提。 規范與協(xié)作 在編碼前能夠完成模塊或特性的清晰架構或設計文檔，并保持在開(kāi)發(fā)過(guò)程以及代碼重構過(guò)程中文檔的一致性。 推動(dòng)及促進(jìn)團隊的代碼及設計規范，并確保執行過(guò)程中與規范的一致，并能根據實(shí)際情況對流程及規范提供優(yōu)化建議。 編寫(xiě)的代碼通常當做團隊的模板或者是最佳實(shí)踐的設計模式。 團隊效率貢獻 有改善團隊效率方面的貢獻嗎？比如做一個(gè)相似項目為何周期很長(cháng)？為什么開(kāi)發(fā)完成之后又花了比開(kāi)發(fā)周期更長(cháng)的時(shí)間調試或修改bug？ 推進(jìn)代碼復用，你的代碼和工具其他小組或部門(mén)愿意用嗎，準備讓他們用嗎？有推動(dòng)讓他們用嗎？ 自動(dòng)化體系來(lái)幫助提高測試、開(kāi)發(fā)、debug、跟蹤用戶(hù)問(wèn)題的效率 能夠用服務(wù)化的方法來(lái)解決異構、多版本問(wèn)題 有優(yōu)化流程貢獻？ 
已經(jīng)不是那個(gè)獨行俠或個(gè)人技術(shù)英雄的時(shí)代了，融入團隊，多考慮對團隊的貢獻，更容易得到成長(cháng)。 后記：職業(yè)發(fā)展方面話(huà)題比較大，不容易寫(xiě)好，本文也寫(xiě)得比較辛苦，改了兩個(gè)晚上，暫不寫(xiě)類(lèi)似話(huà)題。這也再次說(shuō)明，當你有一個(gè)非常大的愿景（想當青年導師？），但系統能力還跟不上時(shí)，更應從小處著(zhù)手。 原文鏈接:timyang.net |
