部门搞了这么久的绩效考核了，好多指标好像并不准确，至少不精确。但是，我们并不为不精确犯愁，毕竟，我们追求的首要绩效精神是公平，正如《让子弹飞》中姜文说的，公平，公平，还是公平。
谁都知道公平的重要，但是真正建立公平体系并不容易。并不是所有的工作都那么容易计算绩效的，是根据工作量呢？还是根据创造的价值？还是根据工作时间？什么都有道理，又什么都没有道理，只能说，因岗位而异，因时而异，甚至因人而异。
有些工作的绩效好搞，以搬砖为例。搬砖，从甲搬到乙，砖头一般大，距离一般远，这就好弄了，最后按砖头的个数数一数就可以了，这个绩效计算，要搞得公平真是太容易了。——但这个公平其实也是相对公平，并不是绝对公平。因为，谁也不能保证每块砖头的重量真的完全一样重，当然，更不能保证所有人搬的每块砖头挪动了一样远的距离，特别是，谁能保证每个人搬每块砖时做的功一样多？
大部分工作都不像搬砖这种工作算起来这么简单。绩效考核的大忌之一，就是把不该简单的工作绩效简单化了。你看，许多学校对老师的绩效考核，以学生的分数为指标，政府对官员的考核，以GDP为指标，这些都是有明显把不该简单的东西简单化的倾向的，其造成的不良后果，有目共睹。
对于企业来讲，有许多岗位，或者有许多工作，真是不太好做绩效考核的。一个培训师，怎么考核他的成绩？当然应该以他培训的其他员工的学习成果来衡量。但是，这个确实有些难，或者几乎不可能吧。于是，由听课者直接对培训师打分，或者，干脆根据培训师的总授课时间作为考核指标。不能太理想，就现实点吧。
大师说，绩效不追求太精确，不追求太公平，关键是，让大家有努力目标，不能导致组织的方向走偏。（好像是德鲁克，具体怎么说的有些忘了，sorry）
我们追求准确，但不追求绝对的准确；我们追求公平，但不追求绝对的公平。这是我们设计绩效标准的原则。嘿，天下本没有绝对公平的事情。想当初，红军那会儿，毛爷不是写了文章说不能搞绝对平均主义嘛，绩效考核，需要破除绝对公平主义。
我们部门里，主要的战斗力量就是程序员了，对于程序员而言，怎么给个绩效指标呢？
首先，先看看工作时间。工作时间这个指标的统计，最准确也最公平，找到打卡时间，下班时间减上班时间算到时长，对谁都一视同仁，加班了，绩效高些，请假了，绩效低些。但，傻子都知道这样是不行的，明显会把部门领进一个混时间不讲工作效率的方向。
这个不行，那么想想最理想的方法，看看程序员创造了多少价值吧。是的，那么多项目，看你做的项目赚了多少钱，赚的钱多，给你的就多，赚的钱少，给你的就少。但是这也有致命的地方，首先，一个项目几个人做，知道谁贡献大呢？还有，有些研发项目，并没有客户付款，是否有成效可能需要几个月甚至几年才能显现出来，这个怎么算呢？而且，大部分时候，这些项目是否能赚钱在程序员开工之前其实就已经决定了大部分了，程序员工作再努力，对它的影响其实并不是太大。这样搞，貌似理想，但很有可能把大家带入了一个靠碰运气的方向，并不能实现我们希望程序员达到的真正目标：努力工作，有团队精神，提供高质量的代码。
看来，最重要的绩效标准还是看他们的工作量与质量。但是，说实话，如何衡量程序员的工作量并不是个容易的事情。当然不能根据程序员完成某项任务使用的时间来计算，这个没有意义的，最好有一个科学的标准工时，根据程序员完成某任务的标准工时计算。
然后，这个标准工时怎么弄呢？谁来给，怎么给？
定标准工时的那个人与他给出的标准工时有什么关系？这个是需要先考虑的，第一种情况，事不关己的，可能不认真，随随便便，或者弄出矛盾，或者大家就靠碰运气工作；第二种情况，给出越多越对自己有利的，可能给出的标准工时远远高于应该给的；第三种情况，给出越多越对自己不利的，可能给出的标准工时远远低于应该给的。最好的想来应该是第三种，没办法就选第一种，第二种是需要尽力避免的。因为，第三种情况，免不了有个确定标准的人与程序员沟通谈判的过程，这一定会导致最后的结果不会与真正的标准偏差太远。
为了尽量减少确定标准工时过程中的人为因素，增强客观性，我们设计了一个计算标准工时的计算模型。在评审时确定某一模块的复杂程度，一般分1、2、3三个标准。只是简单的增删改查的，标准为1；与别的模块关联性较大，或者功能较多，有些复杂业务规则的，标准为2；那种特别复杂的，如BOM分解之类的模块，标准为3。然后，看看模块处理了多少信息，每个字段再给以一个标准工时。两者相乘，得到总标准工时。如某模块需要处理20个字段，复杂程度为2，字段单位工时为5分钟，那么，总标准工时为20*2*5分钟。这样既考虑了信息处理量，又考虑了复杂程度。
这样虽然有些开发模块有特殊情况，过于简单或过于复杂，但是，我们相信，这个方法虽然不精确，但绝对是可以激励大家努力工作，实现部门的期望目标的。
总之，绩效考核，我们追求准确与公平，但没有绝对的准确，也没有绝对的公平。
