这是一个创建于 1598 天前的主题，其中的信息可能已经有所发展或是发生改变。
想和大家探讨的话题是：互联网行业技术团队的技术考核这个话题。
首先，这个话题很大，技术团队：前后端开发、测试工程师、设计师，产品经理。 每个岗位的绩效考核指标都不一样。
其次，不要告诉我用什么 bug 数、工时数、线上 bug 等这些简单的指标做统计，明显有弊端的，架构师写的一个 bug 和一个初级工程师的 bug 不在一个级别上，架构师的一个小时和初级工程师的 10 个小时也不能简单的比较。
所以，我其实作为技术部经理，技术部的绩效考核其实是我一个很头疼的事情，挺难做的比较客观、科学，有说服力。
我现在还是主观考核为主，客观指标为辅的方法，因为如果全部按照客观指标，那么，就会出现很多为了指标好看而做出来更愚蠢的行为。
大家有什么好的办法和思路可以分享下么？感激不尽。
第 1 条附言 2021 年 12 月 11 日
看了大家的留言，收获满满，但是开发人员的绩效考核，不仅仅是代码输出，还有其他方面，我能够总结出来的方面：
1. 在代码输出之前的需求梳理和方案确定能力。
2. 代码输出：主要偏业务上的实现了，这个可能已经是需求已经梳理好了，方案已经确定了，后面的 coding 阶段。
3. 团队增益：技术分享、帮助他人解决问题、团队奉献（组织团建、服务他人等）
4. 日常表现：出勤、工作态度、是否服从管理、是否有团队精神、大局观意识、配合团队工作等。
其实我在日常的部门管理的时候，可能还会涉及到不同的岗位，需要考核的部分还不太一样，例如：产品经理、后端开发、UI 设计师，都不会一样的，如果全部细化的考核，需要花费很大力气，可能效果还不一定会好。
就像有同学说的，中小公司适合主管为主、客观指标为辅，我现在的做法基本也是如此：
客观的指标我会收集，基本是按照行业上主流的指标，但是，决策的时候我不能完全按照这些指标，因为可能指标不能完全反映这个人的真实绩效，所以，大方向还是主观判断。
1. 在代码输出之前的需求梳理和方案确定能力。
2. 代码输出：主要偏业务上的实现了，这个可能已经是需求已经梳理好了，方案已经确定了，后面的 coding 阶段。
3. 团队增益：技术分享、帮助他人解决问题、团队奉献（组织团建、服务他人等）
4. 日常表现：出勤、工作态度、是否服从管理、是否有团队精神、大局观意识、配合团队工作等。
其实我在日常的部门管理的时候，可能还会涉及到不同的岗位，需要考核的部分还不太一样，例如：产品经理、后端开发、UI 设计师，都不会一样的，如果全部细化的考核，需要花费很大力气，可能效果还不一定会好。
就像有同学说的，中小公司适合主管为主、客观指标为辅，我现在的做法基本也是如此：
客观的指标我会收集，基本是按照行业上主流的指标，但是，决策的时候我不能完全按照这些指标，因为可能指标不能完全反映这个人的真实绩效，所以，大方向还是主观判断。
 | 1 wsseo 2021 年 12 月 9 日 中小公司可以“主观考核为主，客观指标为辅” |
 | 2 leeg810312 2021 年 12 月 10 日 via Android okr 可以了解一下 |
 | 3 zpxshl 2021 年 12 月 10 日 via Android 不是很明白你为啥要拿架构师跟初级工程师比... |
 | 4 iceheart 2021 年 12 月 10 日 via Android  11 以前没考核的时候，公司氛围非常好，大家都有主人翁意识，相互帮助，处处为公司考虑，人员流动率很低。 后来有了考核，就慢慢变了，人员流动频繁，个人自扫门前雪，都忙着争利益甩锅，人心越来越寒，都没了主人的觉悟。 唉.... |
 | 5 Kontinue 2021 年 12 月 10 日 @wsseo 没错 我司传统软件公司，基本就是看 leader 主管考核，但和互联网相比感觉就没那么透明，奖金也是自己到手多少才知道，不像互联网公司那样会提前沟通告知 n*4 啥的 |
 | 6 GiantHard 2021 年 12 月 10 日 via Android |
 | 8 yaphets666 2021 年 12 月 10 日 1 @stoneabc 大锅饭呗,谁要加薪谁就去找领导聊.成绩特别突出的,解决了重大问题,做出重大贡献的,公司会主动给加. 这样就是大家比较轻松,没有日常考核,然后大家比较融洽,这样其实效率非常高. 如果想要很多奖金,晋升机会比较多的,那势必不可能采用这种大锅饭方式.那就要卷起来的,就要竞争起来了,也跟轻松无缘了. |
 | 9 nicholasxuu 2021 年 12 月 10 日 @iceheart 那是考核项目本身有问题，过于注重于被考核人员的个人直接成绩（容易的部分），没有注意到员工对别人的帮助和影响。 |
 | 10 qsnow6 2021 年 12 月 10 日 大锅饭不靠谱，如果没有考核指标来衡量，也就无法客观的筛选出对团队做出贡献的人。如果团队里每个人都找你加薪，没有客观指标来衡量，你给还是不给？该给谁？不该给谁？ |
| 12 GiantHard 2021 年 12 月 10 日 @dany813 跟代码量不完全相同，这里用的是开发当量。开发当量的计算对象是对一段代码的修改，假设我们修改前的代码是 old.java, 修改后的代码是 new.java, 开发当量是基于 old.java 修改成 new.java 的编辑来计算的。 开发当量不同于代码量的另一个地方是加权机制。开发当量的计算会先将代码转换成 AST ，然后按照对代码的修改类型（例如新增字面量、重命名变量等）、修改方式（例如新增、复制、删除）对每次代码修改进行工作量的评估。从而能够消除代码书写风格的噪音，更好的理解代码的语义变更，相对客观的反应程序员的代码产出。对实际开发中常见的拷贝代码，自动生成代码等场景进行了优化，智能地消除干扰，从而使开发当量更加真实的反应实际的开发工作量。 对于你这种需要进行绩效考核场景，可以分析整个代码仓库每个人的开发当量，从而得出每个人对整个代码库的贡献。比如你可以对比各个项目每人每周的开发当量，在项目这个级别上进行效能比对。 |
 | 13 qjbcnrs 2021 年 12 月 10 日 @GiantHard #12 存在一个问题，比如修复 bug ，可能看了一天，只需要改动一行代码。开发新功能，一天能写几百行。难道修复 bug 比开发新功能更简单？ |
 | 14 leo108 2021 年 12 月 10 日 2 @GiantHard 不适合聪明人多的团队，在这个评价体系中花一天思考从而写出简洁易懂的代码不如无脑堆屎山。 另外 https://www.merico.cn/ji-zhu-jing-li ji-zhu-jing-li 是什么鬼？ |
| 16 GiantHard 2021 年 12 月 10 日 via Android @zhongjun96 目前其实没有很好的方法仅通过单一的指标就能够衡量程序员的绩效。开发当量可以作为一个更加客观公平的指标，帮助你进行主观的绩效评估。 |
 | 17 iugo 2021 年 12 月 10 日 如果自驱力都很强, 没有绩效才好. 我能想到的最好的方法就是小团队内的技术经理一天到晚就看代码, 团队内的项目经理一天到晚就看大家的沟通. 每一个加减分的项目都记下来, 到时候将问题项目匿名化让大家根据所有问题进行逐项计分. 坏处就是为了追求绩效的尽量公平而浪费了人. |
 | 18 jenlors 2021 年 12 月 10 日 同样推荐： https://www.merico.cn ，我感觉还是比较客观的 |
 | 19 invdan 2021 年 12 月 10 日 还是用 okr 做绩效面谈，然后每个人写目标吧，最终根据部门的 O ，来定每个人的绩效贡献比 |
 | 20 jsion 2021 年 12 月 10 日 需求评审，大家一起给所有需求实现难度以 1.0-5.0 数值打分，谁最后接手难度大的并且完成，那么即可获得分数，统计一下数量和分数分布，用于辅助客观评价成员活动 |
 | 21 Rwing 2021 年 12 月 10 日 是的，很头疼，我也想听听各位的意见 |
 | 22 leiuu 2021 年 12 月 10 日 1 没有银弹。 感觉用类似任何「代码编辑量」的指标衡量都有点误入歧途的意思。 如果团队水平很平均，没有层次，其实每个人绩效都接近，这种反而好打绩效。 如果团队水平有明显的层次，用类似 OKR 的方式，看关键产出的完成率以及完成质量其实估计能明显区分出来的。 但是后者对 tl 的要求就高，需要鉴别水分，对技术有足够的了解。 |
 | 23 Pipecraft 2021 年 12 月 11 日 让每个人总结自己各个阶段做的事情，做的结果，给团队和公司创造的价值，有什么创意和挑战。 有些人虽然做的事情很多，觉得自己做的多，绩效应该好，可是做的事情创造的价值不大，或本可以有更好的办法提高效率，确不愿意思考，保守于旧思维与旧方法。 |
 | 24 mrliusg 2021 年 12 月 11 日 真正困难的应该并不在怎么定绩效？ 而是定了绩效之后，怎么让大家知道为什么被定了这个绩效 再进一步的，在下个阶段里应该怎么进行去调整自己 毕竟团队整体进步了，大家才能稳定升工资 |
 | 25 WilliamYang 2021 年 12 月 12 日 @leiuu 赞同用 OKR ，但最终评价的还是人，也就要求 tl 是否能够做到客观评价了，但现实上，很多都或多或少带有主观和偏见 | /tr>
 | 28 2i2Re2PLMaDnghL 2021 年 12 月 13 日 《古德哈特定律》 当压力施于其上以进行控制时，任何观测到的统计恒性都倾向消散。 说若一个经济学的特性被用作经济指标，那这项指标最终一定会失去其功能，因为人们会开始玩弄这项指标。 一个量度好不好同客观与否无关。（真要说代码量可太客观了，难道还有比这更客观的？） 它的必要条件是不可被取巧地通过。 The Lesson to Unlearn <http://paulgraham.com/lesson.html> 及 HN 评论 <https://news.ycombinator.com/item?id=21729619> 如果你是以逐利为目标，那么绩效考核应当直接统计产出，可采用代码完成的计算的价值（比如对每个 API 定一个虚拟价格乘以调用次数）减去计算的代价（比如调用这个 API 消耗的 CPU 时间乘以调用次数）。 对于 BUG ，可以定损并视为『减少或避免损失』。 |
 | 29 linshenqi 2021 年 12 月 13 日 我们可能采用 okr ，先看看吧。。 |
 | 30 lapulasi 2021 年 12 月 16 日 考虑某个技术团队的工程师 A 和工程师 B 。 A 是算法工程师，可能几十行代码就将原来的算法性能提升了 10 倍。 B 是开发工程师（非算法方向），写了几百行业务代码，实现了某个小功能。 |
Select Language