大家好，我是Z哥。我坦白，这篇是早就写好的库存文章，包括上周的那篇也是。
原因是最近跳槽了，到新公司忙得飞起，都没时间写文章。还好我之前未雨绸缪准备了几篇提前写好的文章作为余量～
我尽量能保持不断更，如果实在顶不住就周五的时候给大家请假哈。
好了，回到这次聊的正题。
研发考核难是整个软件开发领域众所周知的问题，甚至可以说是跨世纪的难题了（上个世纪开始至今未被有效解决）。
近期我对这个问题有了一些新的思考，在这里和大家分享交流一下。
很多人觉得因为研发考核很难考，所以索性就不考了。这个就有点因噎废食了。
首先我们要搞清楚，考核存在的意义是什么？
我的理解是：为了达成团队的共同目标。为了更好的管理团队、驱动团队力往一处使。
但是管理大师德鲁克又说过：
你如果无法度量它，就无法管理它。
德鲁克
这句话既然能被各个时代的管理者所追捧，存在了几十年，自然有它的道理。
所以，不管我们是不是为了考核，都得找到度量的方式方法。
有些团队的确找到了不少度量指标，但是大多偏向技术层面，包括我们团队之前也是如此。
这些指标一旦在具体实施之后往往发现效果甚至不如没有考核的时候。这个背后的原因也有很多文章提到过，就是那些指标不适合考核。
也有一些人经历了上面这个阶段后觉得研发的考核不好做，不好量化。实则是因为找不到那种直击要害的关键指标。
从这个问题的本质上来说，大家之所以觉得研发考核难本质是由于研发工作的三个特点导致的。
01 无法标准化
这里的无法标准化并不只是难以度量，而是说同样完成一个任务，不同的人会有不同的做法，最终的结果也可能会差别很大。
比如，同一个任务，有的人做了 5 天，有的人做了 10 天；有的人喜欢花很多时间在前期的设计阶段，有的人则会花更多时间在后期的自测上。但是你也不能说一定是谁的方式更好。
02 工作透明度低
实现同样一个功能，如果有合理的代码封装，可能只要 100 行代码。但是如果不花时间去构思封装，那么可能是 500 行，甚至是 1000 行。
此时，如果没有第三者进行 codereview 的话，甚至可能会觉得写 1000 行代码的人产出更大。
03 工作时间的碎片化
不得不说，大多数人的工作时间其实大部分时候很难完全由自己掌控，一会有人找你问个事，一会需要参加一个会，一会又来个电话接一下。
这些被动的意外之事都会使得做度量这件事变得困难，甚至还会将原来的计划打乱，导致某些考核指标出现失真。
Z哥觉得研发考核指标怎么定这件事应该分为两个问题去看。
能够度量的指标有哪些？
怎么考核？
这两个问题之间其实没有必然联系，如果老想着一箭双雕，一次解决两个问题，就会陷入前面提到的困境中。
我认为大部分的指标是用来作为帮助决策的信息源，而用于考核的指标不一定要多，要有业务价值。具体我来展开说说。
/01 能够度量的指标有哪些/
相信有不少指标已经马上在你的脑海中跳出来了：
代码行数
工时
bug 数
……
很多讲考核的文章都会对这些指标嗤之以鼻，因为这些指标不适合用来考核，这是针对流水线工作性质的考核产物。这点不否认。
但是也不能否认，这些简单的指标中也蕴含着有价值的信息。
因此在我的理念里，认为不应该主动放弃任何能被度量的指标。正如前面所说，研发工作本身就具有无法标准化、工作透明度低、工作时间的碎片化的特点。我们好不容易找到一些指标能够帮助我们更清楚的认识我们的工作做得到底如何，为什么不要呢？
不适合考核不等于我们可以忽略他们。这也是我认为要将这事分为「能够度量的指标有哪些？」和「怎么考核？」的原因。
除了这些大家都知道的指标，还有很多指标可以被度量。它们主要分为两个维度：过程指标和结果指标。
常见的过程指标有：需求响应周期、发布前置时间、交付吞吐量、线上问题平均解决时长等；结果指标有：日均新增 bug 数，日均 bug 库存数，线上问题数量等。
如果你所在的团队对工程效率比较重视，相信还有不少指标可以被度量出来。
这些指标有什么用呢，我们需要每天观察他们的变化，便于及时发现团队里正在发生的变化是否符合预期。比如，
最近并没有太多并行开发的版本，为什么平均交付时间反而变长了？是不是不够敏捷？
比如最近生产环境的 bug 数明显变多了，是不是质量团队出了什么状况？
……
/02 怎么考核？/
用上面列出的这些指标来考核吗？自然不是。
Z哥认为考核还是得从业务下手，要想办法找到与技术有一定关系的业务指标，比如，DAU、用户平均停留时长等等。
可能很多人第一眼会觉得说，这些指标有很大比例是由业务决定的，技术在其中起不了什么作用。
其实并不然，你想象一下。如果我们的拉新用户承接页的稳定性不好，或者核心业务链路经常出错，这对 DAU 和用户平均停留时长必然会造成不好的影响。所以，业务指标真的与技术无关吗？其实并不然。
怎么落地为考核呢？我的思路是建立在两个逻辑之上的：
业务指标的移动平均值在一段时间里是一条趋势向上或向下的曲线。平均范围越长，曲线越平滑。
技术在短期不能显著提高业务指标，但可以降低业务指标。
基于这两个逻辑在落地为考核的时候有两种方案。
一种是长周期考核，比如每半年或者每年一次的 OKR 考核。这种考核直接用指标在开始时和结束时的差值即可，大多数的偶发性事件直接被平滑掉了。
另一种是每个月都要进行的短期考核。这种考核建议使用环比变化作为依据。比如比上个月提升了就奖励，降低了就惩罚，这样从长期来看，偶发性事件带来的影响也被平滑掉了。当然这里的奖励和惩罚不一定是物质形式的，也可以是精神形式。
可能有的人会觉得，这样的考核如果在业务快速发展期，不是躺赚吗？
是的没错，只要技术能支撑快速发展的业务，不拖业务的后腿，我认为就应该奖励。至于是不是躺赚，关键还是看选择的业务指标以及如何制定具体的奖惩尺度。
今天就聊这么多吧。
研发考核这事和研发工作一样，没有「Sliver Bullet」，我今天和大家聊的也只是我的一家之言，欢迎大家一起探讨。
本质上，我们也是在讨论，如何更好地向非技术人员展示我们技术人工作成果的好坏。
好了，总结一下。
这篇呢，Z哥和你分享了我对研发考核这件事的看法。
首先，我认为考核还是要考的，不考核肯定不行。研发工作性质的三个特点导致考核指标很难定。
无法标准化
工作透明度低
工作时间的碎片化
所以，我的建议是找指标管找指标，考核管考核，两件事分开看。
我们要尽可能多的收集研发过程和衡量结果的指标，它们不一定用来考核，但可以用来及时发现团队中的潜在问题。
关于考核指标还是建议使用业务相关的指标，从中挑选有一定技术影响程度的。也分享了两种落地方案，分别是长期用 OKR，短期用环比来考核。
希望对你有所启发。抛砖引玉，欢迎在留言区分享你的观点。
