技術人員的考核與激勵一直是我們比較頭疼的問題，具體到前端開發方面，員工所做的工作，很難量化到細節。各項目組和人員工作的可比性不強。項目的不確定因素太多。
xHtml+CSS的績效考核
之前曾經嘗試按設計稿的大小（1024*768分辨率）為單位，在規定時間內做好指定大小的頁面，給予獎勵。但是前端開發是一個比較隨性的工作，我們可以10分鐘寫完一個頁面，也可以100分鐘寫完一個頁面，都取決於開發者對待工作的態度。
周末的培訓中，把員工分為兩類，一類是X型，不積極工作的；另一類是Y型，積極工作的。上述情況，和人民公社一樣，都把員工假想為Y型，都在認真寫代碼，這種考核制度才是可取的。問題是，有多少人在認真寫代碼？速度快的質量就好嗎？
很多技術都是需要時間來堆徹的，考慮的越全面，越費時間。就算工作類型都是普通頁面的xHtml重構，不包含任何ajxa、Javascript等耗時元素，代碼審核也仍然是個大問題。
在這方面，趙老師提到了一個觀點“十字路口的紅綠燈重要還是交警重要？”
制定一套詳盡的規則，遠比一個盡職盡責的警察重要的多。世界杯賽場上，如果沒有邊界線，純靠裁判的眼睛來判罰，會有多少失誤？
我們首先可以利用w3c的頁面檢測，大概的查一下員工所做頁面是否有嚴重錯誤，然後再用yslow分析一下頁面的質量，最後查看源代碼大概看看就可以完成審核。這樣操作可以大大降低審核人員的工作強度，但適用的范圍仍然很狹隘。
以結果為導向
績效（即結果、目標導向），做出成績來，才能談獎金的問題。如果把前端的開發人員，拉到運營的層面，從業務的角度來進行研發的績效管理，拿每月的流量分析、數據報表說話，就可以直觀的反應出員工的價值。
我的建議是，以整體項目運作產生的價值作為考評的原則，迭代開發。
第一版設計稿+頁面，用戶的跳出率是多少？目標轉化次數是多少？忠誠度？訪問深度？…第二版的？第三版的？
這個月，這套東西給公司賺了多少錢，下個月，賺了多少錢。在這其中，誰的關鍵性點子起了作用，改了什麼地方的元素，提高了哪個值。然後以項目組為單位，發獎金，再由組長進行獎金的分配。
當然，如果你的管理人員出了問題，這套績效管理方法反而會起反作用。任人唯親，結黨私營。
嚴厲的政策是為了降低管理的工作量
對於遲到的問題，有的公司罰款10元，有的50元，有的100元。對於高空墜物，新加坡會沒收他們的房子。
員工遲到一次罰款100元，是否合理？要是有人罰我100元，我肯定就帶著兄弟們起義了。
但如果真這麼搞，而且入職前都說明了，不要往主服務器上提交未經測試的代碼，違者罰款1000元。那我相信這個員工就會很注意SVN的提交動作，從而盡量避免了這個問題。
要知道，沒有任何企業是依靠扣員工的薪水發家的。制定規則的目的是為了避免失誤，而不是為了處罰。我們可以再訂一條，如果出現失誤，公司暫時替你保管1000元，1個月內如果沒有重大失誤，返還給你。
當然，這裡面要注意勞動法的問題，操作的時候要謹慎，讓員工主動給你交罰款，別直接從工資裡扣。罰款手段不可濫用，只有結合各種獎勵的措施，才能有效發揮其預期的效果。
總結
繼續摸索。在任何制度沒有想清楚之前，不要匆忙上馬。
個人比較傾向於第二套模式，以結果為導向，根據業務的運營狀況來分配獎金。再研究吧……