互联网技术团队的绩效考核应该如何去做？

[davidshen]

想和大家探讨的话题是：互联网行业技术团队的技术考核这个话题。

首先，这个话题很大，技术团队：前后端开发、测试工程师、设计师，产品经理。 每个岗位的绩效考核指标都不一样。

其次，不要告诉我用什么 bug 数、工时数、线上 bug 等这些简单的指标做统计，明显有弊端的，架构师写的一个 bug 和一个初级工程师的 bug 不在一个级别上，架构师的一个小时和初级工程师的 10 个小时也不能简单的比较。

所以，我其实作为技术部经理，技术部的绩效考核其实是我一个很头疼的事情，挺难做的比较客观、科学，有说服力。

我现在还是主观考核为主，客观指标为辅的方法，因为如果全部按照客观指标，那么，就会出现很多为了指标好看而做出来更愚蠢的行为。

大家有什么好的办法和思路可以分享下么？感激不尽。

[Rwing]

是的，很头疼，我也想听听各位的意见

[leiuu]

没有银弹。
感觉用类似任何「代码编辑量」的指标衡量都有点误入歧途的意思。
如果团队水平很平均，没有层次，其实每个人绩效都接近，这种反而好打绩效。
如果团队水平有明显的层次，用类似 OKR 的方式，看关键产出的完成率以及完成质量其实估计能明显区分出来的。
但是后者对 tl 的要求就高，需要鉴别水分，对技术有足够的了解。

[Pipecraft]

让每个人总结自己各个阶段做的事情，做的结果，给团队和公司创造的价值，有什么创意和挑战。
有些人虽然做的事情很多，觉得自己做的多，绩效应该好，可是做的事情创造的价值不大，或本可以有更好的办法提高效率，确不愿意思考，保守于旧思维与旧方法。

[mrliusg]

真正困难的应该并不在怎么定绩效？
而是定了绩效之后，怎么让大家知道为什么被定了这个绩效
再进一步的，在下个阶段里应该怎么进行去调整自己
毕竟团队整体进步了，大家才能稳定升工资🐶

[WilliamYang]

@leiuu 赞同用 OKR ，但最终评价的还是人，也就要求 tl 是否能够做到客观评价了，但现实上，很多都或多或少带有主观和偏见

[dany813]

@jsion 这个我们很早就尝试过，后来就废了，领导没推下来

[xuanbg]

@qsnow6 大锅饭吃得好的前提是领导要英明神武，处事公正，大家服气。。。所以对于大多数团队来说，有考核还是要比没考核好的。

[2i2Re2PLMaDnghL]

《古德哈特定律》
当压力施于其上以进行控制时，任何观测到的统计恒性都倾向消散。
说若一个经济学的特性被用作经济指标，那这项指标最终一定会失去其功能，因为人们会开始玩弄这项指标。

一个量度好不好同客观与否无关。（真要说代码量可太客观了，难道还有比这更客观的？）
它的必要条件是不可被取巧地通过。
The Lesson to Unlearn <http://paulgraham.com/lesson.html> 及 HN 评论 <https://news.ycombinator.com/item?id=21729619>
如果你是以逐利为目标，那么绩效考核应当直接统计产出，可采用代码完成的计算的价值（比如对每个 API 定一个虚拟价格乘以调用次数）减去计算的代价（比如调用这个 API 消耗的 CPU 时间乘以调用次数）。
对于 BUG ，可以定损并视为『减少或避免损失』。

[linshenqi]

我们可能采用 okr ，先看看吧。。

[lapulasi]

考虑某个技术团队的工程师 A 和工程师 B 。
A 是算法工程师，可能几十行代码就将原来的算法性能提升了 10 倍。
B 是开发工程师（非算法方向），写了几百行业务代码，实现了某个小功能。

[pysex]

@linshenqi ORK 怎么跟绩效挂钩