编者按：本文来自“InfoQ”（微信大众号ID：infoqchina），作者：Tina，36氪经授权发布。
年末了，各企业年度绩效都做完了，未来还能撑得下去的企业都开始发年终奖了。
前些天，腾讯发年度终奖的音讯爆屏了。先是腾讯云的阳光普照奖，人手一台 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 使你的绩效受必定的影响？
你以为你的年终绩效成果，老板打的分数适宜吗？不适宜也欢迎在谈论区留言吐槽！
封面图来自pexels
