作为程序员，你希望绩效考核怎么来做？

不搞考核的人，有个问题，你能接受不怎么干活或者经常把事情搞砸的人跟你拿一样的钱？
我觉得现在很多考核最恶心的点在于
1.哪怕所有人做的还可以，也必须有人低绩效
2.有些公司纯看跟上级的关系来给绩效，不看工作质量

时间长了，谁的能力强都知道，谁能给别人做 code review ，谁能在一线解决客户的问题，KPI 基本都是垃圾

抛砖引玉
低效管理：干的越多越好
高效管理：敏捷开发，两周一个迭代，站会周会，计划会合理安排 10 人天工作量

大多数考核都是看领导的喜好，上面跟谁关系好就给谁打高分。
而且每个人做的业务不一样，有的业务产出明显，有的业务重调研，产出效果一般。
每个人职级与工资不一样，这是一个重要的维度其实，但好多可能都放在一起去考核。
所以有这么多不确定因素在，这绩效大多数还是形同虚设，最后还是变成领导喜好去打

程序员的意见不重要

别考我了，我考核老板吧

@wqhui 那为什么这么糟糕的人能进团队并且留在团队？

人月神话，可以了解一下。

当你思考这个问题的时候，你就能理解许多作为底层员工觉得不合理的管理方式了
本质上就在于人会普遍高估自己，如果你让每个人自评绩效，那么整个团队合起来，肯定会超预算。基于这个前提，你无论怎么打绩效，都会打击部分人的逾期
PS 一下，不是说制度透明就不会受到非议，大家会说制度不合理。即使非常明确的制度，依然会受到执行层面的细节所影响，比如一楼说的几条里面，最简单的 BUG：到底算不算 BUG ，算是谁头上的，责任要怎么分，往细了说就复杂，一复杂就有人有意见。同时，当规则透明之后，这个规则是否真的能代表工作的所有内容，规则越强大，规则之外的事情越没人关心，但那些似乎可有可无的东西，依然对整体的工作有较大的影响。比如说团队合作，知识分享

所以我的观点是：打绩效就还是偏人治的事情，组织会选择信任 leader ，信任他做的选择。leader 在绩效中有较大自主权，由 leader 来全权管理团队，拿到好的成绩

程序员考个毛~又不是销售~

无恶意的说一句, 大部分程序员知识面很单一,

看不上这看不上那, 可是看不上的偏偏是自己严重缺失的部分

原因呢, 就是编码是最简单, 心智负担最低的工作

- 以团队为单位来进行考核，leader 负全责，做得不好换 leader
- leader 掌握所有组员生杀大权，及时更换拖后腿的组员

我 [理想] 中的考核在条条框框之前是有先决条件的，这个先决条件甚至比考核项的具体内容还要重要：

1. 被考核人信服考核人/团队的资质。
2. 考核人/团队了解被考核人的条件。

要不然考核内容的落实无从谈起，结果也与考核最原始的目的相去甚远。

现今的考核框架制定原则，个人是用这些方针：

1. 所有硬性指标由技术内部控制，不受能行政干预。（避免技术评价还行，HR 一票否决，然后人被开了的情况）
2. 按项目类型和责任人等级决定绩效是结果导向还是过程导向。
3. 考核项以小型里程碑为最小单位，尽量忽略短期时间内的细枝末节。
4. 不使用自评，也不使用 360 环评等可能影响氛围或滋生不良的机制。
5. 上级给下属打差评要有据可依且须与对方解释清楚。

经历过很多绩效考核的公司，其实我感觉绩效考核，它不止是在评分阶段存在不准确不公平的现象，它在分配任务之前，就已经不公平了，比如需求它总有难的、容易的、恶心的，领导它总是会把恶心的任务分配给它不喜欢的手下，这种活其实就是吃力不讨好的，哪个人来做，都是这样子，总结就是 做多错多

如果垂直度比较高，那就各级 leader 自由分配。可以平均分配，也可以用自己的方式考核。最烦的就是强制比例。

如果是扁平化管理，没想好。。。

bug 数、代码行数，不设硬性的考核指标。
可以作为评价的参考，最终由直属 leader 主观评价。
即使 bug 多、代码行数少，如果直属 leader 认为他绩效优，那就可以。

不要搞什么绩效考核，一个小团队首先要有一个 Leader ，大家要认可这个 Leader 说的话，这个 Leader 要能观察团队中的成员是否互相帮助、互相理解、互相认可。

把大家不太认可的那个人踢出去，换一些新人进来，大家做出来的产品，产生了什么最终结果，这个才重要。

@chendy #4 不做或者做简单就没有 bug ，越难 bug 越多，你不会说你从来不写 bug 吧

考核员工先考核自己，每个月按照标准考核给自己评，再来评员工。