技術人員應對「考覈」的一些思考

來這個公司實習已經半年多了，在年前經歷了一次年終考覈，最終對個人工做的評級是 C（ 及格-符合當前職位的工做），讓我不由思考本身在項目中的一些工做的問題，爲何我是C？是我作的不夠好嗎？或者說在哪裏作的不夠好？

 

從考覈流程來看，基本上是 CTO 與 Team Leader 對團隊成員的「年終總結與次年工做計劃」進行Rank，我的狹義的認爲「考覈」的主要支持材料就是這個總結了。

 

他山之石

其餘公司是怎麼考覈的呢？說實話我也不太清楚，剛入行，只能經過搜索瞭解，在網上了解到有如下幾種：發精品博客、發論文、開源項目、出書、技術分享大會、技術公衆號/微博/知乎 等，這一類績效方式是經過推廣本身的技術來提高公司在行業中聲望。如Element、Qcon等。

其餘類型的我就沒看到了，很明顯，這類考覈僅適合大公司或者高層次技術人員的考覈，或者說，我本身是不具有相關條件的。

 

對於我我的，因爲是實習生，不少知識點還不算熟練，半年來也就是「 積極完成產品的需求，以及1~2天一次的高頻率的發佈，跟進線上日誌，平時會整理一些項目的文檔，和其餘部門的人溝通一些業務等」，看上去平平淡淡，中庸到我本身都會給本身打 「C Rank」了，可是這也就是一個技術人員的真實工做狀況，我 leader 也在感嘆如何獲取更好的績效，畢竟我參加的項目是一個已經運行了 8~9 年的一個老項目了，平時的工做要求也真的只是完成產品的需求，不容易產生「突出」的工做成果，那麼我該怎麼去作來打破這一困局呢？

 

考覈量化？

反對對技術人員的過度量化管理，爲了「指標」容易脫離產品，不利於開發效率，也不利於真正提高產品質量。好比：爲了追求低異常率，而花費大量的時間資源進行測試，會下降項目迭代速度，最終影響項目進度，而某些產品正須要快速迭代。

 

考覈的缺陷

首先來思考一下這樣考覈的缺陷

對技術人員的考覈通常是體現就是在他的產品上，相較於研發部門，業務開發的部門的程序員可能更不容易突出本身的工做，舉個例子來講，業務開發人員的工做內容可能就只有一種「 完成A需求，B需求，C需求……」。而研發部門更容易突出本身的成果，如 「 反垃圾、對XX進行深度學習、精準推薦……」 ,而且 即便業務開發人員說他完成了XX等功能模塊的開發，但考覈時並不會把這一項歸功到程序員上，而是會把這個工做更多的歸功到設計這一功能的產品身上，因此對於純粹作業務開發的程序員來講，並不容易在整個產品技術部門的考覈中佔據優點。

 

對程序員考覈其餘可能的誤差因素：

• 是否爲公司新項目，是否爲重點項目

        新項目或重點項目更加容易獲得公司高層的關注，如騰訊的 英雄聯盟 和 微信，相較於什麼「QQ音樂」確定是更加受關注的，對業務程序員來說，基礎需求開發的工程都是差很少的，原本應該是產品性質決定的二者性質不一樣，但管理層在實際考覈中會更偏袒於新項目或者重點項目。

• 銷售額、毛利率、產品估價等外因影響項目的評價

        某些產品受大環境影響比較大，可能有的項目這一年的開發量或工做量不是不少，改進也不大，但隨着政策或大環境的發展成爲一大熱點，PV 或銷售額上升，此類爲外因致使的產品績效提高，如 「各種娛樂圈事件在微博上發酵提高了產品活躍度」這一背景可能會讓新浪對 微博開發部門 的評價總體提升。

• 行業領域的發展

        在這段時間尤其火爆的前端，「Vue.js 」與「 微信小程序」 在技術圈仍是比較吸引眼球的， 阿爾法狗的人工智能或深度學習也是吸引了你們的眼球，不能否認新技術的使用是績效的一大加分項，也是對技術人員的挑戰，但與iOS 、Android 、Java、PHP 相比，後者在技術圈幾乎沒什麼波瀾了，特別是服務器端的開發很難出現像 「小程序」 這樣的IP，相較於前端部門，移動端/服務器端部門在今年的評價的確是比前端低。

• 其餘因素

        是否準時上班、考勤打卡、加班、是否在上班時間瀏覽微博新聞等，這裏不過多闡述。

 

以上因素可能不能從程序員自身獲得解決，也就是說：相同的程序員在不一樣的項目的最終評分會由於這類因素致使不同。

 

 

我眼中的技術人員的考覈的目的

對於公司和我的來講是出於人事薪資管理的目的

對項目來講目的是 「但願技術人員能運用技術手段讓項目更加好」

 

 

因此，技術人員如何使產品更加完善呢

站在銷售角度：提高毛利率 ≈ 下降人工成本 + 銷售額度提高

銷售這一塊我沒想到什麼好的技術人員能夠輔助的手段

在下降人工成本方面：

• 多信息導入流程中，將手動填寫表單轉爲用戶使用Excel批量導入信息，下降客戶的編寫成本
• 使用反垃圾技術提高社區網站垃圾的信息的屏蔽速度（參考 ：知乎的悟空系統）
• 自動化/輔助運營，如EDM

 

站在Boss角度：面向關鍵指標(KPI)的提高

能夠先想象一個場景：

「  程序員向非技術出身的Boss做工做彙報（錯誤的方式）」

Boss: 小K，你來彙報一下這個月的工做吧！

小  K：這個月完成了對項目的老的 Spring 框架的升級，升級以後項目就能夠用新特性進行開發了，並且更安全，以及摒棄了某數據對XML的依賴，改成使用數據庫進行此類數據的管理，這樣操做效率更高，修復了許多線上的異常，解決了N個慢查詢的SQL,同時完成了A\B\C\D\E\F\G等功能特性的開發……

Boss：好！（？？？聽的一臉懵逼，但仍是要保持微笑）

小 K ：謝謝老闆。

 

其實越對於高層的人員，實際上是越脫離項目的業務邏輯的，他們可能關心你所在的項目，但不關心你的項目細節，他們更但願聽到的是產品在你手裏有什麼提高的地方。其實在上面那個場景已經說到了幾點 「提高速度」、「安全性」、「穩定性」等，這些能夠被稱做技術人員的項目的關鍵指標，既然是要彙報工做，建議 使用數聽說話，用通俗的語言來描述本身的工做。

如：

 

    給首頁添加一套 緩存機制，之前首頁須要 1s，如今只須要 0.4s就能打開，且能保證數據更新，提高了 60%速度！

 

標準格式：技術名稱+應用場景+之前+如今+改善多少

再舉一個例子：

 

    對搜索項目今年改成 雙機部署，以前線上單機的時候線上有必定的失敗率，致使用戶搜索不到結果，天天這個狀況約發生 2000+次，雙機部署後，情況良好，幾乎再也不出現這種狀況了。

 

其實這些數據獲取也很是方便，直接ssh到服務器上，而後用 grep命令統計特定關鍵詞，一分鐘不到就能能夠統計到的事。

 

例：能夠需統計的數字

• 發佈次數、補發次數->發佈成功率  （穩定性）
• 需求量 / 開發人數 = 效率 
• 解決慢查詢的次數 並 估計能夠提高的頁面訪問效率 （訪問速度提高）
• 對搜索接口做緩存處理/雙機處理，避免沒法使用（穩定性）
• 線上異常數量，並作好統計，並以這個數據來設計一套 「項目健康度」，且有利於技術人員瞭解項目健康程度
• 內存使用下降多少。
• 自我滲透測試解決XX漏洞（沒有QA部門的能夠試試）

 

這些其實都是作業務開發的人員的工做，但有數據支持，特別是提高的方面的數據支持其實能給本身績效增添很多分，由於言語夠通俗，且你在項目中發揮的做用很明顯，再也不是「完成XXX等重點業務開發」這樣的話了。若是能用圖表表現的話可能會更加直觀。

 

站在產品角度：技術人員能夠嘗試對競品進行分析

 

舉個例子來講，開啓開發者工具，打開Network選項，而後打開某站，整套工做流程走下來，粗略的看中間的請求頭與請求內容，哪些是Ajax，爲何這個是使用Ajax的，是否採用了restful的接口設計，他是如何規避CSRF，是否存在XSS、越權等，他的字段設計是怎麼樣的，表間關係大概是怎麼樣的，頁面相應時間是否比我項目的快，可能能夠經過緩存來優化相應速度的地方有哪些，他的SEO策略有哪些，站點是否有反爬蟲機制。

 

還有一個例子是Word導出的方法，這個我也是調研了十幾個產品的同類功能，最終總結出5個方法的，分別都有哪些優缺點什麼的，而後根據本身產品的實際狀況技術選型，而後完成開發，目前感受效果還不錯。這個過程也不錯

 

這個過程不只好玩，還能經過對比其餘產品來提高本身的產品，還能提高本身開發過程當中的安全意識，好比說我在調研競品的時候發現了它的越權漏洞，因而我就開始排查本身業務中的漏洞，並且真的排查出來了。(不過我不是白帽子，也不知道咋報告，畢竟是競品就讓bug留在那把😋)

 

站在聽衆的角度：重點變更的先後對比截圖存檔

 

這一條實際對我的成長沒什麼提高，但對績效考覈做爲工做的證實是很是直觀的，如 「站點首頁的改版」 這類工做，一句話可能說不清楚改了什麼，但若是有一個先後對比圖可讓leader看到兩個是徹頭徹尾的不同，並且是在你的改版下網站變的不同了。

同理，上面說的一些效率的提高的比率也能夠用柱形圖來進行對比，圖片畢竟比文字直觀。

 

其餘方面

 

團隊管理與人員培養、 提高開發效率、 打鐵還需自身硬，保持學習、項目總結、技術積累、技術分享、人員招聘、制度完善、代碼規範、項目管理工具的引入、良好格式的年終總結……

這些都是工做中能夠提高的地方，就不一一舉例了。

結語

半年的實習生活是愉快且富有挑戰的，雖然以 C Rank 結尾，但學到的東西是遠遠不是這個績效能衡量的，但願下次考覈能獲得 B 以上甚至 A 的績效，此文爲實習生半年來對本身第一次績效考覈作的一次思考，也但願有前輩能指出不足或不對之處，謝謝。