创业团队如何正确衡量技术人员绩效

为什么要考核

很多团队都会定期（月、季度、半年）进行绩效考核。为了刺激绩效，通常又会和经济利益绑定（奖金、期权）。但是绩效考核只是为了找到一种奖金的“合理”的分配方式吗？
当然不是。初衷肯定是通过奖金来激励大家做出更多的贡献。对于创业团队，正确的做出绩效评定就更事关重大了。在一个小团队中，技术人员是否积极主动对产品的影响区别很大。一个对团队有着高度信任、对产品充满使命的程序员；和一个只是为了完成工作任务按时交付的程序员，对于团队的贡献差别几倍是很有可能发生的。

常见的问题

错误的衡量指标

老板最喜欢看数据了。销售部门可以通过销售额直观的看出，人事部门从简历数量、招聘效率来衡量，技术部也一定可以找到一个数字来衡量。
工地上搬砖搬的多的人贡献最大，程序员就用代码量来衡量吧。这实在是一个很“文盲”的维度，编程是带有一定创造性的工作。可能花了一天时间解决了一个非常严重的bug，只有几行代码。有些UI程序员复制粘贴可能一天就几千行代码了。前者代码量比后者小100倍，贡献就小100倍吗？
虽然程序员觉得可笑，但这却真实存在于行业里。我曾供职的一家公司月度考评的指标是提交代码所涉及的文件数。初衷觉得是你做的多，肯定涉及代码文件就多。但是有一次一个全局的配置文件要改，类似每个请求的默认分页数从20改成50。因为项目多年，所以四处代码里散落着这些hard code。这种搜索替换的工作肯定交给小弟做了，于是当月这个小弟获得了技术团队的绩效第一名。

对接部门打分

这也是我曾供职团队的一个考核维度。大概思路就是和你对接的人对你的评定是有认可标准的。以程序员角度来说，绩效由产品、设计、运营来打分。看起来很美好，很可能造成的结果就是程序员和产品、设计撕逼再也没底气了，因为担心如果和他们进行争论，自己绩效会被故意降低。这样虽然大家和和气气，但是对于最终产品却是不利的，得到的是一团和气。

盲目的民主

有的团队绩效排名由团队成员投票选出，期待这样得到一个大家都认可的公正结果。虽然初衷好弊端也很明显。大家在一起只能看出你工作是不是努力，但是不能看出你的工作对团队的贡献大不大。很可能出现某个员工因为效率高，总是按时交付，bug少。另外一个代码糙，虽然总是交付的很快，但是交付只能加班焦头烂额的改bug，大家都觉得这个人工作好努力，走的晚，做的多。
另外一个可能的情况是小团体的抱团，也不能直接称为作弊，只是人多了之后总有几个人是走的近的关系比较好，最后投的时候可能会不自觉的分数打的高了。
这种模式最后筛出来的是看起来努力、人缘好的员工。但是这样的员工对团队贡献是最大的吗？其实未必。

模糊的上级评定

更多时候绩效是写了工作总结，上级沟通后得到一个绩效。有些被私下告知，有些优秀的被公布出来。也许得到的是一个相对靠谱的结果，但是得到C的人内心肯定会疑问：为什么我是C不是B？我如何才能得到B？某某是不是和领导走的近所以绩效高？
通常绩效优秀的同学领导都会语重心长的说好好干，表示给予厚望。但是对于大多数的普通员工只是得到了一个结果，他们得到的不是激励，而是迷茫。

不及格的统计学

团队里肯定有10%优秀的人，10%可以被淘汰的人，30%一般的人。技术团队有20个人，那就淘汰两个，6个人绩效D。分配指标也是上级热衷的事情，执行明确。但是10个人里就一定有一个人是要被淘汰的吗？虽然统计学是有道理的，但是那是大数下的统计概率啊。如果有两个产品团队，一个团队做的差，可能10个人里5个人都应该淘汰；另外一个团队齐心协力，大部分人都很优秀。这种情况也要死板的按照概率来考核吗？

衡量的出发点

那么应该如何衡量呢？我们要再次明确绩效要达到的目的：激励对整个团队目标（产品）贡献大的员工。一个人虽然很努力，可是对产品没有实质性的贡献，为什么要奖励呢？
可以从以下几个维度进行考核。

劳动生产力/结果

这个是显而易见的，产出多的人肯定是值得肯定的。这里要注意不是看起来勤快，而是产生的结果。某些核心的模块工作量看起来不大，但是写起来却很考验技术能力。考核工作时要注意提高这部分的权重，而不能单纯的通过代码量来判断。

对团队的贡献

团队里总是有一些工作是没有明确的划分的。如果员工不止完成了本职工作，还为团队做贡献也应该算到绩效中。比如移动端工程师对设计师解释移动平台人机交互规范。或者需求前期对产品提供技术咨询帮助制定需求等。这些工作都没有明确责任划分，然而却又确实花费了精力，最后的结果也对整个团队有益。应该鼓励这种行为，促进大家都以团队为整体考虑。不应该觉得这不是工程师的本职工作就不值得鼓励。

对产品的贡献

论坛上看到一个用户提到app有反馈是应该装作看不见还是主动去沟通跟进问题，即使这块代码不是你写的？产品提的这个需求在业内有更好的做法，是不是应该指出来告诉他？或者有一个更复杂但是体验更好的方式，我是不是应该提出来？SDK推出了一个很好用的新功能，要不要主动去研究一下告诉产品？
这些都和编程无关，但是如果是这种做事态度显然能提高产品的质量。如果团队每个人都为产品的方方面面出谋划策、视为己出，该不该为员工这样的行为作出肯定呢？

考核方式

考核方式我认为是上级通过工作汇报、和各员工的沟通了解后作出决定。最后公布结果的时候从上面提到的三个维度说明评为优秀员工的具体原因。这样其他员工就能明确的知道公司所鼓励的工作方式内容，对于培养好的团队文化也能起到一定的作用。

延伸阅读

构建之法:现代软件工程