要么“被离职”要么几十万年终奖，程序员的年度绩效怎样做才公正？

年底了，各企业年度绩效都做完了，未来还能撑得下去的企业都开始发年终奖了。

前些天，腾讯发年度终奖的消息爆屏了。先是腾讯云的阳光普照奖，人手一台 iPhone 11 Pro，总奖金超过三千万。

而后据称微信支付团队拿到了腾讯 2019 年的公司创始人奖，奖励微信支付团队 2 亿，按照一千人算，一人 20 万。这 2 亿还不算是年终奖，有消息称微信支付团队的年终奖都是 10 个月工资起算。

（这是一张老板们不想看到的截图）

互联网企业的年终奖

互联网头部企业钱多，年终奖往往丰厚得让人秒变柠檬精。

阿里今年在香港再次上市，不知道奖金是否会变多，据阿里员工反映，他们还在走绩效流程。按照惯例，会在 4 月份发放年终奖。普通程序员一般可拿到 4-9 个月的奖金，那么税前至少是 10-25 万。

今年是百度成立 20 年，但主打的 AI 布局也很需要现金流的支撑，目前还没有拿多少年终奖的确切消息。百度在 2019 年改为全年 15 薪，脉脉上有人反映今年拿了 4 个月的年终奖，按照百度工资计算，这个数比起其他大厂略少。

华为的年终奖最丰厚，据华为内部人说，华为人的收入三分之一靠工资，三分之一靠股票，三分之一靠年终奖。其中股票和年终奖，各级领导的话语权比较大。一般员工年终奖都能拿到 2、30 万。

不过华为虽然奖金多，但是个体差别也很大。这位内部人士举例：“比如前些年 18 级左右的员工，如果绩效打 A 会给 60 万；如果绩效打 B 就只有一半，30 万，相差会有小几十万；绩效拿 C 的话，一年就白干了“。真真正正的用“薪”激励啊。

以低绩效为名的“裁员”

除了根据绩效来发年终奖，还有企业根据绩效结果来“裁员”。我们看到有一则求助：

某 BAT 头部企业的老员工了，今天跟 HR 聊了，HR 总体意思是：你的绩效不是很符合预期，这个是你个人能力有问题，你必须相信这一点。你抓紧时间找工作吧，我们可以推荐猎头，我们没有裁员，不会有赔偿。好慌，求助。

被离职不赔偿，这可以解读为以绩效为名被 PUA 了吗？

BAT 和华为等几家公司的绩效管理都有个特点，就是都有 10%左右的最低档绩效，还有的是要求强制分布。

对于中基层的员工，百度和腾讯都是按照五档打分，都会有 10%在最低档。阿里的中基层员工整体打分按照 3-6-1 比例进行强制分布，即 30%为“最好”，60%为“一般”，10%为“较差”。特别的是“价值观”导向，价值观占据50%。阿里 2019 年推出“新六脉神剑”，价值观方面有 20 个选项，绩效考核更为复杂。

华为的年终绩效考评，分为 A、B+、B、C 几个档次，80%的人都是 B 或 B+，C 档最低，比例为 5%-10％且要求强制分布。他们的考核最为独特，要根据投票来评定。比如 CT（绩效评定团队）投票，一般三票左右，直接主管占据一票，评定完了后交由 AT（行政管理团队）复核。

虽然在很多企业里，背最低档不意味着“必须离职”，但是也免不了有企业会拿业绩之外的东西去评定一些员工，进行“人员淘汰”。

当我看到某 HR 这样说一名老员工——“他今天要不自己离开，未来一年也一定会因为绩效问题被公司开了”的时候，我感到了在这 HR 考评背后一股非常强的暗流和不可见的力量让她干出了这样一件匪夷所思的事。

——技术人的“绩效考核” 陈皓（左耳朵耗子）

程序员的绩效怎么考核

要么”被裁员“要么奖金相差小几十万，这些都要靠年终绩效来决定。那么如何用绩效来评断程序员的工作呢？尤其是如果这家公司还是一家小公司，是不是就更难了？

在 InfoQ 的一次活动上，有人提出这样的问题：”我目前带 40 人的研发团队，正在考虑考核问题，我分了三部分：第一部分仍然保持主观打分，第二部分是量化的东西（Bug ），第三部分是额外的工作。请问这种量化是正确的吗？“

在考评中加入可量化的指标来考核一名程序员确实是可以做到更公平公正，但是以 Bug 数来评定，这就有些”狗血“了吧。历史上我们也是见证过好几种“程序员工作成绩”衡量指标的，比如 Bug、代码行、提交次数等等，这些科学吗？

以代码行为例，代码行大约有 70% 是噪音，比如空行、评论等。而且编程语言之间的差异也大，比如在 CSS 文件中编写的一行代码与在 Java 文件中编写的一行代码的工作量有很大的不同。因此，根据这个指标，“最有价值的开发人员”往往是添加最多 CSS、空白和第三方库的人。

再说提交计数。从概念上讲，提交只不过是开发人员工作过程中的一个“保存点”。程序员多久会保存一次他们的工作要看个人喜好。如果你使用“提交计数”作为指标来考核开发人员，那么你实际上是鼓励他们培养一种个人偏好，写完一行代码就提交。

偏差较小的衡量应该是将多个指标放到一起使用：

• 需求交付时间（Lead time)：从创意到交付软件需要多长时间。

• 周期时间（cycle time）：对软件系统进行更改并将该更改投入生产环境需要多长时间。

• 团队速率（team velocity）：团队通常在一个迭代（或叫做 Sprint）中，完成多少个“单位”数量的软件。

• 缺陷开/闭率（Open/Close ）：在特定时间段内，报告和关闭的生产问题数量。总体趋势比具体数字更重要。

• 应用的崩溃率（application crash rate）：应用程序崩溃的次数除以使用次数。

• …

留住老程序员

G 是一位老程序员，经历过十几次的绩效评估。对于这些评估，他吐槽说很大一部分感觉结果并不公平，也数次因为不满绩效考核而选择离职。评判经验丰富的老程序员的工作，更要让大家“心服口服”。

对软件工作进行评估难免在某些部分会产生偏差。消除偏差的方式，可以利用复核评议，用面谈进行解决。面谈之前双方需要收集足够多的信息，用来纠正“遗漏”或“片面”的评价：

• 1 v 1 会议记录。

• 程序员在参与的项目中负责了哪些功能，难度如何？

• 产生的输出：代码，文档，电子邮件。

• 收到的反馈：同行反馈，通过电子邮件或其他方式收到的感谢，以及能找到的其他反馈。

• 给出的反馈：代码审查、计划文档审查、与他人的交互。

此外复核评议也是保持两者之间信任的关键。特别被打”低绩效“或面临“被离职”时候的面谈，这一环节也最容易出事儿或“上新闻”，如果公司的”解释权“使用不恰当的话。

“如果事情有可能变坏，它就迟早会变坏。”——墨菲定律

墨菲定律总是给我们无情的打击。软件研发的绩效管理是如此之难，其副作用是如此之多，以至于很多时候为了处理问题我们已经耗费了大多数精力。怎么在这种复杂环境中应用好绩效管理，避免副作用，让绩效管理真正能激发员工激情，推动组织创新，成为公司绩效的发动机？这是值得深思的问题。

结束语

作为程序员的你，今年的年终奖发了吗？奖金高的话说出来让大家酸一酸？

你有没有因为什么 Bug 使你的绩效受到影响？

你认为你的年终绩效结果，老板打的分数合适吗？不合适也欢迎在评论区留言吐槽！