<p><img src="https://simg.open-open.com/show/67858501d8ae58df7a9ced9029d69a15.jpg"></p>    <p>前不久看到个新闻，Amazon 美国的一个中国 IT 工程师在西雅图办公室跳楼自杀，原因是收到了 PIP。那 PIP 是什么？就是 Performance Improvement Plan 的简写，表达的意思大概就是，再给你点时间改进工作绩效，否则就请走人。但实际收到 PIP 95% 的情况都是走人，这样实际的意思就变成了，再给你点时间赶快找下家吧。</p>    <p>但这哥们在美国工作，拿的是工作签证。如果失业了，就意味着工作签证失效，在美国也就待不下去了。各种压力一起涌来，一时想不开就跳楼了。这个故事里面有个关键词：绩效，而且是程序员的绩效。关于程序员的绩效，像是一个弥久的历史谜题，长期困扰着大量的程序员与他们的领导们。</p>    <h2>工具与方法</h2>    <p>KPI（Key Performance Indicators 关键绩效指标）是企业最爱用的绩效考核工具，但 KPI 通常只能定一些更宽泛的指标，且一般也只能分解到团队经理的头上，而很难分解到具体每个程序员的身上。</p>    <p>在我工作的历史上，换过几家公司，每家公司都使用一种粗放且独特的方式来考核程序员。第一家公司，工作完一年后我才知道什么叫绩效考核。因为它们采用的是年度考核，一年过去到了年末经理跑来告诉你说你今年的绩效还不错，然后也不知道不错是个什么水平。</p>    <p>总之是不错了，但最后也没有加薪奖金什么的。努力回顾一年的工作，发现记忆非常模糊，除了少数几件印象深刻的事。而那几件少数事件，都是我搞砸了的事情，而且还捅了不小的窟窿，获得了血泪换来的宝贵经验。这么一想可能觉得「不错」大概就是「有点差」的一个稍微温和的表达了。</p>    <p>说起按事件来评判绩效，就想起后来的另一个公司，他们就使用这样的关键事件法来评估全年的绩效。回想一下这一年自己做了什么特别的事情，有让身边的同事或领导都觉得很棒的事件么？有印象深刻的正向事件，那么就是优秀，如果是负向事件就是还需改进提升，其他就是一般了。表面看有那么一点合理性，但结合程序员的工作性质一想就不是那么合理了。</p>    <p>上面的方法要么只是模糊要么只是没考虑工作性质的差异，那么下面的这个公司的评估方法就完全扯淡了。当时公司采用强制分布绩效的方式，比如一个部门有 10% 的人得优秀，有 10% 的人得差，其他属于一般。这样的评估方式每月一次，直接和当月工资中的绩效奖金挂钩。</p>    <p>上面这么一强制分布下来，部门再分布到小组，小组长一看大家都是兄弟伙，一年有十个月出差于全国各地，天天加班不说，还要给人绩效评个差，于心不忍。大家一商量，那就轮流来吧，这次得了差的，过几个月就会得个优秀，这样的绩效评估基本也就流于形式，毫无意义了。</p>    <p>近年，像 Google 这样的明星公司大规模应用起了一种叫 OKR 的工具。OKR 就是 Objectives and Key Results 的缩写，表示目标和关键结果。这听起来和 KPI 很类似，但它们有个本质的区别是方向性的，KPI 一般是分解下来，要你去做的。而 OKR 是我要去做的，KPI 是考核工具，而 OKR 实际是管理工具，跟踪做事的目标和方向性。所以 OKR 也不是解决绩效评估难题的银弹。</p>    <p>综上，通用的这些绩效评估工具和方法，似乎面对程序员的绩效评估都不太有用，这是为什么呢？这也许要从程序员的工作实质说起。</p>    <h2>工作与评估</h2>    <p>管理学上有位大师叫彼得·德鲁克，他最早提出了知识工作者（Knowledge Worker）的概念，德鲁克生于 1909 年，所以他经历了从工业时代到信息时代的革命性变化。早期的工业时代只有工人和管理者的概念，那时的行业多是重资本推动的制造业，工人的特点是流水线的体力劳动，简单重复，过程很容易监控，产出结果的数量和品质也容易检测，所以个人的 KPI 很容易量化。</p>    <p>而德鲁克定义的知识工作者是：</p>    <p>那些掌握和运用符号与概念，利用知识或信息工作的人。</p>    <p>显然，程序员就是典型的知识工作者。知识工作者不仅利用知识，他们还会创造新的知识，从知识中获得洞见，进而产生智慧。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/5e79ad166d55d558fde75eec30f5d889.jpg"></p>    <p>程序员的主要产出是：代码或交付的软件系统。但软件系统的代码通常都是由多个程序员合作一起完成的，所以你就没法精确的测量每个程序员的贡献。也不要想当然的用一些简单粗暴的指标来考核程序员，比如像：代码行数。这样的指标容易定义，容易测量，所以这样的考核容易实施，而容易实施的考核总是首先被采用。但前提和出发点是错的，只会南辕北辙，离目标越来越远。</p>    <p>幸好应该大家都认识到这样简单的指标无法考评程序员个体的产出，但如果真得采用代码行数来评价的话，倒是能解决程序界的另一个亘古已久的争论：花括号 { 到底是写在一行程序的末尾还是另起一行:)。</p>    <p>硅谷创业之父 Paul Graham 在《黑客与画家》一书中写到：</p>    <p>程序员就是知识时代的手艺人，也是目前还存在的最大的手工艺人群体。</p>    <p>最顶尖的 5% 的程序员写出了全世界 99% 的优秀软件。</p>    <p>可见，程序员的个体差异导致的贡献度差异之大。但很遗憾的是我们至今没有任何可行的具体测量方法能精确的评估程序员个体的贡献度。所以 Paul Graham 继续说：</p>    <p>大公司会使得每个员工的贡献平均化。</p>    <p>大公司最大的困扰就是无法准确测量每个员工的贡献，大多数时候它只是在瞎猜。</p>    <p>我依稀记得看过一个来自英特尔的例子，原文记不住，大概简单重述下。是说有个负责芯片设计的工程师提出并改进了一种芯片设计和生产方法，应用到一条年产值 10 亿美元的生产线，提高了 1% 的产值。那么他的直接贡献很容易计算出来就是一年为公司多增加了 1000 万美金产值。但问题是我们该怎么奖励他的这次卓越贡献？</p>    <p>这个例子中还提到，他所在的芯片设计部门有一百多人，所以平均下来整个部门的人均额外贡献就不到 10 万美金了。所以，当年公司能给予他的奖励实际是远小于计算出来的实际增加值的，这就是一个大公司平均化的典型例子。但这个例子中，也不必感觉太不公平，实际离开了英特尔这样的大公司，那个芯片工程师很可能是无法做出这样的贡献的。大公司一方面平均化了个人贡献度，另一方面也为个人降低了风险同时提供了贡献的放大器。</p>    <p>反过来，如果是在小的创业型公司，它依然是平均化计算个人贡献度的。但人少了，被平均掉的就少了。对于小创业公司 Graham 的建议是：</p>    <p>你最好找出色的人合作，因为他们的工作和你的一起平均计算。</p>    <h2>结果与影响</h2>    <p>按 SMART 原则来评定你的目标和达成情况：</p>    <ul>     <li>Specific（明确）</li>     <li>Measurable（可测量）</li>     <li>Achievable（可达成）</li>     <li>Relevant（相关）</li>     <li>Time-bound（时限）</li>    </ul>    <p>其中只有「可测量」这一项在程序员个体上比较难实施，所以恐怕只能放弃精确的测量而转为目标导向。而所谓目标或 KPI 无非就是上级对下属的期望，然后再以此来判断下属的绩效是否合乎期望。如果上级没有明确对下属的期望，如果我们不知道到底要什么，最可能的结果是什么也得不到。</p>    <p>那评估的结果是否能以达成目标为依据呢？表面一听似乎很合理，但仔细一深入想想就有问题。如果上级只用目标管理来决定下属的升迁赏罚，以至于下属只专注于制定“好的”目标，即容易达成的 KPI，就会错失了其他可能。</p>    <p>哥伦布的故事证明了这一点，哥伦布设定了一个寻找到亚洲（东印度群岛）的新航线，但他最终却找到了美洲，并开辟了后来延续几个世纪的欧洲探险和殖民海外领地的大时代，因此：</p>    <p>即使一个下属没能达成所设定的目标，他的绩效仍有可能被评为卓越。</p>    <p>哥伦布当初定的目标和最后达成的结果存在差距，但并不能以此说他做的不好。过于绑定目标则限制死了路径并控制了风险，但激励创新意味着冒险，如果没有风险，就几乎等于没有可放大性。</p>    <p>但就个体而言，你需要分清楚评估个人绩效和提供机会让个人获得成长与提升的区别。所以，不妨把这两种效果分为：</p>    <ul>     <li>产出绩效</li>     <li>成长绩效</li>    </ul>    <p>前者是组织更关心的，后者是个人更应关心的。当然现在的组织都说很关心员工成长并提供相应培训，但更多时候组织是更倾向于在市场购买已经成熟的大树。所以你不应该等着组织想起来给你浇灌才去成长，成长绩效通常只能自己去评估，而且这点在很多组织也直接影响你的升级。</p>    <p>...</p>    <p>《程序员修炼之道》一书中写道：</p>    <p>注重实效的程序员不仅要完成工作，而且要完成得漂亮。</p>    <p>所以，请：“Care about your craft. Think! About your work.（关心你的技艺，思考！你的工作）。” 毕竟你还是个手艺人，还要靠手艺吃饭不是。</p>    <p>有时会面临这样一种尴尬局面：一群程序员里，你想提拔一个经理，难道不是应该提拔绩效更好的么？在你把超级程序员提拔为经理的同时，你也失去了你的超级程序员，并创造了一个差劲的经理。反过来，你去提拔一个差劲的程序员当经理，则更糟：一样创造了一个差劲的经理，而且可能会失去一群从超级到优秀的程序员。</p>    <p> </p>    <p> </p>    <p>来自：http://www.cnblogs.com/mindwind/p/6262822.html</p>    <p> </p>