DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> CSS入門知識 >> CSS詳解 >> xhtml+css(網頁前端工作)的績效考核
xhtml+css(網頁前端工作)的績效考核
編輯:CSS詳解     
前端開發方面,員工所做的工作,很難量化到細節。各項目組和人員工作的可比性不強。項目的不確定因素太多。之前曾經嘗試按設計稿的大小(1024*768分辨率)為單位,在規定時間內做好指定大小的頁面,給予獎勵。

技術人員的考核與激勵一直是我們比較頭疼的問題,具體到前端開發方面,員工所做的工作,很難量化到細節。各項目組和人員工作的可比性不強。項目的不確定因素太多。

xHtml+CSS的績效考核

之前曾經嘗試按設計稿的大小(1024*768分辨率)為單位,在規定時間內做好指定大小的頁面,給予獎勵。但是前端開發是一個比較隨性的工作,我們可以10分鐘寫完一個頁面,也可以100分鐘寫完一個頁面,都取決於開發者對待工作的態度。

周末的培訓中,把員工分為兩類,一類是X型,不積極工作的;另一類是Y型,積極工作的。上述情況,和人民公社一樣,都把員工假想為Y型,都在認真寫代碼,這種考核制度才是可取的。問題是,有多少人在認真寫代碼?速度快的質量就好嗎?

很多技術都是需要時間來堆徹的,考慮的越全面,越費時間。就算工作類型都是普通頁面的xHtml重構,不包含任何ajxa、Javascript等耗時元素,代碼審核也仍然是個大問題。

在這方面,趙老師提到了一個觀點“十字路口的紅綠燈重要還是交警重要?”

制定一套詳盡的規則,遠比一個盡職盡責的警察重要的多。世界杯賽場上,如果沒有邊界線,純靠裁判的眼睛來判罰,會有多少失誤?

我們首先可以利用w3c的頁面檢測,大概的查一下員工所做頁面是否有嚴重錯誤,然後再用yslow分析一下頁面的質量,最後查看源代碼大概看看就可以完成審核。這樣操作可以大大降低審核人員的工作強度,但適用的范圍仍然很狹隘。

以結果為導向

績效(即結果、目標導向),做出成績來,才能談獎金的問題。如果把前端的開發人員,拉到運營的層面,從業務的角度來進行研發的績效管理,拿每月的流量分析、數據報表說話,就可以直觀的反應出員工的價值。

我的建議是,以整體項目運作產生的價值作為考評的原則,迭代開發。

第一版設計稿+頁面,用戶的跳出率是多少?目標轉化次數是多少?忠誠度?訪問深度?…第二版的?第三版的?

這個月,這套東西給公司賺了多少錢,下個月,賺了多少錢。在這其中,誰的關鍵性點子起了作用,改了什麼地方的元素,提高了哪個值。然後以項目組為單位,發獎金,再由組長進行獎金的分配。

當然,如果你的管理人員出了問題,這套績效管理方法反而會起反作用。任人唯親,結黨私營。

嚴厲的政策是為了降低管理的工作量

對於遲到的問題,有的公司罰款10元,有的50元,有的100元。對於高空墜物,新加坡會沒收他們的房子。

員工遲到一次罰款100元,是否合理?要是有人罰我100元,我肯定就帶著兄弟們起義了。

但如果真這麼搞,而且入職前都說明了,不要往主服務器上提交未經測試的代碼,違者罰款1000元。那我相信這個員工就會很注意SVN的提交動作,從而盡量避免了這個問題。

要知道,沒有任何企業是依靠扣員工的薪水發家的。制定規則的目的是為了避免失誤,而不是為了處罰。我們可以再訂一條,如果出現失誤,公司暫時替你保管1000元,1個月內如果沒有重大失誤,返還給你。

當然,這裡面要注意勞動法的問題,操作的時候要謹慎,讓員工主動給你交罰款,別直接從工資裡扣。罰款手段不可濫用,只有結合各種獎勵的措施,才能有效發揮其預期的效果。

總結

繼續摸索。在任何制度沒有想清楚之前,不要匆忙上馬。

個人比較傾向於第二套模式,以結果為導向,根據業務的運營狀況來分配獎金。再研究吧……

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved