请教下程序员应该怎样考核？

会摸鱼划水的加工资

燃尽图

当然是按代码行数，哈哈

工作投入、产出质量，按比例考核

今天去面试，说没加班费；绩效里面也有按工作时长这项；
我？？？

笑版：
拆成功能模块后“拍卖”，谁出的考核分少谁拥有开发权，月底计算每个人的考核总分。
如果没人竞拍，就指定一个考核分，然后抓阄。

分几块看
1.团队贡献
2.质量与效率
3.项目完成情况

大方向是结合团队目标，如果团队没目标，那就不要考核了。不然，你想清楚考核的目的是什么

资深 hr 告诉你，程序员考核？自找苦吃

30 个人应该是有几个小组的，小组长主观评价？

质量 性能 效率 。活多 活块活好。

当然是三者结合了。首先是主观评价，谁会来事谁分高；然后看工时，和代码行数

团队目标那种更多是小组长以上人的事，用来框普通程序猿？也是牛逼了。

软件工程里面专门就有一个研究方向叫软件度量，个人觉得可以按功能点，bug 数和代码行数之类的建立一个量化的评价标准

管人很爽吧

一个技能档工资 + 项目效益啊

很简单。项目组长门清，你问他我拿张三和李四跟你换你们组的王大麻子，组长说滚，不换！
怎么样，人家考核 1 秒都不用。

当然是发量啊，这个最准了

你想考核程序猿？就 HR 那点算计人的智商怎么跟程序猿斗

@yiome404 @zengming00 我不是 HR， 也是程序员

1、考核能力而不是考核工作量、业绩
2、考核主动性而不是考核犯错的次数
3、价值观什么的老板最喜欢了。。。

分小组管理，组长负责组员情况，再考核组的情况
评估每个组的工作量、难度系数、价值
个人能力加分评估，很重要，对能力强的人表扬

OKR 了解一下？
https://www.infoq.cn/article/gU*236UQhE5FYgDsYXoB

还是组长门清吧，HR 视图指定一套规则来衡量程序员，按我待过公司的经历，最终都会导致很严重的抵制。

你这样考核的目的无外乎想外行管理内行。
管理人员先提高自己的专业姿势水平再想着管理。

考核和薪酬体系挂钩不

考核分数高钱多给吗

按颜值！

比较反感

按加班时间最客观。
加班越多水平越差。

@beginor 考核不就是为了扣工资的嘛， 不管你怎样设计方案， 只要扣钱了 ， 老板就认为你做事不错

@mikicomo 肯定会挂钩的

@askfilm 扣工资不是目的， 但是考核垫底的就不好说了

按效率， 工作流分状态，看板自动记录每个状态时间，个体和自己做比较

@lastpass 是的，就是想让外行管理内行。 你程序员不是牛逼吗，多干活，多拿分， 没 bug， 就 OK 了。 不行就别瞎 bb

@tt67wq 那是鼓励师

咱们本就是最会挖墙脚的民族，
你面对的还是这个民族中智商最出色的一群，
即便你智商也是一个水平的，
你能一个打十个？

HR 们你们就承认吧，
搞不过这帮高智商的孙子。。。
代码行数，bug 数量，加班时间，工作效率，
哪一个参数都可以摸鱼，
你信不信。
管那么多啥，按时出活就行了。。。

提到考核无非按时、按质、按量，至于怎么把具体工作对应到时、质、量，就需要考验组长们的任务拆解能力了。考核项的设定可以参考 S.M.A.R.T。

评论里很多 ver 提到被考核人抵触考核的问题，个人觉得其实主要是考核规则不透明，考核目的不单纯的问题。其中考核目的不单纯是最大的因素。

试想一下，如果你的考核目的就是要把一部分人挤走，或者就是为了进一步压榨剩余价值，那员工如果不抵触，我觉得肯定是脑子有问题。但如果你的考核目的是为了激励员工提高工作效率、提升工作质量，并围绕这个目的进行考核设计，我相信正常的员工不会有抵触。原因在于目的决定手段，是奖，还是罚。

考核规则不透明，主要是对于员工对考核点完成情况的评价方式、评估标准不透明。很少见到有公司的 leader 会公开一份像题主列的那么明确的加分 /减分规则。也很少有 leader 敢拍着胸脯说我制定的考核规则是在切合实际的基础上做到尽量公开、公平、公正的。我猜可能是因为他们的考核目的本身就不单纯，又或者他们对自己设计的考核标准是否合理也是心理画着问号的吧（手动围笑）

以上，一些个人观点，欢迎在友好的氛围下进一步讨论，抬杠的就算了，搬砖已经摧毁了我的身体，老了，抬不动了：）

@Dex7er 所以，要让程序员的工作产生数据，用数据来考核。 摸鱼肯定是少不了的， 但是不会让你摸得那么爽

@hzgit 说的太对了， 佩服佩服！

个人挺反感这种方式的，考核应该是用来鼓励

告诉你一个情况。
程序员可能某一天什么活儿都没出。但是他去学习了接下来项目中所需要的新知识。如果不学，项目 100 天完成，因为他学了 ，可以缩短工期 20 天，并且提高了软件产出质量。
请问各个精明的 hr，你要设计出一个什么样子的 KPI 来评判程序员的质量。
你是希望程序员假装干活儿很热闹，假装一副加班修 bug 的样子
还是希望程序员看起来没写几行代码，但是他就是 bug 少，质量高

@ritaswc 两个人都干掉，把工资给进来就可以 20 天搞定的人

我觉得一年以后你可以写一篇文章，叫：论程序员的从“同甘共苦”到“反目成仇”。
技术这东西不像销售，比较难量化。在小公司，如果非要用量化来体现员工价值，说明这个管理者的管理水平本身就是有问题的。

@deepzz 那么请问怎样鼓励才是合理的呢？

@ritaswc 所以考核是分阶段的，按月，按季度，而不失按天。 学几天新技术没问题，如果整月都在学习新技术，甚至整个季度都在学习，那就有问题了。

程序员还想考核？预估好工作量，按时完成就好了。要以目标为导向。参考：OKR

看 bug 多少吧，不好量化

脑力劳动，量化起来比较困难，而且也难以达到相对公平，一旦不公平出现，可能会促使内部矛盾。。。

用心去感受~

秃头程度(^)

在菊花待了一段时间，深刻认识到，即使像大厂这样花尽心思搞的考评体系，合理性也不过尔尔

@yuriko #52 对的，到头来，你真要较真这个，舔就完事了

@Edsie 确实是这样， 不可能做到对每个人都是公平的。 能做到对多数人相对公平的就可以了。

考核过 加工资么？

公司只需要定大方向和定大目标，然后落实细化目标给主管，主管自己再去拆分，要给到足够的自由和权力给主管，而不是事事关心！ 30 人的公司也不算小了吧。

@sanqian 那肯定了

看 bug 多少的。。。不知道多做多错么， 写越多错越多
看代码量的，也许系统核心部分占 10%，但重要程序也许比 90%的要大的多，开发占时间也可能长的多，难度也可能大的多
所以这玩意其实是真难衡量

建议楼主找找资料，看阿里或者 Google 对于程序员的绩效考核是怎么样的，看看是否有值得借鉴的地方

感觉 Story Point 可以尝试。
每一个任务是一个 User Story，Story Point 由团队成员共同评定，每个人单位时间可以完成不同量 Story Point，而随着能力提升，一个员工单位时间可以完成的 Story Point 是会增多的，最后根据完成的 Point 数来作为绩效评估的要素之一。

绩效评定可以采用类似 Peer Review|360 Degree Feedback 的方法，需要花费比较多的精力，但是相对公道，不会导致普遍性的反抗，唯一的缺点就是可能会导致死海效应。

开盘了，猜下可以执行多久，我猜一个月，因为我公司之前用过类似的，在不断变动的需求和填坑之旅后，果断放弃

想用点数或分数来量化绩效基本都是自找苦吃。

原因有：
1. 分数多的成员干的活的确会多，但干活多会有助于业务成功吗？写代码又不是搬砖。
2. 软件质量的成功很大因素在于团队协作，量化绩效会间接破坏团队协作，损害技术领导的领导自由度，进而阻碍创新。
3. 有的事情无法用点数衡量，但却很重要。比如，对业务的重视程度，技术选择的方向，团队成员能力的建设，促成团队成员的协作，对非技术流程的梳理及知识传递，等等。

那么最好的方式是什么，那就是拆团队，打通团队之间的流动性，考核整个小团队的产出，营造优胜劣汰的环境，并将产出和义务挂钩。

你考核多了，他们会主动挖坑的，本来不需要的坑现在变成必须完成的任务。

你怎么办？

到现在领导还没有告诉我我的绩效怎么定……

纯粹用数值来衡量无法正确考核，开发任务的周期、难度、激励都没有考虑进去，简单和难的一样考核，会导致烫手山芋没人接。

@Dex7er 孙子？多大仇

@seabirds 淡定， 不要和这种人生气， 不值得， 林子大了什么鸟都有。

这种太细了，这样多压抑啊，一起干活，各自负责部分，有错一起分析。这种技术型公司氛围关系越简单越好，反正工资入职已经定了，大家都知道涨薪水基本不可能。

@beginor 这吊毛自认孙子，别扯上别人。我认为如何考核也是技术问题，扯上人身攻击的真的没素质。

@lijingyu68 nice，管理者其实只需要关注最终产出，量化团队绩效就可以了。至于团队内部，如何细分到个人，就要放权给团队领袖了。设置一个开放的投诉渠道，对于各个团队内部的不同意见给予重视即可。。。想要给个人员工打分的考核计划，目前见过的几家最终都是走形式，纯属浪费时间。。。

严重赞同 摸鱼和处理个人事务是基本人权。。。

@seabirds 自嘲懂不懂 捡骂干嘛呢

只要是用打分，就有空子钻，上有政策，下有对策 这个我在一家大厂深有体会，我猜一下给程序员考核的最终目的是什么？
1. 找出优秀员工，升官，找出垃圾员工，干掉
2. 让员工全情投入工作
3. 让开发的产品质量更高
我个人觉得楼主的考核细则还可以，但是如果让员工们知道这些细则，他就知道如何去钻空子，如何去刷分，如何摸鱼，所以我觉得考核可以有，但是不能公开细则和具体的结果，因为不管细则多么完美，考核的结果和实际的情况绝对是有出入的。如 58 楼 @wawehi 所说，具体的工作是很难衡量的，用一个简单的工时是不够的，据一个简单的例子，程序员 A 接到要求 2 天内完成一个 issue，A 可以用自己很熟悉的方式完成这个 issue，只需要一天，但是 A 觉得可以尝试一些新的思路来实现它，可以获得更好的性能，结果 A 花了 3 天才完成。所以 A 的考核垫底，这会打击 A 的积极性，A 从此以后和其他员工一样老老实实完成工作，开开心心摸鱼。
所以一切具体的考核规则，都会磨灭人的创造性和积极性，考核得有，但是不能作为唯一的评判依据。
回到上面的三个目的，第一个优秀的员工自然会随着时间脱颖而出既然能进入公司的就不能说是垃圾员工，至少一开始不是。
第二个 考核不但不能激发员工的工作热情，而且会让员工找到安全的摸鱼方法，想要员工全情工作，估计得在企业文化和氛围下功夫。
第三个 保证软件质量，最重要的还是测试，外企的测试流程很规范，可以学习一下，不过完整的测试会拉长开发周期。
既然是软件公司，那么最重要的还是要留下优秀的人，有两种方式，一是靠钱，二是靠联系，联系是什么 简单的理解就是让优秀的员工和公司产生更多的关联，让他感觉不仅仅是来打工的赚钱的，所以公司内的各种团建活动，技术交流活动神马的必不可少。

@Dex7er 自己当孙子就行，别扯上别人

入职后看看是不是秃的更厉害了，也能作为一种客观表现吧~哈哈哈哈哈

@seabirds
首先，我好像没有点名叫你孙子
倒是你上来就指着我叫孙子吊毛的
麻痹给你脸你还他妈蹬鼻子上脸呢
可去你妈的吧傻逼玩意儿。。。

考核这个词 本身就代表着资本主义的剥削本质
当你费劲心思 制定出一堆个人考核指标的时候
你既决定了一个人的工作下限 也决定了一个人的工作上限
这时候大部分人 都只会关注个人的目标 而忽略了团队的目标
大公司人多难管理 采用这种方式无可厚非
小公司搞这个 就是给自己挖坑

看目标呀，安排的任务都完成了，就加分。
任务完不成的，就减分

核心还是代码交付质量，设置主程序员做 Pull Request，分支提交代码后，需审核才能合并；
同时要求文档质量，注释规范度做为其中一维。

好像很难