剛入職場的時候,對於績效的概念理解朦朦朧朧,到後面本身作PM,本身開始帶團隊,帶團隊之後開始接受公司相對正規的團隊管理的培訓,到閱讀德魯克的《卓有成效的管理者》,對績效這個概念有了相對較爲清晰的認識,因此在這篇隨筆裏,我會以本身的親身體驗來說一講我對績效的認識。程序員
一、TOP 1有意思的問題做爲程序員怎麼拿到高績效?這個話題就好像問作什麼賺錢的同樣, 沒有一個很是精準的答案可是有一些普適的道理。工具
a)超出預期: 所謂高績效通常狀況下是要超出指望纔有可能,那麼這個指望就是給你考評的老闆或者主管的指望。舉個例子,好比主管安排你去開發一個大的新特性,主管在和你溝通時候,就會在談話中有意無心的流露出本身的指望,好比說:小王,這個特性是咱們xx項目的關鍵特性,直接決定了項目的成功。在這句話中,首先主管是但願你把這個特性開發出來,可是若是你只是把功能開發出來了,是否是就意味着高績效呢?絕大部分狀況下必定是超出預期纔會有高績效。性能
項目經理的高績效,通常在成本、進度和質量方面超出預期,原來項目須要30人月,你20人月搞定。開發人員通常是進度和質量上超出預期,原來是1個月開發出來,你20天完成;原來通常的缺陷率是5個bug/K loc,可是你作到了轉測試零缺陷;原來指望這套系統設計能支持100 tps,可是你設計之後,能達到150tps等等。測試
b)瞭解你的老闆甚至老闆的老闆和你所在的團隊,經營你的人脈關係:我我的的技術情節比較重一些,對這一點的真正本身理解比較慢是大概工做了7年多的時候。瞭解你所在的團隊,會更加準確的命中團隊的短板,這樣會更好的瞭解老闆的指望。我這裏有一個印象深入的例子,當我在帶一個大概40人左右的團隊的時候,有一次給一個高層的領導彙報某工做的思路,我和我團隊的幾個骨幹精心準備了膠片,有數據、有圖表自認爲不錯,哪知道彙報尚未2分鐘就被中斷了,領導丟下一句「思路不清楚,想清楚了再來彙報」。回來之後,個人主管給了我一些指導,大概的意思: 第一,你彙報的對象是SPDT經理,SPDT經理今年最關注的是降成本,而降成本里面今年的一個方向就是將非主營業務經過產品合做或者技術合做。第二,咱們的SPDT經理並非技術出身,加上彙報的人不少,若是在開始的幾張膠片中沒有吸引他的眼球的話,他就會沒有耐心再聽你講下去。從這個事情之後,我又仔細的想了想,從思路上如何和組織的指望對齊,加上材料上從20多頁從新組織只留了大概7頁左右,終於彙報獲得了承認。設計
c) 腳踏實地,幹活儘量不要挑肥揀瘦:在一個團隊中,不可能每一個人作的事情都同樣,有的事情看起來挺無聊的,好比管理持續集成的環境、專門負責DFx的工做等等。我遇到的那些挑活幹的同窗中不少即便挑了其它工做,不少也並非作的很好,固然這個並非100%絕對的。我這裏有2個例子,一個是我本身的,一個是我知道的。在咱們原來大團隊中準備開發新的產品,那時的DFx由於你們以爲沒有開發後臺好玩,你們都不肯意作,有一個同窗主動承擔了,後來這個同窗幾年以後成了咱們整個大產品首屈一指的DFx方面的專家;另外是我本身的經歷,那是大概在06年的時候,個人主管有一次據說有的團隊在搞E2E的性能測試,可是沒有人去研究這些,那時咱們的團隊主業務並非這個,當時我也沒想太多什麼績效,因而我把全部相關的資料都找到,相關的代碼以及測試工具本身琢磨,發現這裏面大有搞頭,一直到後來我成了這項工做在咱們大團隊的帶頭人。對象
d) 多總結,及時總結:我想到了之前參加一個知識管理的老師說的話,「經歷不表明經驗,經驗不表明是知識」,若是要轉換,那麼就須要經過總結。總結的好處不只僅讓你本身收益,也能將知識讓更多的人收益。排序
二、上面說了怎麼拿高績效,可是第二個面對的問題應該以什麼樣的心態來看待績效。開發
績效管理是企業管理的很是重要的一個部分,有人拿績效好,那麼必然有人績效很差,那麼做爲咱們我的怎麼看待?產品
首先不要刻意的把天天把拿到好績效放在嘴邊上,由於大部分拿高績效的同窗只是認真把本身手頭的工做盡量作到最好,好的績效是水到渠成的事情,績效不會由於你每天想、夜夜思他就會來到你身邊。持續集成
其次拿不到高績效並不意味着本身很失敗,績效是一個相對排序的結果,畢竟是人爲排序的結果,只要有人的參與,就很難100%的客觀;每一個人的個體的差別,好比有的同窗以前有相關的經驗,有的名校畢業專業技能更強等等。拿不到高績效不是說咱們就不努力了,相反我以爲只要盡力了,就不要有什麼遺憾。
最後若是持續的低績效,就要考慮換個環境或者地方,多是你和老闆不對拍,「樹挪死,人挪活」,這樣的例子我經歷過比較多。舉個例子,咱們團隊作軟件的招了一個之前作嵌入式的同窗過來,那個同窗一直對原來的老本行感興趣,而對咱們作的純軟件不感冒,因此一直不在狀態,績效那2年不好。後來個人主管很明智,有一個機會把他調到一個新的產品,到了新產品之後發展到很是好,我走的時候他已是那個產品最牛掰的設計師了。
三、最後簡單的說一下帶團隊的同窗的績效。若是你只是一個開發人員,那麼你的工做是一個獨立貢獻者,基本上作到上面就能夠了,可是若是你是一個帶團隊的,總但願本身多寫幾行代碼,那麼你的團隊總體很難拿到高績效。團隊的高績效必定意味着團隊承接了更上層組織的重點工做,並用整個團隊之力將重點工做完成好,而不只僅是某一個項目中成功。因此帶團隊的主管的角色必定作轉變,轉變爲把握整個團隊的方向,如何給員工作績效輔導,讓好鋼用在刀刃上,完成組織的目標。話題太大,簡單的說說。
績效話題很是大,以我淺薄理解,但願對你們有所幫助。