KPI

关于程序员的绩效考核要不要考虑技术难度

众所周知 Facebook 内部运转的核心精神是“focus on impact”。这在软件工程师每半年一次的绩效考核上的体现就是：考核只考虑这半年做出来的结果而不考虑过程。如果通过改一行代码能让公司赚到与做一个复杂系统同样多的钱，那两者在评定上也是等价的。事实上公司也特别推崇“one line fix”。这可能是 Facebook 与 Google 在软件工程师绩效考核的理念上最大的区别，因为 Google 无疑是把技术难度看得很重的。

考核不考虑技术难度的好处在哪里？因为在机制上这可以把 impact 的生产效率最大化。Facebook 在早期本质上是一个产品驱动的公司，很多事情的瓶颈并不在技术上。在结果驱动的考核机制下，工程师们会自发解决那些技术之外的问题，而不是对没有技术难度的事情嗤之以鼻放在那不管闷头继续搞自己的代码。很多人说 Facebook 的软件工程师分担了一部分产品经理的责任，这话是有道理的。在考核机制的作用下，大多数的软件工程师会演化成 product generalist。

那考虑技术难度的好处在哪里？因为技术发展很多时候是非线形的。常见的一种情况是，研发的前几年进展很小，但超越拐点之后飞速发展。如果在每半年一次的考核中只考虑结果，那这些高风险高回报的技术项目永远不会被启动。Google 那么多 big bets，考核上看重技术难度是极为自然的做法。

当然事情总在变化中，我觉得 Facebook 大概率在不久的将来会在考核上更靠近 Google 一点点，因为新时代下技术在重新变成产品的瓶颈。大家不仅要 focus on impact，更要 focus on long term impact。