我推荐的方式是选用OKR。
很多公司到了一定规模的时候，就需要开始量化程序员在公司里的一些贡献，或者评判程序员的优劣。
程序员毕竟不像销售或者流水线工人，他们没有明确的一个指标来进行产出的衡量标准。而且也确实不太适合，总不可能用修复Bug数量又或者是写的代码行数来作为依据。
我曾经听过一些同行使用实现需求数量来作为衡量标准，但面临的问题是，需求有大有小，每个需求所需要的工作量是不一样的，所以如果用需求数量来做衡量的话是相当不公平的。
那是否可以用实现需求时的有效工作时长来作为依据呢？这又会牵扯到另外一个问题，一个需求的真正所需工作时长究竟是多少？又以谁评估出来的时间的为准？如果评估出来的时间不准确，是否会影响到评价的准确性？任务难度级别又如何加权等等……
有太多太多的模糊的因素干扰着指标的量化过程，以至于最终很难落地，又或者说落地后的效果并不理想。
那究竟应该怎么制定才会比较合理呢？
让我们重新回到起点，程序员的所谓贡献究竟是什么？无论是产品从0到1，还是上线运营后的性能优化，其实最终都是围绕着一个东西，那就是公司收益。而提高收益可以分为提高营收和降低成本两个方向。
所以作为技术总监，就很用必要地把提高收益放到最上层的O上，然后再拆解为收益提高多少？成本降低多少？两个KR。然后再把KR定为O再交给下面的人来拆解，比如：
客户端的启动加载速度提高从5秒降低到2秒；
推荐算法优化，使得用户停留时长增加20%；
一台同样配置的服务器，同时承受的并发量提高20%，
等等……
同时结合A/B Test以具体优化的数据转化为实际收益，用收益的增量来量化效果与成绩。
这样我们每一件任务做完了之后，就可以得到一个效用反馈。最终让成员的工作成果得到量化，从而作为评估标准。
网友评论