前端开发的绩效管理
周末和同事一起去听了赵老师《绩效管理》的课程，没带着纸笔，直接说感想吧。
技术人员的考核与激励一直是我们比较头疼的问题，具体到前端开发方面，员工所做的工作，很难量化到细节。各项目组和人员工作的可比性不强。项目的不确定因素太多。
xhtml+css的绩效考核
之前曾经尝试按设计稿的大小（1024*768分辨率）为单位，在规定时间内做好指定大小的页面，给予奖励。但是前端开发是一个比较随性的工作，我们可以10分钟写完一个页面，也可以100分钟写完一个页面，都取决于开发者对待工作的态度。
周末的培训中，把员工分为两类，一类是X型，不积极工作的；另一类是Y型，积极工作的。上述情况，和人民公社一样，都把员工假想为Y型，都在认真写代码，这种考核制度才是可取的。问题是，有多少人在认真写代码？速度快的质量就好吗？
很多技术都是需要时间来堆彻的，考虑的越全面，越费时间。
就算工作类型都是普通页面的xhtml重构，不包含任何ajxa、javascript等耗时元素，代码审核也仍然是个大问题。
在这方面，赵老师提到了一个观点“十字路口的红绿灯重要还是交警重要？”
制定一套详尽的规则，远比一个尽职尽责的警察重要的多。
世界杯赛场上，如果没有边界线，纯靠裁判的眼睛来判罚，会有多少失误？
我们首先可以利用w3c的页面检测，大概的查一下员工所做页面是否有严重错误，然后再用yslow分析一下页面的质量，最后查看源代码大概看看就可以完成审核。这样操作可以大大降低审核人员的工作强度，但适用的范围仍然很狭隘。
以结果为导向
绩效（即结果、目标导向），做出成绩来，才能谈奖金的问题。
如果把前端的开发人员，拉到运营的层面，从业务的角度来进行研发的绩效管理，拿每月的流量分析、数据报表说话，就可以直观的反应出员工的价值。
我的建议是，以整体项目运作产生的价值作为考评的原则，迭代开发。
第一版设计稿+页面，用户的跳出率是多少？目标转化次数是多少？忠诚度？访问深度？…
第二版的？
第三版的？
这个月，这套东西给公司赚了多少钱，下个月，赚了多少钱。在这其中，谁的关键性点子起了作用，改了什么地方的元素，提高了哪个值。然后以项目组为单位，发奖金，再由组长进行奖金的分配。
当然，如果你的管理人员出了问题，这套绩效管理方法反而会起反作用。
任人唯亲，结党私营。
严厉的政策是为了降低管理的工作量
对于迟到的问题，有的公司罚款10元，有的50元，有的100元。
对于高空坠物，新加坡会没收他们的房子。
员工迟到一次罚款100元，是否合理？
要是有人罚我100元，我肯定就带着兄弟们起义了。
但如果真这么搞，而且入职前都说明了，不要往主服务器上提交未经测试的代码，违者罚款1000元。
那我相信这个员工就会很注意SVN的提交动作，从而尽量避免了这个问题。
要知道，没有任何企业是依靠扣员工的薪水发家的。
制定规则的目的是为了避免失误，而不是为了处罚。我们可以再订一条，如果出现失误，公司暂时替你保管1000元，1个月内如果没有重大失误，返还给你。
当然，这里面要注意劳动法的问题，操作的时候要谨慎，让员工主动给你交罚款，别直接从工资里扣。
罚款手段不可滥用，只有结合各种奖励的措施，才能有效发挥其预期的效果。
总结
继续摸索。
在任何制度没有想清楚之前，不要匆忙上马。
个人比较倾向于第二套模式，以结果为导向，根据业务的运营状况来分配奖金。
再研究吧……
07/13/2010 at 22:32
对这些就不太懂了。。。还没工作
回复
07/13/2010 at 23:59
但是以结果为导向的还是有很多地方需要讨论：
1.前端在整个产品过程中说话力度多大？
2.对于用户访问量及访问深度，前端能做什么？
3.用户跳出率并不只在于前端代码，可能更多的的是内容抑或者视觉上的，也可能是网络方面的，对于其中的比例怎么衡量？
最后 其实痕量前端工作还可以根据设计完成符合度来恒定：看是否达到设计要求，交互要求，产品要求，差异度有多少？ 或者代码质量等等之类的。。
回复
七月 14th, 2010 at 11:22
外在因素太多。
就好像几年前的北京楼市，一个小姑娘能卖几个亿的房子。
现在同样的小姑娘，还能卖几个亿吗？
您后边提到的几点，很有借鉴意义，我再想想。
07/14/2010 at 13:21
赞同用工具去评测前端页面的考核。
但说到把前端和运营方面扯在一起，就不太认同了。
页面的跳出率，流量等方面并不是前端说了算的。
回复
七月 14th, 2010 at 13:52
这里所说的前端开发，包含设计、交互、用户体验、SEO、页面加载速度
一个设计不错的广告图，可以引入更多的流量。
一个加载速度快的页面，可以给用户展示更多的内容。
一个交互顺畅的流程，可以带来额外的订购率。
我认为，设计、交互、用户体验，这些都是前端的工作。
我们不是页面仔，我们能做的，不仅仅是写代码而已。
07/15/2010 at 3:36
对于绩效管理我也有很多困惑，看过您的文章后深受启发。同时我也有一些绩效管理方面的心得分享：
1.如果绩效标准很难确定，可以先从主观评价开始，逐步发展为客观标准(比如通过直观感觉或刻意观察，从几个大的方面进行评价，然后逐步引入客观指标)
2.奖励多于惩罚，这和团队士气有直接关系，进而影响团队整体的战斗力
3.过程和结果的考核同样重要，结果考核应该是实实在在的指标，过程考核则取决于团队的文化——或者说您的团队看重哪些精神或意识形态层面的东西：比如团队在乎大家在一起近距离工作的氛围和感觉，那就要对出勤情况多做考核
4.绩效应该同时体现团队成绩和个人成绩
5.今天的绩效标准决定了明天的团队形态，太过死板的绩效管理会使团队的能力变得僵硬，逐渐丧失应对各种变化的能力
6.前端开发和市场反应不无关系，但与其把市场反应直接作为绩效指标，不如将其转化为前端开发看得懂的东西，这样绩效不仅可以评价大家的工作，还可以对大家的工作有一个明确的指引
7.好的绩效标准应该是主管和下属共同制定出来的，甚至因人而异，不时调整，对症下药
8.本着解放生产力的原则，不要因为迁就绩效管理而增加下属的工作负担，比如每月填个大报表什么的——这应该是主管或机器的工作
9.我理想中的中小型团队，应该是：主管负责让员工爱上自己的工作；员工做自己喜欢做的事情。
以上
回复
07/15/2010 at 17:42
这个以结果导向的方法已在我公司用了，并且范围扩大到全公司，不论是商务、财务、技术、运营支持等等部门，一律考虑部门贡献按比例提成，然后部门奖金再内部分配。
至于那个“任人唯亲”的问题，我部门奖金分配都公正透明，所有奖金分配方案在中层以上经理是共享的，所以不会有人敢乱来。另外自己部门的奖金方案对自己部门员工共享。奖金异变原因都会对每个员工交代。
回复
07/16/2010 at 8:33
不实际，，执行起来是另一码事
回复
07/19/2010 at 11:19
没有管理才是最高境界
回复
07/19/2010 at 13:41
我也看过一些。
回复
07/24/2010 at 22:47
值得借鉴。增加点我的看法，前端任务分为脑力任务和体力任务。体力任务的前端经常是产品的需求和设计粒度很细，一般是产品缺少创新内容，或者copy产品的时候。当前端涉及脑力任务时，相应的绩效点就很难把握了。通常这种前端会涉及产品设计和用户体验设计。对于夹杂有脑力任务的前端绩效，我的一个经验就是横向比较，与同行类似的产品做比较，以行业最优秀的几个产品做标杆，评估出一个行业平均绩效来，当然还是不好控制客观。
回复
07/29/2010 at 0:51
感觉扣钱不是很好的激励
奖励钱是否更好！
回复
12/05/2011 at 18:11
技术类的考勤，一直都是个头疼的难题！结果导向，也有许多弊端！规则重要，但个人觉得，关键还是要看企业是否讲文化影响到个人，同时奖惩结合到位，摸索出有特色的规则
回复